std::auto_ptr<localization_backend> localization_backend_manager::get() const;
Class localization_backend_manager is marked as BOOST_LOCALE_DECL. This 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). 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) 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! :-/ 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.
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 -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?