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 05:22:21

#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:4 niels_dekker]:
 > Hi Edward,
 > I understand you do not want to adapt your proposed constructor, merely
 because of a Microsoft specific compiler bug. But I think
 [https://svn.boost.org/trac/boost/attachment/ticket/3472/value_init.patch

 your patch] ''might'' break some use cases on other compilers as well:
 > {{{
 > class my_integer
 > {
 >   value_initialized<int> m_data;
 > public:
 >   operator value_initialized<int>() const;
 >   operator int() const;
 > };
 >
 > int main()
 > {
 >   my_integer my;
 >   value_initialized<int> val(my);
 > }
 > }}}
 >
 > The above example will become ambiguous when your proposed constructor
 is added, also according to GCC 4.1.2: http://codepad.org/zukxSDbB

 >
 > I think there's a trade off between safety and convenience here. BTW,
 why did you add an {{{explicit}}} keyword to your constructor?

 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. That seems to me to be
 unnecessarily restrictive and would eliminate much of C++ class design as
 it has previously been practiced. Consider:

 struct X
 {
 X() {}
 X(const X & value) {}
 X(int value) {}
 };

 struct Y
 {
 Y():anInt(5) {}
 operator X() const {return anX;}
 operator int() const {return anInt}
 private:
 X anX;
 int anInt;
 };

 int main()
 {
 Y aY;
 X anotherX(ay); // ambiguity
 X YetAnotherX(static_cast<X>(ay)); // eliminates ambiguity
 X YetAgainX(static_cast<int>(ay)); // eliminates ambiguity
 }

 One can create this situation with any class, like X, which has a
 constructor taking a single value. So I still do not see the point of yout
 objection to this very common usage in value_initialized. I know, or I
 think I know, that you can't seriously be suggesting that all classes with
 any constructors which take a single parameter are badly designed, and
 therefore need to add a second dummy parameter in each case just to avoid
 the possibly ambiguity as ou showed and I have shown above.

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