On 01.06.2015 09:58, Vladimir Ozerov wrote:
> Igniters,
>
> There is widespread opinion that STL types should not be used in public
> (exported) APIs to maximize portability. It means that even such simple
> types like std::string or std:vector shouldn't appear in any public
> definitions.
>
> Pros:
> Better portability => less problems when Ignite library will be linked to
> user applications possibly created with other compilers.
>
> Cons:
> Uglier and heavier interfaces. E.g., instead of
> std::string ReadString(const char* fieldName)|
>
> it will be something like
> char* ReadString(const char* fieldName, const CharAllocator& alloc);
> class CharAllocator {
> public:
> virtual char* Allocate(int32_t len) = 0;
> }
>
> So should we stick to this practice and avoid STL classes in public API?
I heartily agree that no-one should be using the STL. Everyone should be
using the 15-year-old C++ standard library instead. :) For historic
reference, the STL concepts were included as the standard Containers
library (<vector>, <list>, etc.).
If you decided to use C++98 (or 03) as your compatibility baseline, then
stick with that. Compatibility of standard libraries is not a problem:
we release source, users compile the source with whatever compiler
they're using and link the results into their application.
IMO it is insane to try to "improve portability" by not using standard
library types in the public API: you'll end up by either writing your
own smart objects or returning bare pointers from the API. That's
"fixing" a minor inconvenience (having to compile the sources) by
introducing memory management hell, not to mention making it impossible
for the API consumers to write exception-safe code.
Instead, make sure compiling the C++ API is as simple as possible; avoid
all non-standard dependencies and platform-specific magic and you're done.
-- Brane
