Thanks for the detailed replies. That was exactly the kind of
information I was looking for.

I've got a separate question on N1770. The proposed clause on
expressions (5/6) reads:

  If an expression initially has the type ``reference to T''
  (dcl.ref, dcl.init.ref), the type is adjusted to ``T'' prior to
  any further analysis and the expression designates the object or
  function denoted by the reference. The expression is considered an
  lvalue after this adjustment if the expression type was
  ``rvalue-reference to T'' and the expression is a variable
  reference, parameter reference, class member access operation
  (expr.ref), or pointer-to-member operation (expr.mptr.oper), or if
  the expression type was ``lvalue-reference to T''; otherwise, it
  is considered an rvalue.

What is the bit about pointer-to-member operations? I'd think there
could never be a pointer to member operation with the type of
``rvalue-reference to T'' since a pointer to member can't point to a
member with reference type (8.3.3/3).

- Russ

---
[ 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                       ]

Paolo Carlini wrote:
> ...
> Indeed, that is great news. I would suggest, however, using as baseline
> the current mainline compiler from CVS, not 4.0, before of course only
> the former will possibly include your work.

When I submit the patch, it'll be against CVS HEAD. I've already
started looking into that and other other patch submision guidelines. I
started with 4.0 because I wanted a stable, fixed base to work on, and
because I'm deployed to iraq at a facility with extremely limited
internet connectivity. It took me days to download the release tarball,
and I wasn't looking to complicate things further with anonymous CVS.

- Russ

