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-07 18:46:44

#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 niels_dekker):

 Replying to [comment:5 Edward Diener]:
 > It sounds to me that you are rejecting any class that has a constructor
 which takes a single parameter because it may lead to an ambiguous
 situation like the one you show above.

 I am not rejecting ''any class'' that has a constructor which takes a
 single parameter. Although I have to admit, both
 [http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=522094

 that particular Visual C++ bug report of yours] and [http://www.open-

 std.org/jtc1/sc22/wg21/docs/papers/2009/n3006.html#535 CWG issue 535,
 "Copy construction without a copy constructor"] have made me more aware
 that such a constructor may cause confusion or ambiguity.

 But I do think {{{value_initialized}}} should be dealt with with extra
 care. Because it is around now for more than seven years, and I assume it
 is used in quite a lot of programs worldwide. Thereby
 {{{value_initialized}}} is by its nature ''very'' generic, so it's very
 well possible that your proposed change might break some user code in an
 unexpected way. Moreover, your proposed constructor offers a ''loophole'',
 which allows to break the class invariant, being that
 {{{value_initialized}}} holds an object that has been value-initialized.

 Now it might in some cases be acceptable to break backward compatibility.
 And I think that there are very good reasons to allow storing a ''direct-
 initialized'' object into a {{{value_initialized}}} wrapper. But I just
 think the considerations above have to be taken into account when deciding
 how to resolve your value_init request.

 I'm certainly not against
 [https://svn.boost.org/trac/boost/attachment/ticket/3472/value_init.patch

 your proposed patch], it's just that I would prefer to add a tag parameter
 (for example, ''boost::direct_initialized'') to your constructor. But it
 appears that you're strongly opposed to that idea of mine, right?

 Anyway, I just hope Fernando can make the right choice  :-)

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