Subject: Re: [boost] [locale] localization_backend_manager interface issue
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-15 11:20:46
> > 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
> 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
> 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.