Doug Gregor wrote: > On Thu, Jun 26, 2008 at 10:23 PM, David Abrahams <[EMAIL PROTECTED]> wrote: >> and interface changes across versions of Boost. > > soversions are the right way to deal with this issue, not name mangling.
Yeah, I know; I just don't really understand them yet ;-) >>> 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? very few, so your point is taken. >> 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. OK, agreed. Now do you think that auto-linking makes mangling make sense on Windows, or should we drop it there, too? -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
