Topic: Why is X(X&) now illegal?


Author: oslo@vnet.ibm.com (Charles Rankin)
Date: 1995/07/28
Raw View
In <3u762m$sp2@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
>esap@cs.tut.fi (Pulkkinen Esa) writes:
>
>>In article <1995Jul11.164514.28277@ptolemy-ethernet.arc.nasa.gov>,
>>Paul J. Lucas <pjl@kronos.arc.nasa.gov> wrote:
>>>             template< class T > class baton {
>>>             public:
>>>                     baton( baton &from ) : p( from.p ) { from.p = 0; }
>>>             private:
>>>                     T *p;
>>>             };
>>>     But, the above c'tor of the form X(X&), I discovered, is now
>>>     flagged as an anachonism.  Why?  If I really want to do the
>>>     above, why shouldn't I be able to?
>
>>I couldn't find it in the anachronisms section of the draft...
>
>I don't believe it is disallowed, and the Sun C++ 4.1 compiler does
>not flag it as an anachronism.
>--
>Steve Clamage, stephen.clamage@eng.sun.com

Isn't the problem the fact that the copy constructor for this template
class should be

    baton(baton<T> &from);
               ---

Charles Rankin
IBM Austin - Product Assessment for LAN Systems
------------------------------------------------------------------------
I do not speak for IBM.






Author: maxtal@Physics.usyd.edu.au (John Max Skaller)
Date: 1995/07/20
Raw View
In article <1995Jul11.164514.28277@ptolemy-ethernet.arc.nasa.gov>,
Paul J. Lucas <pjl@kronos.arc.nasa.gov> wrote:
> Suppose I have a class 'baton':
>
>  template< class T > class baton {
>  public:
>   baton( baton &from ) : p( from.p ) { from.p = 0; }
>  private:
>   T *p;
>  };
>
> where only one instance at any given time is permitted to point
> to an object.  If a new instance is copy-constructed, the new
> instance nulls the 'from' instance's pointer.
>
> But, the above c'tor of the form X(X&), I discovered, is now
> flagged as an anachonism.  Why?  If I really want to do the
> above, why shouldn't I be able to?

 The 28-April Draft permits the form X(X&). Has this changed
at Monterey?

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189





Author: jsa@edg.com (J. Stephen Adamczyk)
Date: 1995/07/21
Raw View
In article <3ulm9o$2m1@metro.ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>In article <1995Jul11.164514.28277@ptolemy-ethernet.arc.nasa.gov>,
>Paul J. Lucas <pjl@kronos.arc.nasa.gov> wrote:
>> Suppose I have a class 'baton':
>>
>>  template< class T > class baton {
>>  public:
>>   baton( baton &from ) : p( from.p ) { from.p = 0; }
>>  private:
>>   T *p;
>>  };
>>
>> where only one instance at any given time is permitted to point
>> to an object.  If a new instance is copy-constructed, the new
>> instance nulls the 'from' instance's pointer.
>>
>> But, the above c'tor of the form X(X&), I discovered, is now
>> flagged as an anachonism.  Why?  If I really want to do the
>> above, why shouldn't I be able to?
>
> The 28-April Draft permits the form X(X&). Has this changed
>at Monterey?

No, nothing was changed in that area.  X(X&) is a copy constructor.  It is,
however, a copy constructor that can copy only lvalues, not rvalues.
Perhaps the compiler in question is warning of an anachronism on a *use*
of the copy constructor, not its definition?

Steve Adamczyk





Author: ball@Eng.Sun.COM (Mike Ball)
Date: 1995/07/21
Raw View
In article DLn@edg.com, jsa@edg.com (J. Stephen Adamczyk) writes:
> No, nothing was changed in that area.  X(X&) is a copy constructor.  It is,
> however, a copy constructor that can copy only lvalues, not rvalues.
> Perhaps the compiler in question is warning of an anachronism on a *use*
> of the copy constructor, not its definition?

As Paul later posted, he found the problem in his program that caused the
error message.  He didn't say what it was, but I suspect that Steve's
guess above is correct.

The Sun compiler doesn't and never has warned about X(X&) as a copy constructor.

There is no change in the standard in that area.

-Mike Ball-
SunSoft Developer Products






Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1995/07/15
Raw View
esap@cs.tut.fi (Pulkkinen Esa) writes:

>In article <1995Jul11.164514.28277@ptolemy-ethernet.arc.nasa.gov>,
>Paul J. Lucas <pjl@kronos.arc.nasa.gov> wrote:
>>  template< class T > class baton {
>>  public:
>>   baton( baton &from ) : p( from.p ) { from.p = 0; }
>>  private:
>>   T *p;
>>  };
>> But, the above c'tor of the form X(X&), I discovered, is now
>> flagged as an anachonism.  Why?  If I really want to do the
>> above, why shouldn't I be able to?

>I couldn't find it in the anachronisms section of the draft...

I don't believe it is disallowed, and the Sun C++ 4.1 compiler does
not flag it as an anachronism.
--
Steve Clamage, stephen.clamage@eng.sun.com





Author: pjl@kronos.arc.nasa.gov (Paul J. Lucas)
Date: 1995/07/12
Raw View
In <3tvh1g$42q@peippo.cs.tut.fi> esap@cs.tut.fi (Pulkkinen Esa) writes:

