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 >> > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
