Re: [Boost-bugs] [Boost C++ Libraries] #3472: Setting value_initialized<T> to a value when T is a top-level const

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #3472: Setting value_initialized<T> to a value when T is a top-level const
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-01-06 01:11:20

#3472: Setting value_initialized<T> to a value when T is a top-level const
------------------------------------------------+---------------------------
 Reporter:  Edward Diener <eld@…>               |       Owner:  fcacciola
     Type:  Feature Requests                    |      Status:  new      
Milestone:  Boost 1.41.0                        |   Component:  utility  
  Version:  Boost 1.40.0                        |    Severity:  Problem  
 Keywords:  value_initialized const             |  
------------------------------------------------+---------------------------

Comment(by Edward Diener <eld@…>):

 Replying to [comment:2 niels_dekker]:
 > I still think your request is very reasonable. So I have just had
 another look at your proposed patch, which adds an explicit
 {{{value_initialized(T const&)}}} constructor. But now I'm a ''little''
 bit worried that the patch ''might'' cause some confusion or ambiguity
 between your proposed constructor and the existing copy-constructor of
 {{{value_initialized}}}. You know, a constructor with a single parameter
 could get ''some compiler'' confused, when generating an implementation-
 defined copy-constructor,
 [http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=522094

 as you have have recently reported to Microsoft]. Moreover, I believe
 there might be use cases where ambiguity would occur, even without a
 compiler bug.
 >
 > So wouldn't it be wiser to add an extra parameter to your constructor,
 as a ''tag'' (similar to {{{std::allocator_arg_t}}} in the latest
 [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf C++0x
 Draft], section [memory]).  Such a parameter might unambiguously specify
 that your constructor would ''direct-initialize'' the object, instead of
 doing value-initialization. I would propose to call the tag type
 {{{boost::direct_initialized_t}}}, and add the following lines to
 [https://svn.boost.org/svn/boost/trunk/boost/utility/value_init.hpp

 value_init.hpp]:
 > {{{
 >   struct direct_initialized_t { };
 >   const direct_initialized_t direct_initialized =
 direct_initialized_t();
 > }}}
 >
 > Your constructor could then be defined as follows:
 > {{{
 >    explicit value_initialized(T const & arg, direct_initialized_t)
 >    {
 >      new (wrapper_address()) wrapper(arg);
 >    }
 > }}}
 >
 > What do you think?

 I think that doing such contortions to avoid a Microsoft bug is unwise.
 You are basically saying, as I see it, that adding the 'explicit
 value_initialized(T const & arg)' along with the already existing copy
 constructor of 'value_initialized(value_initialized const & arg)' is going
 to cause VC++ to call the wrong constructor when trying to copy a value-
 initialized value. As I understand the Microsoft bug the problem lies when
 Microsoft generates a user-defined copy constructor in a derived class and
 this calls down to the incorrect base class constructor. Unless someone is
 going to derive a class from value_initialized, which is  probably not
 going to be done very often,  my added constructor will not cause problems
 with VC++. Even when it does in that particular case, do you really
 believe that it should be necessary to contort C++ just to deal with a
 single compiler's problem ? I would much rather have the person who might
 consider deriving from value_initialized and who uses VC++ to be made
 aware of the VC++ issue, possibly in comments in the value_initialized
 code, and to use the workaround to get around this bug of defining one's
 own derived class copy constructor that calls the base class's copy
 constructor.

 I strongly feel it is really a bad idea to change or complicate normal
 design and coding because of the an obvious bug in a particular
 implementation of a computer language. Please note I consider this as
 different from a compiler that simply doesn't support some feature of a
 language, where workarounds may be created for that compiler, so that one
 can implement some library design in another often less proficient and
 natural way. Not implementing a templated constructor in a perfectly
 normal way as opposed to a completely unusual and much harder to use
 choice can not be right.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/3472#comment:3>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.