jpotter@lhup.edu (John Potter) wrote in message
news:<t3aZc.10462$6o3.4957@newsread2.news.atl.earthlink.net>...
> On Tue, 31 Aug 2004 21:20:31 GMT, kanze@gabi-soft.fr wrote:

> > Off hand, I can only think of three cases where the compiler
> > provides default semantics for a user defined type: assignment, the
> > unary &, and the comma operator.  The first two must be member
> > functions if the user is to define them.  And I don't think I'd use
> > the third in any code I wanted to be readable.

> Oops on unary&.

> #include <iostream>
> class A {};
> A a;
> std::ostream& f1 (std::ostream& os) {
>     return os << &a;
>     }
> template <class T>
> int operator& (T const&) { return 42; }
> std::ostream& f2 (std::ostream& os) {
>     return os << &a;
>     }
> int main () {
>     f2(f1(std::cout) << " ") << "\n";
>     }

> Seems like all of the problems of op= are still there with op&.

So it does.  Sounds like a good reason to ban it in coding guidelines.
(I'm pretty sure I've never defined it in any of my code.)

> Just less likely that someone will do something stupid like this with
> op&.

It's probably less likely that they will override it.  On the other
hand, if they do override it, it wouldn't surprise me if they did
something stupid doing so.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly.at@xmission.dot.com (llewelly) wrote in message
news:<867jrgr261.fsf@Zorthluthik.local.bar>...
> stephen.clamage@sun.com (Steve Clamage) writes:
> [snip]
> > If you could create a non-member copy-assignment operator, you could
> > wind up (accidently or on purpose) with different parts of the
> > program having different ideas about how to perform assignment. You
> > can say it is an ODR violation, but this violation would be
> > difficult for the compiler to detect, and even more difficult for
> > the programmer to discover.
> [snip]

> Isn't this already true for ordinary functions?

If you forget to include the header with the declaration of the ordinary
function, and you try to use it, you get an error from the compiler.  If
free standing operator= were legal, and you forget to include the header
declaring it, the compiler will provide one for you.  Probably with
different semantics than the user defined one.  (Otherwise, why would
you have gone to the bother of writing it.)

Off hand, I can only think of three cases where the compiler provides
default semantics for a user defined type: assignment, the unary &, and
the comma operator.  The first two must be member functions if the user
is to define them.  And I don't think I'd use the third in any code I
wanted to be readable.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 31 Aug 2004 21:20:31 GMT, kanze@gabi-soft.fr wrote:

> Off hand, I can only think of three cases where the compiler provides
> default semantics for a user defined type: assignment, the unary &, and
> the comma operator.  The first two must be member functions if the user
> is to define them.  And I don't think I'd use the third in any code I
> wanted to be readable.

Oops on unary&.

#include <iostream>
class A {};
A a;
std::ostream& f1 (std::ostream& os) {
    return os << &a;
    }
template <class T>
int operator& (T const&) { return 42; }
std::ostream& f2 (std::ostream& os) {
    return os << &a;
    }
int main () {
    f2(f1(std::cout) << " ") << "\n";
    }

Seems like all of the problems of op= are still there with op&.
Just less likely that someone will do something stupid like this
with op&.

I leave it to others to decide whether the library error from
comeau online is a bug.

John

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

stephen.clamage@sun.com (Steve Clamage) writes:
[snip]
> If you could create a non-member copy-assignment operator, you could
> wind up (accidently or on purpose) with different parts of the program
> having different ideas about how to perform assignment. You can say it
> is an ODR violation, but this violation would be difficult for the
> compiler to detect, and even more difficult for the programmer to
> discover.
[snip]

Isn't this already true for ordinary functions?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bronek Kozicki wrote:
> All builtin assignment operators have signature similar to:
>   T& operator=(T&, const T&);
>
> However, it's impossible to define such an overload of assignment
> operator in namespace scope for classes. ...
>
> There's also asymmetry that modyfing (operator+= etc.) assignment
> operators can be defined in namespace scope.
>
> I believe that C++ standard should allow definition of assignment
> operators in namespace scope for all user defined types (compiler would
> generate assignment operator at the point of first use, if not declared
> by user till this point; if defined later or in other translation unit,
> we have violation of ODR), or at least for classes without implicit
> compiler generated operator= (see proposal N1582 by Francis Glassborow).
>
> I believe that this idea is not new - has this been considered by C++
> Standard Committee already? I could not find relevant proposal on
> Committee's site.

The reason that a copy-assignment operator must be a class member is
that assignment is pre-defined for class types. Assignment of class
objects has a defined meaning whether you provide the operator or not.

