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 <atri.j...@gmail.com> 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 <voze...@gridgain.com>
> 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*
>
