Choosing helper C++ libraries for interop.

2015-05-20 Thread Vladimir Ozerov
Igniters, In upcoming interop efforts we will need concurrent collections and primitives in C++ layer. Obvious candidate is Boost, but it appears to be too heavy. Another library I found is Intel's TBB ( https://www.threadingbuildingblocks.org/) - it is open-source and pretty light. Does anyone

Re: Choosing helper C++ libraries for interop.

2015-05-20 Thread Pavel Tupitsyn
Hi, I vote for Boost. From my understanding, it is the most comprehensive extension library, and very widely adopted. What do you mean by too heavy? - Did you try to use it and compare dll sizes? How big is the difference? - Does dll size really matter for us that much? Thanks, On Wed,

Re: Choosing helper C++ libraries for interop.

2015-05-20 Thread Vladimir Ozerov
Brane, I do not know in advance what exactly will be needed there, but it is _very_ likley that we will need thread-locals, atomics (both CAS and increments/decrements), java-like volatiles (i.e. membars), cirical sections, read-write locks and concurrent dictionaries. On Wed, May 20, 2015 at

Re: Choosing helper C++ libraries for interop.

2015-05-20 Thread Branko Čibej
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

Re: Choosing helper C++ libraries for interop.

2015-05-20 Thread Yakov Zhdanov
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,

Re: Choosing helper C++ libraries for interop.

2015-05-20 Thread Branko Čibej
There is one thing you could do, depending on which parts of Boost you need. Boost has a tool to extract only the headers you actually need and puts the extracted declarations into a custom namespace. If your dependencies are header-only, you can include those bits in the Ignite sources. That way,