On Thu, Jun 26, 2008 at 10:23 PM, David Abrahams <[EMAIL PROTECTED]> wrote: > Doug Gregor wrote: > But as you know, it's not just about multiple compilers: it's about > incompatible ABI options
Yes, I know. This is typically handled by having the user just set the options needed and putting the libraries into some place where all of the libraries compiled with those options will reside. Problems can crop up if users are sloppy, of course, so this approach is less safe. > and interface changes across versions of Boost. soversions are the right way to deal with this issue, not name mangling. > >> People have been doing this on Unix systems for many, >> many years. > > With C++? I know there are a few C++ libraries out there but I didn't > think many of them had the kind of variations that we seem to want to > have. What do other libraries do about each of the features described > in > http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html#library-naming? > Are all of those letters solving non-problems? They are real problems, but how many users will ever use more than one, default variant of the library? > Just for example, in single-threaded programs, we apparently don't want > to make people pay for synchronization when shared_ptr is copied, > because then they'll say our general-purpose shared_ptr is slow. But > then you need separate libraries for single- and multi-threaded > programs. OK, shared_ptr is header-only, but I hope you get my point. I suggest that the vast majority of users should be using the multi-threaded versions; those that truly will only use Boost in single-threaded environments and are copying shared_ptrs so often that their performance is at risk can flip the right switches to build Boost differently. Few people need that freedom, so the rest of the users shouldn't pay for it with more complexity. - Doug _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
