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? Vladimir. |
+1
Depending on STL in long term will cause issues with portability and potentially performance across different architectures. If we want to go for a cleaner interface, we can think of a more portable library (Boost?) On Mon, Jun 1, 2015 at 1:28 PM, Vladimir Ozerov <[hidden email]> 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? > > Vladimir. > -- Regards, Atri *l'apprenant* |
Atri,
As a general rule of thumb we are trying to avoid 3rd party dependencies as much as possible. E.g. Ignite for Java has only one mandatory dependency - jcache - as our cache is compliant with jcache specification. So we should try avoiding any 3rd-party dependenices (especially such massive like boost) until it is absolutely necessarily. On Mon, Jun 1, 2015 at 11:00 AM, Atri Sharma <[hidden email]> wrote: > +1 > > Depending on STL in long term will cause issues with portability and > potentially performance across different architectures. If we want to go > for a cleaner interface, we can think of a more portable library (Boost?) > > On Mon, Jun 1, 2015 at 1:28 PM, Vladimir Ozerov <[hidden email]> > 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? > > > > Vladimir. > > > > > > -- > Regards, > > Atri > *l'apprenant* > |
In reply to this post by Vladimir Ozerov
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 |
Free forum by Nabble | Edit this page |