Subject: [boost] [locale] localization_backend_manager interface issue
From: Max Sobolev (macsmr_at_[hidden])
Date: 2011-04-15 06:55:25
> 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
..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:
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. Ð Ñ ÑÐ»Ð¸ ÑÐ¾Ð»ÐºÑ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk