Re: Rvalue-references, binding and conversions

From:

Dragan Milenkovic <dragan@plusplus.rs>

Newsgroups:

comp.lang.c++.moderated

Date:

Sat, 6 Dec 2008 08:32:05 CST

Message-ID:

<ghb0qo$rfk$1@aioe.org>

SG wrote:

On 4 Dez., 00:53, annamalai <annamalai.gurus...@gmail.com> wrote:

$ cat temp.cc
#include <iostream>

struct Foo {
     Foo() {}
     Foo(const Foo &) {}

};

struct Bar {
     Bar(const Foo &) {}

};

const Foo && func() { return Foo(); }

Just making sure that no one will get the idea of writing a function
like this: returning references to temporaries (including rvalue
references) has no purpose whatsoever. A use of this reference will
invoke undefined behaviour.

Your example is just as good with

const Foo func() { return Foo(); }

void dlg(Foo&& foo) {
    std::cout << "f(Foo&&)" << std::endl;

}

void dlg(Bar&& bar) {
    std::cout << "f(Bar&&)" << std::endl;

}

int main() {
     dlg( func() );}

$

Good point. I added another function:

    const Foo func1() { return Foo(); }
    Foo func2() { return Foo(); }

    int main() {
       dlg( func1() );}
       dlg( func2() );}
    }

G++ 4.3.2 in -std=c++0x mode prints:

    f(Bar&&)
    f(Foo&&)

Appearently the compiler won't create a temporary if the type (apart
from its constness) is the same. In this case f(Bar&&) will be
selected and another temporary will be created for it. I think it
makes sense because: What would be the use of references when a
temporary needs to be created?

Because those are rvalue-references... by design, they reference
temporaries...

In the 2nd case overload resolution kicks in and since f(Foo&&)
doesn't require a conversion it is selected.

I appreciate the existence of rvalue references but IMHO their should
be limited to exactly what they were designed for: move semantics and
perfect forwarding.

But would move semantics and perfect forwarding fail if things change
to allow both calls to resolve to f(Foo&&) ? I don't think so...

While testing with concepts and rvalue references
I came across this problem:

    concept VectorExpression<typename T> {};

    struct foobar {};

    concept_map VectorExpression<foobar> {};

    template<VectorExpression VE>
    void do_something(const VE &); // #1

    template<VectorExpression VE>
    void do_something(VE &&); // #2

    foobar func1();
    foobar& func2();

int main() {
    do_something(func1()); // #1 (right?)
    do_something(func2()); // #1 or #2 with VE = foobar&
}

Template parameter deduction rules try to make VE=foobar& in the 2nd
case but foobar& is not a model of the concept VectorExpression. Bam!

So, to make this work like intended we have to use a trick like CRTP
to suppress top-level template parameter deduction and hence avoid the
rule that makes perfect forwarding possible. I'm not too happy about
it.

Don't you thing these issues would keep on piling? Saying "I'm not
concerned with other uses" doesn't help. Should I ignore the issue you
had over there just because I don't need it right now? The code seems
valid... and && is created to be used for move semantics... yet again,
the example fails! Someone will eventually try to fix it and still
keep things backward compatible.

--
Best regards,
Dragan

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]