C++ client: using STL types in public API.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

C++ client: using STL types in public API.

Vladimir Ozerov
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.
Reply | Threaded
Open this post in threaded view
|

Re: C++ client: using STL types in public API.

Atri Sharma
+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*
Reply | Threaded
Open this post in threaded view
|

Re: C++ client: using STL types in public API.

Vladimir Ozerov
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*
>
Reply | Threaded
Open this post in threaded view
|

Re: C++ client: using STL types in public API.

Branko Čibej
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