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

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 >

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev