This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] rvalue reference implementation for C++0x


"Doug Gregor" <doug.gregor@gmail.com> writes:

| On 11 Mar 2007 05:54:12 -0500, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
| > "Doug Gregor" <doug.gregor@gmail.com> writes:
| >
| > | > I think it is better to create a new type in the C++ front-end
| > |
| > | I'd recommend against this. Lvalue references and rvalue references in
| > | C++0x are identical in nearly every aspect, except that they behave
| > | differently for template argument deduction and have slightly
| > | different overloading behavior.
| >
| > That sounds to me as if it is best represented as a distinct type node.
| > Distinct notions should get distinct type nodes; each time the C++
| > front end violates that principle, it came back biting fiercely in
| > terms of complexity and bugs.
| 
| I would usually agree, but not with rvalue references.

The overload resolution process and template argument deduction rules
are central part of the compiler that I would prefer distinct notions
-- and rvalue references *are* different from references -- get
distinct node types.  
G++ has a long record of bugs related to bit fiddling for "related 
notions"; many of them got eventually fixed by introducing due
abstractions that differentiate them properly.

| The vast
| majority of uses of the word "reference" in the C++0x working paper
| just say "reference" because they apply equally to lvalue and rvalue
| references. In a few places, it says "lvalue reference" or "rvalue
| reference" specifically. So in a few places in the compiler, we
| differentiate between "lvalue reference" and "rvalue reference."

Alas, the compiler has to take care of much more details than the
Standard, in its standard hand waving, does.  If we were to consistently
follow the logic above, we should not be distinguishing between deleting
destructors and destructors, and between constructors in-charge and
constructors -- they are mentioned nowhere in the Standard.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]