Re: [boost] [locale] localization_backend_manager interface issue

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
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