Lines 1 and 2 below should not compile, should they?

class Moo
{
public:
   Moo();
   Moo(Moo& rhs);
   Moo& operator=(Moo& rhs)
   ...
};

static Moo Foo()
{
   return Moo();
}

int main(void)
{
   Moo m1 = Foo();  // 1
   m1 = Foo();          // 2
   return 0;
}

Thanks,

Vlad

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <evVx4.4085$u8.132108@newsread2.prod.itd.earthlink.net>, Vlad
Vinogradsky <vinogradsky@ibm.net> writes
>Lines 1 and 2 below should not compile, should they?

Why do you think so?
>
>class Moo
>{
>public:
>   Moo();
>   Moo(Moo& rhs);
A little unusual as a copy ctor as its parameter is non const.

>   Moo& operator=(Moo& rhs)

Likewise

>   ...
>};
>
>static Moo Foo()
>{
>   return Moo();
>}

Note that this returns by value.

>
>int main(void)
>{
>   Moo m1 = Foo();  // 1

You did not qualify the Moo ctor as explicit so in the context of
initialisation I do not see the problem. The code must behave as if you
create m1 by copying he return value of Foo()

>   m1 = Foo();          // 2

And here this simply behaves like m1.operator=(Foo()); so where is the
problem. These are not compiler generated temporaries but unnamed
instances created by the programmer.  Not, IMHO, the same thing.

>   return 0;
>}
>
>Thanks,
>
>Vlad
>
>---
>[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]
>

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I compled that codes in MSVC 6.0;
It works well.

Vlad Vinogradsky <vinogradsky@ibm.net>      (      )
news:evVx4.4085$u8.132108@newsread2.prod.itd.earthlink.net                                     .
> Lines 1 and 2 below should not compile, should they?
>
> class Moo
> {
> public:
>    Moo();
>    Moo(Moo& rhs);
>    Moo& operator=(Moo& rhs)
>    ...
> };
>
> static Moo Foo()
> {
>    return Moo();
> }
>
> int main(void)
> {
>    Moo m1 = Foo();  // 1
>    m1 = Foo();          // 2
>    return 0;
> }
>
> Thanks,
>
> Vlad
>
> ---
> [ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]
>

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Vlad Vinogradsky" <vinogradsky@ibm.net> wrote in message
news:evVx4.4085$u8.132108@newsread2.prod.itd.earthlink.net...
> Lines 1 and 2 below should not compile, should they?
>
> class Moo
> {
> public:
>    Moo();
>    Moo(Moo& rhs);
>    Moo& operator=(Moo& rhs)
>    ...
> };
>
> static Moo Foo()
> {
>    return Moo();
      ^^^^^^^^^^^ error
> }
>
> int main(void)
> {
>    Moo m1 = Foo();  // 1
>    m1 = Foo();          // 2
>    return 0;
> }
>

Not only those 2 lines, but also return Moo(); shouldn't compile because the
class doesn't have const copy constructor and assignment and temporaries
cannot be bound with non-const references.
--
Gene Bushuyev
*** If Linux is the answer, then what is the question? ***



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Vlad Vinogradsky wrote:

> Lines 1 and 2 below should not compile, should they?

Of course they should not, you are trying to bind a
non const reference to a temporary.

If you still want them to compile (as with auto_ptr), you'll
need to play the auto_ptr_ref dance.

> class Moo
> {
> public:
>    Moo();
>    Moo(Moo& rhs);
>    Moo& operator=(Moo& rhs)

> };
>
> static Moo Foo()
> {
>    return Moo();
> }
>
> int main(void)
> {
>    Moo m1 = Foo();  // 1
>    m1 = Foo();          // 2

--

Valentin Bonnard

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Vlad Vinogradsky wrote:
 > Lines 1 and 2 below should not compile, should they?

Yes, they should not.  And neither should line 0:

 > class Moo
 > {
 > public:
 >    Moo();
 >    Moo(Moo& rhs);
 >    Moo& operator=(Moo& rhs);
 >    /* ... */
 > };
 >
 > static Moo Foo()
 > {
 >    return Moo(); // 0
 > }
 >
 > int main(void)
 > {
 >    Moo m1 = Foo();  // 1
 >    m1 = Foo();          // 2
 >    return 0;
 > }

Lines 0 and 1 both try to invoke Moo::Moo(Moo&).  In both cases, the argument is a temporary object which cannot be bound to the reference to non-const.  [As everyone here probably knows, in spite of the syntax, line 1 does not involve operator=.]

Line 2 fails for the same reason as the others except that the function involved is Moo::operator=(Moo&);

It would all be fine if the 'Moo&' parameters were 'const Moo&'.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Sat, 11 Mar 2000 02:38:57 CST, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:

: In article <evVx4.4085$u8.132108@newsread2.prod.itd.earthlink.net>, Vlad
: Vinogradsky <vinogradsky@ibm.net> writes
: >Lines 1 and 2 below should not compile, should they?
:
: Why do you think so?

Didn't you say it?  Can't copy or assign an rvalue because you can't
bind a non-const reference to an rvalue.

: >class Moo
: >{
: >public:
: >   Moo();
: >   Moo(Moo& rhs);

: A little unusual as a copy ctor as its parameter is non const.

The point, can't copy an rvalue or a const lvalue.

: >   Moo& operator=(Moo& rhs)
:
: Likewise

Likewise

: >   ...
: >};
: >
: >static Moo Foo()
: >{
: >   return Moo();
: >}
:
: Note that this returns by value.

That requires a copy ctor; so, this shouldn't compile either.

: >int main(void)
: >{
: >   Moo m1 = Foo();  // 1
:
: You did not qualify the Moo ctor as explicit so in the context of
: initialisation I do not see the problem. The code must behave as if you
: create m1 by copying he return value of Foo()

Which is an rvalue.

: >   m1 = Foo();          // 2
:
: And here this simply behaves like m1.operator=(Foo()); so where is the
: problem. These are not compiler generated temporaries but unnamed
: instances created by the programmer.  Not, IMHO, the same thing.

Yes, they are rvalues.

Did I miss something?

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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:

> In article <evVx4.4085$u8.132108@newsread2.prod.itd.earthlink.net>, Vlad
> Vinogradsky <vinogradsky@ibm.net> writes
>
> >class Moo
> >{
> >public:
> >   Moo();
> >   Moo(Moo& rhs);
> >   Moo& operator=(Moo& rhs)
> >   ...
> >};
> >
> >static Moo Foo()
> >{
> >   return Moo();
> >}
> >
> >int main(void)
> >{
> >   Moo m1 = Foo();  // 1
>
> You did not qualify the Moo ctor as explicit so in the context of
> initialisation I do not see the problem. The code must behave as if you
> create m1 by copying he return value of Foo()

I don't get it. What difference would it be to qualify the Moo ctor as
explicit?
The explicit keyword is there to prevent a type to be implicitly converted to
another type by using a constructor taking one argument, but you don't have a
constructor taking another type here, except the copy ctor, taking a reference
of its own type.
A reference is, in expressions,  anyway adjusted to the type it refers to.

Line 1 is ill-formed because
Moo(Moo& rhs);
doesn't allow copying of rvalues, because you can't bind a r-value to a
non-const reference.

>   m1 = Foo();          // 2
> And here this simply behaves like m1.operator=(Foo()); so where is the
> problem. These are not compiler generated temporaries but unnamed
> instances created by the programmer.  Not, IMHO, the same thing.

Same thing here.
Moo& operator=(Moo& rhs);
doesn't allow assigning from rvalues for the same reason as above.

The row
return Moo();
is ill-formed too, since returning by value requires a suitable copy ctor,
which for the same reason as above does not exist.

-- Dag Henriksson

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38c96882.41965649@news.csrlink.net>, John Potter
<jpotter@falcon.lhup.edu> writes
>Yes, they are rvalues.
>
>Did I miss something?

No, I did because so many compilers allow explicitly created temporaries
to be passed as reference parameters, even though they reject implicit
ones.  Actually I am far from being convinced that this behaviour is
unreasonable and think that we should, at some time, revisit the issue.



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Vlad Vinogradsky wrote:

> Lines 1 and 2 below should not compile, should they?
>
> class Moo
> {
> public:
>    Moo();
>    Moo(Moo& rhs);
>    Moo& operator=(Moo& rhs)
>    ...
> };
>
> static Moo Foo()
> {
>    return Moo();
> }
>
> int main(void)
> {
>    Moo m1 = Foo();  // 1
>    m1 = Foo();          // 2
>    return 0;
> }

Why not? You make a temporary Moo m1, create an anonymous
temporary with Moo() and then invoke the assignment operator
to assign the anonymous to m1. Your assignment operator and
copy ctor should be const Moo & but otherwise things look good.

--
Jack J. Woehr                 # Ceterum censeo
PO Box 51, Golden, CO 80402   # in herbas belli
http://www.well.com/~jax/rcfb # ab idem desistamus.



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <38c96882.41965649@news.csrlink.net>, John Potter
> <jpotter@falcon.lhup.edu> writes
> >Yes, they are rvalues.
> >
> >Did I miss something?
>
> No, I did because so many compilers allow explicitly created temporaries
> to be passed as reference parameters, even though they reject implicit
> ones.  Actually I am far from being convinced that this behaviour is
> unreasonable and think that we should, at some time, revisit the issue.

But then, in which case is a temporary explicitly created?
Of course, the border cases are clear:

void foo(double&);

foo(double(3)); // explicitly created double
foo(3);         // implicitly created double

But what about:

double bar();
foo(bar()); // implicitly or explicitly created double?

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]