[infinispan-dev] ABI compatibility of C++ client

[Dan Berindei]

I'm not convinced that assuming that the user has the same compiler/c 
runtime/c++ library/exception handling is such a big deal.

The users already have the sources; if we only ship a binary compiled 
with VS2013 and they want to compile their project with VS2012, they 
can recompile the C++ client themselves.


On Tue, Apr 29, 2014 at 4:08 PM, Radim Vansa <rvansa at redhat.com> wrote:
> On 04/29/2014 01:31 PM, Tristan Tarrant wrote:
>>  Yes, it is a sticky situation. We can definitely change the API now
>>  (actually this is the best moment to do this).
>>  I guess we need to provide "wrappers" of some kind. Any examples 
>> elsewhere ?
> Are we looking for a third-party library for binary-compatible 
> containers? One example could be [1] although it requires GCC 4.7.2 / 
> VS2013 compiler.
> 
> 
> What we need is to pass string, vector, set and map, all of them 
> constant. Shouldn't be a rocket science to convert them into flat 
> blobs 
> (I am not sure about the price of coding it ourselves/using 3rd party 
> library).
> We don't have to use these weird containers in public API nor 
> internally. But we have to put the "compression" into public headers 
> (to 
> be called by user code) and "decompression" (if needed) into 
> internals.
> 
> It could be a bit tricky to integrate this with marshalling which 
> happens anyway in user code, to make as few copies as possible (for 
> example for bulk methods which return std::map<K, V> - we don't want 
> to 
> create std::map<array, array>, convert it into blob_map<array, 
> array>, 
> then marshall into blob_map<K, V> and finally convert to std::map<K, 
> V>).
> 
> 
> And we should not inherit the public classes from Handle which uses 
> HR_SHARED_PTR, that's impl detail. Public classes should hold only 
> opaque pointers to internal data types.
> 
> I would recommend to treat warnings from Windows compilation as 
> blockers: it seems Visual Studio is much smarter in detecting 
> DLL-boundary related errors.
> 
> [1] https://github.com/jbandela/cppcomponents
> 
> 
>> 
>>  Tristan
>> 
>>  On 29/04/2014 13:02, Radim Vansa wrote:
>>>  I was expecting at least some response.
>>> 
>>>  Cliff, Ion, Tristan, Vladimir, could you share your opinions?
>>> 
>>>  Radim
>>> 
>>>  On 04/25/2014 02:26 PM, Radim Vansa wrote:
>>>>  Hi guys,
>>>> 
>>>>  as I've tried to get rid of all the warnings emitted in Windows 
>>>> build of
>>>>  C++ HotRod client, I've noticed that the ABI of this library is 
>>>> not very
>>>>  well designed.
>>>>  I am not an expert for this kind of stuff, but many sources I've 
>>>> found
>>>>  say that exporting STL containers (such as string or vector, or
>>>>  shared_ptr) is not ABI-safe.
>>>> 
>>>>  For windows, the STL export is allowed [1] when both library and 
>>>> user
>>>>  application is linked against the same version of CRT. I am 
>>>> really not
>>>>  sure whether we want to force it to the user, and moreover, due 
>>>> to bug
>>>>  in VC10 implementation of STL [2] we can't explicitly export 
>>>> shared_ptr
>>>>  (I haven't found any workaround for that so far).
>>>> 
>>>>  Regarding the GCC-world, situation is not better. The usual 
>>>> response for
>>>>  exporting STL classes is "don't do that". It is expected that 
>>>> these
>>>>  trouble will be addressed in C++17 (huh :)).
>>>> 
>>>>  What can we do about that? Fixing this requires a lot of changes 
>>>> in
>>>>  API... can we afford to do that now? Or will we just declare 
>>>> "compile
>>>>  with the same versions and compile options as we did"? (we should 
>>>> state
>>>>  them, then)
>>>> 
>>>>  I have only limited knowledge of the whole C++ ecosystem, if I am 
>>>> wrong,
>>>>  I'd be gladly corrected.
>>>> 
>>>>  Radim
>>>> 
>>>>  [1] http://support.microsoft.com/kb/168958
>>>>  [2] 
>>>> http://connect.microsoft.com/VisualStudio/feedback/details/649531
>>>> 
>>  _______________________________________________
>>  infinispan-dev mailing list
>>  infinispan-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140501/4fa66b5c/attachment.html