Here it goes.  Another proposal for the continually shaping standard.

I have often thought that it would be nice to somehow disallow operator=
and copy construction for a class.

There are classes (which I affectionately term "beast classes") that
contain pointers to myriad other things or are simply so large that one
would never want to make a copy of one of their objects.  In short, a
shallow copy won't do, and a deep copy is impossible or impractical.

I suppose that one could make assignment or copy construction "safe" as
follows:

    class X
    {
        // ....

        X& operator= (X& x) {return *this;}
           X         (X& x) {}
    }


But it would still be nice to get a compile-time error which indicates that
the class is not being used as it should.


I propose the following with trepidation:

    class X const
    {
        // ...
    };


Class X is now a const class.  This means that although the values of the
members of X objects may change, an object of X can not be modified by
being copied onto or assigned to by another object of class X.

One could say that class X is const at the object level.

One could also say that objects of X are const in relation other objects of X.


In the same way as

    const int a = 0, b = 0;
    a = b;

is illegal,

    X a,b;

    a = b;

is illegal if X is a const class.



Comments?



Michael Feathers      feathers@ufl.edu

You can already prohibit assignment and copy-construction (or for that
matter, any operation) in a reasonable way:

 1.  Declare the assignment operator and the copy-constructor
     as private members.

 2.  Do not implement them.

Here is an example:

 class Foo {
 public:
  Foo();
  // more stuff ...
 private:
  Foo(const Foo &);
  void operator = (const Foo &);
  // Not meaningful to implement.
 };

What happens now is that any functions "outside" class Foo will get a
compile-time error if they use any of the unwanted operations, because
they are private.  Member functions and friends of Foo will get a
link-time error, because there is no implementation.  Note that
because you have explicitly declared the functions, the compiler is
prevented from automatically generating these functions for you.

The error messages from the compiler do not say exactly why these
functions do not exist, but the comment is usually enough to make
people understand the reason.

    -- Dag

feathers@serss0 (Michael Feathers @ Florida International University, Miami) writes

 > Here it goes.  Another proposal for the continually shaping standard.

If you want to propose something see

 How to Write a C++ Language Extension Proposal
 In The C++ Report pp40-47 May 1992
 also in SIGPLAN Notices, Vol 27 No 6 June 1992 pp 64-71.

A short expression of a wish like this is not sufficient for the committee
to work on (the principle is that if you want something you should be
willing to work for it - the committee members are all volunteers and
most of them are overworked). In particular you should carefully consider
if what you ask for can be done in C++ as it exists now and what the impact
of the extension would be on existing and future programs.

 > I have often thought that it would be nice to somehow disallow operator=
 > and copy construction for a class.

So have I.

 > There are classes (which I affectionately term "beast classes") that
 > contain pointers to myriad other things or are simply so large that one
 > would never want to make a copy of one of their objects.  In short, a
 > shallow copy won't do, and a deep copy is impossible or impractical.
 >
 > I suppose that one could make assignment or copy construction "safe" as
 > follows:
 >
 >     class X
 >     {
 >         // ....
 >
 >         X& operator= (X& x) {return *this;}
 >            X         (X& x) {}
 >     }
 >
 >
 > But it would still be nice to get a compile-time error which indicates that
 > the class is not being used as it should.

Yes. Indeed, and any decent C++ textbook will tell you how to do it.
For example, see sec 7.2.2 (pg228) of The C++ Programming Language (2nd edition):

 Because of historical accident, the operators = (assignment),
 & (address-of), and , (sequencing) have predefined meanings when
 applied to class objects. These predefined meanings can be made
 inaccessible to general users by making them private:

  class X {
      // ...
  private:
      void operator=(const X&);
      void operator&();
      void operator,(const X&);
      // ...
  };

  void f(X a, X b)
  {
      a = b;  // error: operator= private
      &a;     // error: operator& private
      a,b;    // error: operator, private
  }
 Alternatively, they can be given new meanings by suitable definitions.

This does what you ask for except that it will allow the implementor of the
class to copy (iff the implementor bothers to implement these three functions)
and of course that you'll have to add the copy constructor to the set of private
functions.

 - Bjarne

feathers@serss0 (Michael Feathers) writes:

>Here it goes.  Another proposal for the continually shaping standard.

>I have often thought that it would be nice to somehow disallow operator=
>and copy construction for a class.


Would "private" unimplemented methods do the trick?



--
++harvey
===========================================================================
internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice/fax:      617-965-0220    /  617-965-7599

In article <C1suBr.Du8@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>Here it goes.  Another proposal for the continually shaping standard.
>
>I have often thought that it would be nice to somehow disallow operator=
>and copy construction for a class.
>
>There are classes (which I affectionately term "beast classes") that
>contain pointers to myriad other things or are simply so large that one
>would never want to make a copy of one of their objects.  In short, a
>shallow copy won't do, and a deep copy is impossible or impractical.

Why not make the copy constructor and assignment operator private??  Seems
like it would solve your problem.  In addition, you could provide run-time
checking so that the implementation of the class does not use the
internal methods.

TTFN
Phil