Compound assignment like += is not predefined. The operation x1+=x2 is
not allowed unless you define the operator.

If you could create a non-member copy-assignment operator, you could
wind up (accidently or on purpose) with different parts of the program
having different ideas about how to perform assignment. You can say it
is an ODR violation, but this violation would be difficult for the
compiler to detect, and even more difficult for the programmer to
discover.

That is, if the compiler-generated version is expanded inline, or the
user-written function were declared inline, there would be no
conflicts at link time. If the unexpected version of assignment were
in a library that you did not build, it would be very difficult to
find what was wrong.

I don't recall any discussion or proposals in the C++ Committee on
this topic, apart from hallway discussions. We don't document things
that were never discussed formally or proposed. :-)  Your discussion
is the first I've seen that suggested a possible benefit. The
remaining question is whether the benefits outweigh the disadvantages.

For classes such as Francis proposes, a non-member copy-assignment
operator might be reasonable -- apart from adding yet another special
case to the language.

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

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steve Clamage wrote:
> I don't recall any discussion or proposals in the C++ Committee on this
> topic, apart from hallway discussions. We don't document things that
> were never discussed formally or proposed. :-)  Your discussion is the
> first I've seen that suggested a possible benefit. The remaining
> question is whether the benefits outweigh the disadvantages.

thanks :) I will prepare proposal, then (if there's enough time before
deadline for nearest mailing).


B.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

All builtin assignment operators have signature similar to:
   T& operator=(T&, const T&);

However, it's impossible to define such an overload of assignment
operator in namespace scope for classes. Effectively, there's asymmetry
between UDT and builtin types:
   template <typename T> T f() {return T();}
   f<int>() = f<int>(); // error, assignment to rvalue
   f<MyClass>() = f<MyClass>(); // fine

There's also asymmetry that modyfing (operator+= etc.) assignment
operators can be defined in namespace scope.

I believe that C++ standard should allow definition of assignment
operators in namespace scope for all user defined types (compiler would
generate assignment operator at the point of first use, if not declared
by user till this point; if defined later or in other translation unit,
we have violation of ODR), or at least for classes without implicit
compiler generated operator= (see proposal N1582 by Francis Glassborow).

I believe that this idea is not new - has this been considered by C++
Standard Committee already? I could not find relevant proposal on
Committee's site.


B.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <69b80$412a486e$c3883115$30203@nf1.news-service-com>, Bronek
Kozicki <brok@rubikon.pl> writes
>I believe that C++ standard should allow definition of assignment
>operators in namespace scope for all user defined types (compiler would
>generate assignment operator at the point of first use, if not declared
>by user till this point; if defined later or in other translation unit,
>we have violation of ODR), or at least for classes without implicit
>compiler generated operator= (see proposal N1582 by Francis Glassborow).

That is an interesting idea, I wonder what others think. If we add
explicit classes to C++ should they be allowed to have a namespace scope
assignment operator defined?


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bronek Kozicki wrote:

> All builtin assignment operators have signature similar to:
>   T& operator=(T&, const T&);
>
> However, it's impossible to define such an overload of assignment
> operator in namespace scope for classes. Effectively, there's asymmetry
> between UDT and builtin types:
>   template <typename T> T f() {return T();}
>   f<int>() = f<int>(); // error, assignment to rvalue
>   f<MyClass>() = f<MyClass>(); // fine

I agree that this asymmetry is mildly annoying. However I do not see how
allowing the definition of operator= at namespace scope helps in
addressing this issue.

>
> There's also asymmetry that modyfing (operator+= etc.) assignment
> operators can be defined in namespace scope.
>

Modifying assignment operators are like any other "regular" operator.
Giving them "assignment" semantic is not something imposed by the
language but by coding style. You *can* define operator+= to do a
non-modifying multiplication... if you want to compete in an Obfuscated
C++ contest ;-)

OTOH, operator=(const&) is different, its semantic is standardized,
because the compiler may need to provide a default implementation. That
said, my humble opinion is that the asymmetry is justified and there is
no need to fix it.

> I believe that C++ standard should allow definition of assignment
> operators in namespace scope for all user defined types (compiler would
> generate assignment operator at the point of first use, if not declared
> by user till this point; if defined later or in other translation unit,
> we have violation of ODR), or at least for classes without implicit
> compiler generated operator= (see proposal N1582 by Francis Glassborow).

Frankly, I do not see a use case where defining a namespace scope
operator= could be of any help. Could you please provide one?

Regards,

Alberto

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]