[cfe-dev] Trying to work on "C++ Type-checking for copy assignment" project

Brian Allison brian.w.allison at gmail.com
Mon May 18 06:12:17 PDT 2009


On Sat, May 16, 2009 at 2:07 PM, Vyacheslav Kononenko <
vyacheslav at kononenko.net> wrote:

> > But implicit assignment operators are not user-defined. I just wonder
> > how hard we should try in making POD types feel like built-ins.
> You mean by behavior or error message should be the same as for
> builtin? I think implicit assignment operator should provide the same
> behavior.
>
> > I'm not sure, but I don't think our lookup automatically limits it to
> > those operators that are viable for the left-hand side, so we'd have to
> > filter all others out manually. We certainly don't want every possible
> > assignment operator in that list.
> No, of course not. Only assignment operators from the class and
> parents. Yes that will require filtering the list. Another idea is to
> print "incompatible type" message when there is only one assignment
> operator available. That will require filtering that list as well.
>


I may have missed it in the discussion so far - apologies if I did.

The discussion so far *seems* to have left out the fact that if the
programmer doesn't specify a user-defined assignement operator for
class type T, then  the compiler is supposed to generate an assginment
operator. This compiler-generated assignment operator member function
then does a bitwise copy of the member data.

[  It is up to the programmer for class T to know when the
compiler-generated
assignment operator will be sufficient or not - and if they choose to use
the compiler-generated when it's not safe then they can get incorrectly
behaving code. OTOH, if they choose to always write their own, then they
may be bloating their code and slowing down fundamental operations. ]

Again, if this part of the spec *wasn't* left out (or forgotten), then
apologies
for the wasted bandwith.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090518/c70ff78a/attachment.html>


More information about the cfe-dev mailing list