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,
 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
 [ 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
> {{{
> struct direct_initialized_t { };
> const direct_initialized_t direct_initialized =
> }}}
> 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

 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: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:02 UTC