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.

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