>In article <1995Jul11.164514.28277@ptolemy-ethernet.arc.nasa.gov>,
>Paul J. Lucas <pjl@kronos.arc.nasa.gov> wrote:
>>  template< class T > class baton {
>>  public:
>>   baton( baton &from ) : p( from.p ) { from.p = 0; }
>>  private:
>>   T *p;
>>  };
>> But, the above c'tor of the form X(X&), I discovered, is now
>> flagged as an anachonism.  Why?  If I really want to do the
>> above, why shouldn't I be able to?

>I couldn't find it in the anachronisms section of the draft...
>Could you please point out where in the draft such claim is made.

 The SunPro C++ compiler 4.0.1 -- I thought the new Sun compiler
 would have been right.

>I would guess that this means the old copy constructor format,
>and that it has been overridden by the rule that there are two
>forms of copy constructor, X(const X&) and X(X&). [class.copy]/2
>has an example with a non-const version of the copy constructor.

>You can also make the 'p'-member mutable if you want to use the
>const copy constructor for it.

 Ah -- hadn't thought of that.  Thanks.
--
 - Paul J. Lucas
   NASA Ames Research Center  Caelum Research Corporation
   Moffett Field, California  Mountain View, California





Author: pjl@kronos.arc.nasa.gov (Paul J. Lucas)
Date: 1995/07/12
Raw View
In <1995Jul12.142304.27309@ptolemy-ethernet.arc.nasa.gov> pjl@kronos.arc.nasa.gov (Paul J. Lucas) writes:

>In <3tvh1g$42q@peippo.cs.tut.fi> esap@cs.tut.fi (Pulkkinen Esa) writes:

>>In article <1995Jul11.164514.28277@ptolemy-ethernet.arc.nasa.gov>,
>>Paul J. Lucas <pjl@kronos.arc.nasa.gov> wrote:
>>>  template< class T > class baton {
>>>  public:
>>>   baton( baton &from ) : p( from.p ) { from.p = 0; }
>>>  private:
>>>   T *p;
>>>  };
>>> But, the above c'tor of the form X(X&), I discovered, is now
>>> flagged as an anachonism.  Why?  If I really want to do the
>>> above, why shouldn't I be able to?

>>I couldn't find it in the anachronisms section of the draft...
>>Could you please point out where in the draft such claim is made.

> The SunPro C++ compiler 4.0.1 -- I thought the new Sun compiler
> would have been right.

 Never mind...my mistake after all -- the compiler is right.
 Sorry.
--
 - Paul J. Lucas
   NASA Ames Research Center  Caelum Research Corporation
   Moffett Field, California  Mountain View, California





Author: wil@ittpub.nl (Wil Evers)
Date: 1995/07/13
Raw View
In article <1995Jul11.164514.28277@ptolemy-ethernet.arc.nasa.gov> Paul J.
Lucas (pjl@kronos.arc.nasa.gov) writes:
>  Suppose I have a class 'baton':
>
>   template< class T > class baton {
>   public:
>    baton( baton &from ) : p( from.p ) { from.p = 0; }
>   private:
>    T *p;
>   };
>
>  where only one instance at any given time is permitted to point
>  to an object.  If a new instance is copy-constructed, the new
>  instance nulls the 'from' instance's pointer.
>
>  But, the above c'tor of the form X(X&), I discovered, is now
>  flagged as an anachonism.  Why?  If I really want to do the
>  above, why shouldn't I be able to?
> --
>  - Paul J. Lucas
>    NASA Ames Research Center  Caelum Research
Corporation
>    Moffett Field, California  Mountain View, California

Gee, I don't know. Where in the draft standard does it say so? If X::(X&)
is now an anachronism, the standard contradicts itself and should be
fixed, because the class template auto_ptr (20.4.5, [lib.auto.ptr]) has
such a beast. I think it does exactly what your example does.

- Wil





Author: pjl@kronos.arc.nasa.gov (Paul J. Lucas)
Date: 1995/07/11
Raw View
 Suppose I have a class 'baton':

  template< class T > class baton {
  public:
   baton( baton &from ) : p( from.p ) { from.p = 0; }
  private:
   T *p;
  };

 where only one instance at any given time is permitted to point
 to an object.  If a new instance is copy-constructed, the new
 instance nulls the 'from' instance's pointer.

 But, the above c'tor of the form X(X&), I discovered, is now
 flagged as an anachonism.  Why?  If I really want to do the
 above, why shouldn't I be able to?
--
 - Paul J. Lucas
   NASA Ames Research Center  Caelum Research Corporation
   Moffett Field, California  Mountain View, California





Author: esap@cs.tut.fi (Pulkkinen Esa)
Date: 1995/07/12
Raw View
In article <1995Jul11.164514.28277@ptolemy-ethernet.arc.nasa.gov>,
Paul J. Lucas <pjl@kronos.arc.nasa.gov> wrote:
>  template< class T > class baton {
>  public:
>   baton( baton &from ) : p( from.p ) { from.p = 0; }
>  private:
>   T *p;
>  };
> But, the above c'tor of the form X(X&), I discovered, is now
> flagged as an anachonism.  Why?  If I really want to do the
> above, why shouldn't I be able to?

I couldn't find it in the anachronisms section of the draft...
Could you please point out where in the draft such claim is made.

I would guess that this means the old copy constructor format,
and that it has been overridden by the rule that there are two
forms of copy constructor, X(const X&) and X(X&). [class.copy]/2
has an example with a non-const version of the copy constructor.

You can also make the 'p'-member mutable if you want to use the
const copy constructor for it.
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.