🚀 go-pugleaf

"john (j.d.) hickin" <hickin@bnr.ca> writes:
>And this, the expectation that constructors of the form X(X&) and X(const X&)
>must perform a *copy* operation, is, IMHO, the trouble.

No, the notion that these constructors perform copy operations (and only
copy operations) is deeply wired in to the language, in at least three
places: argument passing, return value passing, and optimizing away of
copy constructors all assume these constructors mean "copy".

>The original term was reference constructor, a name which, in my opinion,
>carefully stepped around all subtleties of language.

I have never seen this term used.  Stroustrup said "copy constructor"
at a very early stage.

Anyone who writes a class in which X(X&) or X(const X&) does not have the
semantics of a copy operation is doing something wrong (e.g. auto_ptr in
the draft standard is broken).

-- 
-- Joe Buck 	<jbuck@synopsys.com>	(not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.	   -- Vaclav Havel
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <4eucnc$hr9@hermes.synopsys.com> jbuck@Synopsys.COM (Joe
Buck) writes:

|> "john (j.d.) hickin" <hickin@bnr.ca> writes:
|> >And this, the expectation that constructors of the form X(X&) and
|> >X(const X&) must perform a *copy* operation, is, IMHO, the trouble.

|> No, the notion that these constructors perform copy operations (and only
|> copy operations) is deeply wired in to the language, in at least three
|> places: argument passing, return value passing, and optimizing away of
|> copy constructors all assume these constructors mean "copy".

|> >The original term was reference constructor, a name which, in my opinion,
|> >carefully stepped around all subtleties of language.

|> I have never seen this term used.  Stroustrup said "copy constructor"
|> at a very early stage.

|> Anyone who writes a class in which X(X&) or X(const X&) does not have the
|> semantics of a copy operation is doing something wrong (e.g. auto_ptr in
|> the draft standard is broken).

I wouldn't go quite that far.  X(X&) is a particular form of copy,
which modifies the copied object.  If it is programmed in such a way
that the number of intermittent copies is meaningless (as is the case
in auto_ptr), then it is perfectly valid.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

I wrote:
>|> Anyone who writes a class in which X(X&) or X(const X&) does not have the
>|> semantics of a copy operation is doing something wrong (e.g. auto_ptr in
>|> the draft standard is broken).

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
>I wouldn't go quite that far.  X(X&) is a particular form of copy,
>which modifies the copied object.  If it is programmed in such a way
>that the number of intermittent copies is meaningless (as is the case
>in auto_ptr), then it is perfectly valid.

You're not really disagreeing with me, James.  X(X&) is a reasonable
thing to do in some cases, and the source object will then be modified,
but if this operation does not look like a copy that leaves the
functioning of the argument object mostly unaltered, the user of the class
is going to have problems and surprises.  Many uses of X(X&) just modify
private members to keep some sort of internal record, e.g. how many copies
there are and connections between them.


-- 
-- Joe Buck 	<jbuck@synopsys.com>	(not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.	   -- Vaclav Havel
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

In article <4fbapm$lbk@hermes.synopsys.com> jbuck@Synopsys.COM (Joe
Buck) writes:

> I wrote:
> >|> Anyone who writes a class in which X(X&) or X(const X&) does not have the

> >|> semantics of a copy operation is doing something wrong (e.g. auto_ptr in
> >|> the draft standard is broken).
> 
> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
> >I wouldn't go quite that far.  X(X&) is a particular form of copy,
> >which modifies the copied object.  If it is programmed in such a way
> >that the number of intermittent copies is meaningless (as is the case
> >in auto_ptr), then it is perfectly valid.
> 
> You're not really disagreeing with me, James.  X(X&) is a reasonable
> thing to do in some cases, and the source object will then be modified,
> but if this operation does not look like a copy that leaves the
> functioning of the argument object mostly unaltered, the user of the class
> is going to have problems and surprises.  Many uses of X(X&) just modify
> private members to keep some sort of internal record, e.g. how many copies
> there are and connections between them.

That's what mutable is for.

I have no problems with the desired semantics for auto_ptr, for example.
Copy and assignment modify the copied/assigned from object completely.
They render it invalid.  You can hardly say that this is leaving the
object `mostly unaltered'.  However, the number of intermediate objects
is irrelevant; the function is transitive.  The `copy' is actually more
of a `move'.

Perhaps one of the reasons I want auto_ptr so badly in the standard is
that this is *not* something you would want to do in an arbitrary user
class, anymore than you would want to redefine left shift to mean input.
It because valid because it *is* part of the `standard' language;
everyone knows and uses it in this way.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]