Topic: If no cp ctor, why not def ctor and assignm


Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1995/05/17
Raw View
In article 4CC@info.physics.utoronto.ca, peter@chinook.physics.utoronto.ca (Peter Berdeklis) writes:
>
>
>The WP says that if a copy ctor is not provided by the user then
>the compiler will provide one.  Again, I understand that a
>simple memberwise copy will be sufficient for many situations.
>
>However, if the user has provided an assignment operator and a
>default ctor (if necessary), but has neglected to provide a copy
>ctor for some reason, wouldn't it be better if the compiler used
>the default ctor/assignment pair and flag a warning, than to have
>the compiler just do a dumb copy?

There is no a priori reason to believe that default ctor plus assignment
will be correct and the compiler-generated copy ctor will not.
The reverse could be true.

Compilers (and lint-like) programs can warn about the case where
one or two of copy ctor, assignment op, and dtor are declared but
not all three. It is not necessarily an error to omit just one or two,
but it should be verified. The default semantics for the missing
functions might be correct, after all.

---
Steve Clamage, stephen.clamage@eng.sun.com







Author: peter@chinook.physics.utoronto.ca (Peter Berdeklis)
Date: 1995/05/17
Raw View
According to Steve Clamage <clamage@Eng.Sun.COM>:
> In article 4CC@info.physics.utoronto.ca, peter@chinook.physics.utoronto.ca (Peter Berdeklis) writes:
>
> There is no a priori reason to believe that default ctor plus assignment
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> will be correct and the compiler-generated copy ctor will not.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The reverse could be true.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Compilers (and lint-like) programs can warn about the case where
> one or two of copy ctor, assignment op, and dtor are declared but
> not all three. It is not necessarily an error to omit just one or two,
> but it should be verified. The default semantics for the missing
> functions might be correct, after all.


I think the reason to believe that the default ctor plus assignment
will be correct is that you assume that the programmer knew what
(s)he was doing when the assignment op. was written.  This of course
is not an a priori reason, because too often it's not true. :-)

If the programmer wrote an assignment op., it should be assumed that
it does something other that a memberwise copy (otherwise why bother
writing the assignment op.), in which case the copy ctor would also
have to do something other than a memberwise copy.  Unless someone
comes up with a _very_ intelligent compiler, a compiler-generated
copy ctor will simply do a memberwise copy, which would be wrong.

Maybe my problem is that I just cannot imagine a case (unless the
programmer is just plain wrong) when a compiler-generated copy ctor
would be right and a default ctor/assignment pair would not.  If
you can provide me with a reasonable example, I'ld be happy to just
shut up. <:^0


Pete








Author: riyer@interaccess (Ravikant Iyer)
Date: 1995/05/18
Raw View
Peter Berdeklis (peter@chinook.physics.utoronto.ca) wrote:
[Snip 8< ]
: Maybe my problem is that I just cannot imagine a case (unless the
: programmer is just plain wrong) when a compiler-generated copy ctor
: would be right and a default ctor/assignment pair would not.  If
: you can provide me with a reasonable example, I'ld be happy to just
: shut up. <:^0

class foo {
 public:
  foo (const int g=0,const int b=0) : goo(g),bar(b) {}
  foo & operator = (const foo &f) { goo = f.goo ; return *this}
 private:
  const int bar;
  int goo ;
};

void bar ()
{
 foo f(10,20) ;
 foo f2 = f;
 // With member copy f2 has correct values for bar & goo
 // With a default constructor and assignment it dosent!
}
: Pete
-ravi







Author: rac@intrigue.com (Robert Coie)
Date: 1995/05/18
Raw View
In article <D8qqwt.Dsu@info.physics.utoronto.ca>,
peter@chinook.physics.utoronto.ca (Peter Berdeklis) wrote:

: Maybe my problem is that I just cannot imagine a case (unless the
: programmer is just plain wrong) when a compiler-generated copy ctor
: would be right and a default ctor/assignment pair would not.  If
: you can provide me with a reasonable example, I'ld be happy to just
: shut up. <:^0

How about a class for which I want to prohibit assignment, to disallow
reseating like C++'s references?

class A
{
public:
   A();

private:
   void operator=( const A & );
};

Assume that the data members are trivial, so that memberwise copy is
sufficient for the copy operation.  The way it is now, I can prohibit
assignment without having to actually define the assignment op.  Your
solution would cause me linker errors and force me to actually define
operator= just in order to duplicate the behavior of the
compiler-generated copy constructor, which was all I wanted in the first
place.

Robert Coie                              rac@intrigue.com
Implementor, Intrigue Corporation     AppleLink: INTRIGUE





Author: peter@chinook.physics.utoronto.ca (Peter Berdeklis)
Date: 1995/05/18
Raw View
O.K., thank you.  In 24 hours I've gotten 2 good examples where a
compiler-generated copy ctor would be right and the default ctor/
assignment pair would not.

Now, as promised, I will shut up. (Congrats - I think that's a first :-)


Pete