Topic: Why must assignment operators be members?


Author: scott douglass <sdouglass%_%junk@_.arm.com>
Date: 1998/11/05
Raw View
In 13.5.3 Assignment [over.ass] the first paragraph reads:
>>
An assignment operator shall be implemented by a non-static member function with
exactly one parameter.
Because a copy assignment operator operator= is implicitly declared for a class
if not declared by the
user (12.8), a base class assignment operator is always hidden by the copy
assignment operator of the
derived class.
<<

I don't like either of these sentences much.  The first spuriously disallows:

  enum E { k0, k1, k2 };
  E& operator=(E&, int); // bounds checking or whatever
  E e;
  e = 42;

The second sentence seems to be ignoring that '+=', etc. are also assignment
operators and would not be hidden by a copy assignment operator.  I suspect
'simple assignment operator' was meant instead of 'assignment operator'.  This
would match Table 8 in section 13.3.1.2.

But that still leaves my first problem:  why should the standard disallow the
code above?

[Yes, I could wrap the enum inside a class:

  class E { enum { k0, k1, k2 }; E& operator=(int); };

but that might well make my objects larger.]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: sbnaran@fermi.ceg.uiuc.edu (Siemel Naran)
Date: 1998/11/05
Raw View
On 5 Nov 1998 18:17:36 GMT, scott douglass <sdouglass%_%junk@_.arm.com> wrote:

>  enum E { k0, k1, k2 };
>  E& operator=(E&, int); // bounds checking or whatever

I don't think that this op= is necessary anyway.  Consider this code,

enum E { k0=0x01, k1=0x02, k2=0x04 };
E e=k0|k3; // invokes operator=(E&,int)

In this case, the appropriate thing to do is to overload operator| so
that it returns not an int (the default), but rather an E.


>But that still leaves my first problem:  why should the standard disallow the
>code above?

If operator= were allowed to be a non-member, than some translation
units might use the compiler generated version, and other translation
units might use the user defined version.  But op= is such a
fundamental operation of the class that it should be subject to one
and only one definition.

Rather than change the rule on operator=, we should change the rules
on enums.  The compiler generated ctor enum(int) should be private
and accessible to only the operator functions, which should be
members.  Eg,

// original
enum E
{
     values = {k0=0x01 , k1=0x02 , k2=0x04};
     E operator|(E);
};

// after compiler generated declarations
enum E
{
     values = {k0=0x01 , k1=0x02 , k2=0x04};
     explicit E(values);     // compiler generated
     E(const E&);            // compiler generated
     E& operator=(const E&); // compiler generated
     ~E();                   // compiler generated
     E operator|(E);
     typedef char utype; // compiler generated
     static const utype mask=0x07; // compiler generated
     private: explicit E(utype); // compiler generated
};

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]