canceling noncopyable feature

[Juha Nieminen]

You lied to the compiler (and to the reader of your code).
First, you said that the object wasn't copiable, then you said
it was. I may be of the old school, but I find lying
despicable.

The simple solution to this problem is to fire the person who
wrote the code.

I'm not sure it's that simple. It can also be a genuine mistake.

In a long inheritance chain one of the classes buried somewhere in
there might have been made "noncopyable" for some purpose. Then someone
else might inherit from a class inherited from a class inherited... and
so on from that class, and *inadvertedly* write a copy constructor for
it, overriding the one in that "noncopyable" class.

Of course for this to compile this person has to, if I understood
correctly, fail to call the parent class copy constructor in his own. Of
course this is a bad mistake in itself, but it might happen.

The problem is that now, by pure accident, the class has become
copyable even though it should not be, and the compiler is of no help in
catching this.

 

[Victor Bazarov]

I'm not sure it's that simple. It can also be a genuine mistake.

In a long inheritance chain one of the classes buried somewhere in
there might have been made "noncopyable" for some purpose. Then someone
else might inherit from a class inherited from a class inherited... and
so on from that class, and *inadvertedly* write a copy constructor for
it, overriding the one in that "noncopyable" class.

Of course for this to compile this person has to, if I understood
correctly, fail to call the parent class copy constructor in his own. Of
course this is a bad mistake in itself, but it might happen.

The problem is that now, by pure accident, the class has become
copyable even though it should not be, and the compiler is of no help in
catching this.

Isn't this all at the same level semantically like making class to be
non-derivable ("final")?

V

 

[peter koch]

Hallo Group Members

The following simple program allows for copying non-copyable function.

#include <boost/noncopyable.hpp>
#include <iostream>

using namespace std;

class Original: boost::noncopyable {

public:
  Original() {
    cout << "Original constructor" << endl;
  }
  Original(const Original& rhs) {
    // this definition is the reason!!!!
  }

};

int main(int argc, char *argv[])
{
  Original o;
  Original o2 = o;
  return 0;

}

Do You know how is it possible?

boost::non_copyable is simply a class that forbids copying and in
effect prevents direct copying (and copy-construction). Inheriting
from this class will thus prevent the compiler generated copy-
constructor (and assignment operator) from being generated.
But: nothing prevents you from declaring an explicit constructor:
doing so is an obfuscation and indicates that the original programmer
is quite bad.

/Peter

 

[Fraser Ross]

"Victor Bazarov"

Isn't this all at the same level semantically like making class to be
non-derivable ("final")?

Its more useful than that. Library code wouldn't want to allow classes
without copying semantics to be copied my mistake.

The final attribute doesn't actually make a class non-derivable. I
think it can be achieved when used with a virtual destructor though.

Fraser.

 

[James Kanze]

I'm not sure it's that simple. It can also be a genuine mistake.

Either the class is copiable, or it isn't. If a programmer
can't make up his mind about this, there's a serious problem.

In a long inheritance chain one of the classes buried
somewhere in there might have been made "noncopyable" for some
purpose. Then someone else might inherit from a class
inherited from a class inherited... and so on from that class,
and *inadvertedly* write a copy constructor for it, overriding
the one in that "noncopyable" class.

One can wonder about the wisdom of a long inheritance chain, but
that's not the issue. A derived class is free to offer
additional functionality, including copy, compared to what the
base class offers. I don't see where there's a problem. The
problem is if the author of the base class says both
not-copiable and copiable at the same time.

(Obviously, the derived class can only offer new functionality
if it is capable of implementing it correctly; if the base class
contains data, the derived class probably cannot implement copy
correctly. But in most cases, base classes are interfaces which
don't contain data, so this is often not a problem.)

Of course for this to compile this person has to, if I
understood correctly, fail to call the parent class copy
constructor in his own. Of course this is a bad mistake in
itself, but it might happen.

It depends. I'd guess that most of the time my derived classes
offer copy, they don't call the base class copy constructor,
since the base class is typically abstract, without data, and
doesn't guarantee copy.

The problem is that now, by pure accident, the class has
become copyable even though it should not be,

Should it, or should it not be copiable, that is the question.
The author of the derived class must know this---it's a design
decision. If it should be copiable, he'll have to implement a
copy constructor with the desired semantics. If it shouldn't,
and he implements a copy constructor, there's a serious problem.

and the compiler is of no help in catching this.

How can it be? The compiler doesn't know the intent or the
design of the class.

 

[Chris M. Thomasson]

Hallo Group Members

The following simple program allows for copying non-copyable function.

#include <boost/noncopyable.hpp>
#include <iostream>

using namespace std;

class Original: boost::noncopyable {

public:
Original() {
cout << "Original constructor" << endl;
}
Original(const Original& rhs) {
// this definition is the reason!!!!
}
};


int main(int argc, char *argv[])
{
Original o;
Original o2 = o;
return 0;
}


Do You know how is it possible?

You created an explicit public copy-constructor for `Original'.