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

[Tristan Tarrant]

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 ?

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
>>
>