ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Choosing helper C++ libraries for interop.
Date Wed, 20 May 2015 13:53:51 GMT
Brane, the API has already been designed. In the best case all
functionality available in Java should be available in non-Java stuff (if
there are no technology limitations). I would not care about compile time -
Boost increases it, of course, but does not make compilation infinite.
Functionality, stability and developer convenience seem to be more
important.

GridGain had its CPP stuff using Boost with ~4-5 min compilation on rather
weak machine.

However, given that client will be completely reapproached and should be
less complex I would think whether we need any third party library at all.

--Yakov

2015-05-20 12:27 GMT+03:00 Branko ─îibej <brane@apache.org>:

> On 20.05.2015 09:40, Vladimir Ozerov wrote:
> > This is not about resulting size of our lib. Moreover, we will not
> > statically link it to Ignite because in this case users will have
> troubles
> > when using both Boost and Ignite simultaneously.
> > The problem is that if we use Boost, we will force users to have it on
> > their machines during both build-time and runtime. And Boost is known to
> > have dready dependencies between their modules. So if we use only
> > concurrency module it might lead to transitive dependencies to lots other
> > ones.
>
> Using any part of Boost also increases compile times dramatically
> because if its inter-module dependencies and its heavy usage of template
> programming.
>
>
> The first step is to design an API, before deciding on a helper library,
> which you may not even need. Talking about Boost or TBB or whatnot
> before you even know what kind of features you need to implement your
> API is, to put it mildly, just crazy.
>
> Real Programmers do not download 11 jars to use one external method ...
>
> -- Brane
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message