...

std::auto_ptr<localization_backend>

...

localization_backend_manager::get() const;

Class localization_backend_manager is marked as BOOST_LOCALE_DECL. his is hinting at placing instances of the class in a standalone shared library without problems. But here it is: using std::auto_ptr<> in interfaces is an error (Due to possibility of placing instances of classes in dynamic libraries).

Boost.Locale DLL should be linked with dynamic runtime (/MD switch of MSVC) You should never mix debug and release variants together (/MD and /MDd should not be mixed) This is correct in general and for Boost.Locale as well. It depends on the standard C++'s runtime to be shared with the program otherwise nothing would work. As for example each facet defined by unique id that should be really unique. Also as additional note all facets are classes derived from std::locale::facet and destroyed by std::locale object (may be even in user part of program) So if object that created in DLL can't be deleted outside of DLL nothing would work. Fortunately user program and boost.locale's DLL share the same runtime unless user does something really bad.

Dynamic library that contain your class might be compiled in debug / release / another mode, but client's code might have an alternative heap (because it use another C++ Run Time system)

Never, never, never mix debug and release run-times.

with an alternative heap manager. std::auto_ptr<> doesn't carrying *deleter* with a raw pointer of the allocated object, as boost::scoped_ptr<>, boost::shared_ptr<> or c++0x's std::unique_ptr<> does. Memory allocated from one heap might be "released" by foreign heap manager! :-/

Actually only shared_ptr carries deleter, and in any case in many other (most important places) like std::locale::facets their live time handled by ordinary pointer without any deleters.

See Sutter/Alexandrescu recommendation do not use std::auto_ptr<> (in ISBN: 9780321113580, C++ Coding Standards, "Rule 60: Avoid allocating and deallocating memory in different modules") and problem description (in ISBN: 9780201604641, Douglas Schmidt, Stephen Huston - C++ Network Programming [Volume 2] Chapter 5, "Sidebar 29: Portable Heap Operations with ACE")

..so change std::auto_ptr<> to some of the more safe smart pointer.

In general case it is good to carry deleter but in this particular case I don't see any problem. And "smarter" pointer would not help in 90% other places in Boost.Locale's code.

...

void localization_backend_manager::select( std::string const& backend_name, locale_category_type category = all_categories);

Why you don't use enums instead of std::string and locale_category_type? (latter is unsigned, actually). So this code is permissible:

boost::locale::localization_backend_manager::global().select("...", static_cast<unsigned>(std::rand()));

std::string as opposed to ((emulated) scoped) enum implies discarded static type checking plus run-time overhead (due to *run-time* "type" checking, as i guess). unsigned type provides a wider "supertype" for argument than necessary

Because it is rather bitmask then the specific values. Artyom