---
[ 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 <1121517407.194853.244190@g14g2000cwa.googlegroups.com>,
 "Russell Yanofsky" <russell.yanofsky@us.army.mil> wrote:

> Thanks for the detailed replies. That was exactly the kind of
> information I was looking for.
>
> I've got a separate question on N1770. The proposed clause on
> expressions (5/6) reads:
>
>   If an expression initially has the type ``reference to T''
>   (dcl.ref, dcl.init.ref), the type is adjusted to ``T'' prior to
>   any further analysis and the expression designates the object or
>   function denoted by the reference. The expression is considered an
>   lvalue after this adjustment if the expression type was
>   ``rvalue-reference to T'' and the expression is a variable
>   reference, parameter reference, class member access operation
>   (expr.ref), or pointer-to-member operation (expr.mptr.oper), or if
>   the expression type was ``lvalue-reference to T''; otherwise, it
>   is considered an rvalue.
>
> What is the bit about pointer-to-member operations? I'd think there
> could never be a pointer to member operation with the type of
> ``rvalue-reference to T'' since a pointer to member can't point to a
> member with reference type (8.3.3/3).

I believe you are correct (but I could be mistaken).  The intent of 5p6
in N1770 is to implement the general notion of N1377:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Returni
ng%20A&&

> Earlier this paper proposed that:
>
>     Named rvalue references are treated as lvalues.
>
> This thought will now be completed:
>
>     Unnamed rvalue references are treated as rvalues.

That is, if a function returns an rvalue reference:

A&& foo();

then that function result is treated as an rvalue.

bar(foo()); // foo() is treated as an rvalue when
            // selecting among the overload resolution set

But rvalue references that have an identifier attached to them, such as
a function parameter, are treated as lvalues:

void foo(A&& a)
{
    // a is an lvalue here
}

The standard has no concept of "named and unnamed references", and so
the concept was translated into currently accepted standardeeze.  It is
quite possible that a bug or two crept in during that translation.
Thanks for bringing this possibility to our attention.

-Howard

---
[ 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                       ]

Howard Hinnant wrote:
> The standard has no concept of "named and unnamed references", and so
> the concept was translated into currently accepted standardeeze.  It is
> quite possible that a bug or two crept in during that translation.
> Thanks for bringing this possibility to our attention.

To be sure, I think it is a bug to say that a pointer-to-member
operation of rvalue-reference type should be treated like an lvalue,
because, to my knowledge, there is no such thing as a pointer-to-member
operation of rvalue-reference type.

- Russ

---
[ 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                       ]

I wanted to find out about the status of the rvalue reference proposal.
Has it been implemented in any real-world compiler? Is it at least
somewhat likely to make it into a future C++ language standard?

The reason I'm asking is that 3 weeks ago I downloaded a GCC 4.0
tarball and started hacking in support for n1377. At this point, I've
got what I consider the core of the proposal (parsing && types, binding
them to rvalue expressions, and using them to resolve function
overloads) implemented, though I figure I'm only about a third of the
way towards my goal of having a polished, complete patch to submit for
inclusion with GCC. Since I've never really tracked the C++
standardization process or the development of GCC, I want to make sure
I'm not wasting or duplicating effort before I go further. Any
information or words of advice would be appreciated. My current patch
for GCC is available at http://russ.hn.org/rref/

- Russ

---
[ 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 <1119033835.976169.252120@f14g2000cwb.googlegroups.com>,
 "Russell Yanofsky" <russell.yanofsky@us.army.mil> wrote:

> I wanted to find out about the status of the rvalue reference proposal.
> Has it been implemented in any real-world compiler?

Yes.  Freescale/Metrowerks CodeWarrior has a full language and library
implementation (available under a #pragma, default off), though this
product has not yet been released.  The information on when and on what
platforms it will be released is not yet publicly available.

> Is it at least
> somewhat likely to make it into a future C++ language standard?

I see that your site references the relevant papers (good).  N1770 and
N1771 are only a few months old (dated March of 2005).

At the Spring '05 meeting the proposed wording in N1770 was forwarded
from the evolution working group to the core working group.  This is a
very significant milestone towards standardization.  I am presently
cautiously optimistic that this functionality will make it into C++0X.

The evolution working group expressed some concern with how the syntax
might interact with other proposals before this working group.  However
no conflicts or problems are currently known to exist.  There is simply
concern since this small change has a very large ripple effect
throughout the language.  So I am somewhat less optimistic that N1770
will be standardized with the exact syntax proposed.

On the library side, the library working group gave a tentative nod
towards N1771 and requested more detailed proposals complete with
proposed wording.  I am currently working on those papers and hope to
have many (all?) ready for the Fall '05 meeting.

> The reason I'm asking is that 3 weeks ago I downloaded a GCC 4.0
> tarball and started hacking in support for n1377. At this point, I've
> got what I consider the core of the proposal (parsing && types, binding
> them to rvalue expressions, and using them to resolve function
> overloads) implemented, though I figure I'm only about a third of the
> way towards my goal of having a polished, complete patch to submit for
> inclusion with GCC. Since I've never really tracked the C++
> standardization process or the development of GCC, I want to make sure
> I'm not wasting or duplicating effort before I go further. Any
> information or words of advice would be appreciated. My current patch
> for GCC is available at http://russ.hn.org/rref/

Very cool!  I have heard of no others working on N1770 for gcc.  I have
heard of others working the library end, but of course limited to
library-only solutions.

-Howard

---
[ 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                       ]

Howard Hinnant wrote:
> In article <1119033835.976169.252120@f14g2000cwb.googlegroups.com>,
>  "Russell Yanofsky" <russell.yanofsky@us.army.mil> wrote:
>
> > I wanted to find out about the status of the rvalue reference proposal.
> > Has it been implemented in any real-world compiler?
>
> Yes.  Freescale/Metrowerks CodeWarrior has a full language and library
> implementation (available under a #pragma, default off), though this
> product has not yet been released.  The information on when and on what
> platforms it will be released is not yet publicly available.
>

Just a slight correction: Version 3.2 of Metrowerks C++ compiler has
supported the && reference-to-temporary syntax (enabled via a #pragma
experimental) since it shipped in late summer 2003, according to
information found in the compiler's Release Notes.

---
[ 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 <1119149945.134574.197320@z14g2000cwz.googlegroups.com>,
 "Greg" <greghe@pacbell.net> wrote:

> Howard Hinnant wrote:
> > In article <1119033835.976169.252120@f14g2000cwb.googlegroups.com>,
> >  "Russell Yanofsky" <russell.yanofsky@us.army.mil> wrote:
> >
> > > I wanted to find out about the status of the rvalue reference proposal.
> > > Has it been implemented in any real-world compiler?
> >
> > Yes.  Freescale/Metrowerks CodeWarrior has a full language and library
> > implementation (available under a #pragma, default off), though this
> > product has not yet been released.  The information on when and on what
> > platforms it will be released is not yet publicly available.
> >
>
> Just a slight correction: Version 3.2 of Metrowerks C++ compiler has
> supported the && reference-to-temporary syntax (enabled via a #pragma
> experimental) since it shipped in late summer 2003, according to
> information found in the compiler's Release Notes.

Thanks for the correction Greg.

Now for a correction to the correction: :-)

The 3.2 circa compilers have partial implementation of the rvalue
reference under #pragma experimental (maybe 50%?).  This support was
enough for me to run the experiments documented in N1377.  But some of
the behavior documented in N1377 does not agree with the behavior of the
3.2 compilers.  At that time, it simply did not make sense to invest
more in the compiler as it was too early in the proposal process.
Additionally the bundled C++ library contained only a little support for
the rvalue reference (vector and string), essentially enough to support
the documented experiments in N1377.

The (internal) 4.0 compilers have full support for N1770, which is also
very close to what is described in N1377.  And the associated library
has full support for those parts of N1771 that fall under namespace std
plus partial support for std::tr1 and Metrowerks:: components.  These
features now fall under #pragma rvalue_refs.

-Howard

---
[ 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                       ]

Howard Hinnant wrote:

>>The reason I'm asking is that 3 weeks ago I downloaded a GCC 4.0
>>tarball and started hacking in support for n1377. At this point, I've
>>got what I consider the core of the proposal (parsing && types, binding
>>them to rvalue expressions, and using them to resolve function
>>overloads) implemented, though I figure I'm only about a third of the
>>way towards my goal of having a polished, complete patch to submit for
>>inclusion with GCC. Since I've never really tracked the C++
>>standardization process or the development of GCC, I want to make sure
>>I'm not wasting or duplicating effort before I go further. Any
>>information or words of advice would be appreciated. My current patch
>>for GCC is available at http://russ.hn.org/rref/
>
> Very cool!

Indeed, that is great news. I would suggest, however, using as baseline
the current mainline compiler from CVS, not 4.0, before of course only
the former will possibly include your work.

> I have heard of no others working on N1770 for gcc.  I have
> heard of others working the library end, but of course limited to
> library-only solutions.

Right. Chris Jefferson is contributing patches for containers and
algorithms implementing a library-only form of simulated move semantics
(basically, effective for containers of containers). This work seems
also rather good in prospective, however, because the general framework
will still be useful when rvalue references will be available. If you
are curious about that, either wait a bit for it to be merged to
mainline of fetch from CVS branch libstdcxx_so_7-branch.

Thanks,
Paolo.

---
[ 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                       ]