In article <JAK.94Jul13202852@aruba.cs.brown.edu> jak@cs.brown.edu writes:
>
>I was under the impression that the compiler should generate one only if
>no user-defined operator= exists for X.
>
>The Sun compiler people say that this has changed; the rule is now that it
>should generate an operator= only if no user-defined operator= *taking
>an X* exists.

 The sections you quote, 12.8.6 and 12.8.8, no longer exist.  In
 the 27 May 94 draft of the WP, section 12.8, paragraphs 6 and 8
 say the following:

 6 The default assignment and copy constructor will be
  declared, but they will not be defined (that is, a
  function body generated) unless needed.  That is,
  X::operator=() will be generated only if no assignment
  operation is explicitly declared and an object of class
  X is assigned an object of class X or an object
  derived from X or if the address of X::operator= is
  taken.

 8 If a class has any X::operator=() that has a parameter
  of class X, the default assignment will not be generated.

Clearer?

Larry Miller  The Aerospace Corporation
lmiller@aero.org PO Box 92957
310-336-5597  LA, CA 90009-2957

>>>>> Lawrence H Miller <lmiller@aerospace.aero.org> writes:

>  6 The default assignment and copy constructor will be
>   declared, but they will not be defined (that is, a
>   function body generated) unless needed.  That is,
>   X::operator=() will be generated only if no assignment
>   operation is explicitly declared and an object of class
>   X is assigned an object of class X or an object
>   derived from X or if the address of X::operator= is
>   taken.

>  8 If a class has any X::operator=() that has a parameter
>   of class X, the default assignment will not be generated.

> Clearer?

No.  The first paragraph you quote says "only if *NO* assignment operation
is explicitly declared", and the second says "any X::operator=() that has a
parameter of class X".

The first one leads me to the conclusion that defining X::operator=(int)
suppresses generation of the default assignment operator, the second one
leads me to the conclusion that it does not.

Jason

In article <JAK.94Jul13202852@aruba.cs.brown.edu> jak@cs.brown.edu writes:
>I have a question about when the compiler should generate an operator=
>for a class X.

 So do I.
>
>I was under the impression that the compiler should generate one only if
>no user-defined operator= exists for X.
>
>The Sun compiler people say that this has changed; the rule is now that it
>should generate an operator= only if no user-defined operator= *taking
>an X* exists.
>
>The draft standard we have (Jan 94) is unclear on this point.  Section
>12.8.8 [class.copy.8] says:
>
>    If a class X has any X::operator=() that has a parameter of class X,
>    the default assignment will not be generated.

 Thats supposed to mean its signature is one of

 X::operator=(X&)
 X::operator=(X const&)
 X::operator=(X)
and possibly
 X::operator=(X const volatile&)
 X::operator=(X volatile&)

I believe -- which are called "copy assignments".
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

I have a question about when the compiler should generate an operator=
for a class X.

I was under the impression that the compiler should generate one only if
no user-defined operator= exists for X.

The Sun compiler people say that this has changed; the rule is now that it
should generate an operator= only if no user-defined operator= *taking
an X* exists.

The draft standard we have (Jan 94) is unclear on this point.  Section
12.8.8 [class.copy.8] says:

    If a class X has any X::operator=() that has a parameter of class X,
    the default assignment will not be generated.

Strictly speaking, this says nothing about the case where an operator=
taking some other type is defined (and none taking an X), though it
sounds like the intent was to assert the contrapositive too the default
assignment will be generated if a class does not have an operator=(X&).

Section 12.8.6 [class.copy.6] says:

    [...] X::operator=() will be generated only if no assignment
    operation is explictly declared [...]

Section 13.4.3 [over.ass] says:

    Unless the user defines operator= for a class X, operator= is
    defined [...]

These both state that the existence of *any* operator= for a class X
should prevent the compiler from generating an assignment operator.

So which is right?  Is there a more recent version that makes this
clearer?  Any help would be greatly appreciated.

                         Jak Kirman                        jak@cs.brown.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Never use a long word where a diminutive one will do.
                                            -- William Safire, "Fumblerules"

In article <JAK.94Jul13202852@aruba.cs.brown.edu>,
Jak Kirman <jak@cs.brown.edu> wrote:
>I have a question about when the compiler should generate an operator=
>for a class X.
>
>I was under the impression that the compiler should generate one only if
>no user-defined operator= exists for X.

No, I don't think this is the intention of the ARM.  See ARM 12.8 p297
commentary:

 class Y {
 public:
    Y& operator=(int);
    Y(int);
 };
 void f() {
     Y a = 1;
     Y b = a;   // ok [copy constructor generated]
     a = b;     // ok [assignment operator taking `const Y&' generated]
 }

>The Sun compiler people say that this has changed; the rule is now that it
>should generate an operator= only if no user-defined operator= *taking
>an X* exists.

The Sun compiler people should not be saying this has "changed".  It
hasn't -- the rule you state has been in effect since at least the ARM
printing, and I seriously doubt ANSI/ISO will change the effect of
this rule on C++ code, although they may change the terminology.

>The draft standard we have (Jan 94) is unclear on this point.  Section
>12.8.8 [class.copy.8] says:
>
>    If a class X has any X::operator=() that has a parameter of class X,
>    the default assignment will not be generated.
>
>Strictly speaking, this says nothing about the case where an operator=
>taking some other type is defined (and none taking an X), though it
>sounds like the intent was to assert the contrapositive too the default
>assignment will be generated if a class does not have an operator=(X&).

Yes, I'm sure that's it's the intent.  Hopefully the committee has
improved the wording in 12.8 to specifically refer to

  operator=([const] X&);

instead of using the more general terms "assignment operator" and
"operator=()", which could include `operator=()' functions taking
other parameters.

Jamshid Afshar
jamshid@ses.com