1) Shouldn't the following be considered copy constructors?

X::X(X const &&)
X::X(X const volatile &&)

They don't clobber their argument and they can match both rvalue and
lvalue arguments.

2) OTOH, should the following really be considered copy constructors?

X::(X&)
X::(X volatile &)

These do clobber their argument and should more properly be considered
move constructors.  std::auto_ptr used this form for what must be
considered a move constructor before rvalue references became available.

3) Now that rvalue references are available, why are const lvalue
references still allowed to bind to rvalues?  Is there any reason to
support this other than compatibility with existing code?

4) OTOH, why are non-const rvalue references allowed to bind directly to
lvalues?  This could inadvertently cause an lvalue to be clobbered, when
such an action was not intended.  It seems more prudent to specify that
when a non-const rvalue reference is initialized with an lvalue, a
temporary copy of the lvalue is made, the rvalue reference binds
directly to the temporary, and the copy may not be elided.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <f8cs0o$68r$1@news.inter.net.il>,
 "Ofer Porat" <oporat@yahoo.com> wrote:

> 1) Shouldn't the following be considered copy constructors?
>
> X::X(X const &&)
> X::X(X const volatile &&)
>
> They don't clobber their argument and they can match both rvalue and
> lvalue arguments.

No, they shouldn't.  Copy constructors are "special" as defined by
chapter 12.  The constructors above aren't special.

> 2) OTOH, should the following really be considered copy constructors?
>
> X::(X&)
> X::(X volatile &)
>
> These do clobber their argument and should more properly be considered
> move constructors.  std::auto_ptr used this form for what must be
> considered a move constructor before rvalue references became available.

But the current language does define them as copy constructors and are
thus chapter-12-special.

> 3) Now that rvalue references are available, why are const lvalue
> references still allowed to bind to rvalues?  Is there any reason to
> support this other than compatibility with existing code?

To support existing code that does this.  We're updating an existing
language in very widespread use.  We're not creating a new language.

Besides there are many, many use cases where one wants to bind both
lvalue and rvalues to a reference and consider it const.

class A {...};

std::ostream&
operator<<(std::ostream&& os, const A& a)
{
    return os << a.data_;
}

In the above example I don't care whether "a" bound to an lvalue or
rvalue, and I want to promise that I don't change it while I'm printing
it out.

> 4) OTOH, why are non-const rvalue references allowed to bind directly to
> lvalues?  This could inadvertently cause an lvalue to be clobbered, when
> such an action was not intended.  It seems more prudent to specify that
> when a non-const rvalue reference is initialized with an lvalue, a
> temporary copy of the lvalue is made, the rvalue reference binds
> directly to the temporary, and the copy may not be elided.

Because there are use cases where this is a useful thing to do.

class A {...};

std::ostream&
operator<<(std::ostream&& os, const A& a)
{
    return os << a.data_;
}

I want to be able to print my A to both lvalue and rvalue streams.  This
action will modify the stream, so the reference can not be const.

-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.comeaucomputing.com/csc/faq.html                      ]

On Aug 2, 6:12 pm, howard.hinn...@gmail.com (Howard Hinnant) wrote:
> In article <f8cs0o$68...@news.inter.net.il>,
>  "Ofer Porat" <opo...@yahoo.com> wrote:
>
> > 1) Shouldn't the following be considered copy constructors?
>
> > X::X(X const &&)
> > X::X(X const volatile &&)
>
> > They don't clobber their argument and they can match both rvalue and
> > lvalue arguments.
>
> No, they shouldn't.  Copy constructors are "special" as defined by
> chapter 12.  The constructors above aren't special.
>
> > 2) OTOH, should the following really be considered copy constructors?
>
> > X::(X&)
> > X::(X volatile &)
>
> > These do clobber their argument and should more properly be considered
> > move constructors.  std::auto_ptr used this form for what must be
> > considered a move constructor before rvalue references became available.
>
> But the current language does define them as copy constructors and are
> thus chapter-12-special.
>
> > 3) Now that rvalue references are available, why are const lvalue
> > references still allowed to bind to rvalues?  Is there any reason to
> > support this other than compatibility with existing code?
>
> To support existing code that does this.  We're updating an existing
> language in very widespread use.  We're not creating a new language.
>
> Besides there are many, many use cases where one wants to bind both
> lvalue and rvalues to a reference and consider it const.
>
> class A {...};
>
> std::ostream&
> operator<<(std::ostream&& os, const A& a)
> {
>     return os << a.data_;
>
> }
>
> In the above example I don't care whether "a" bound to an lvalue or
> rvalue, and I want to promise that I don't change it while I'm printing
> it out.
>
> > 4) OTOH, why are non-const rvalue references allowed to bind directly to
> > lvalues?  This could inadvertently cause an lvalue to be clobbered, when
> > such an action was not intended.  It seems more prudent to specify that
> > when a non-const rvalue reference is initialized with an lvalue, a
> > temporary copy of the lvalue is made, the rvalue reference binds
> > directly to the temporary, and the copy may not be elided.
>
> Because there are use cases where this is a useful thing to do.
>
> class A {...};
>
> std::ostream&
> operator<<(std::ostream&& os, const A& a)
> {
>     return os << a.data_;
>
> }
>
> I want to be able to print my A to both lvalue and rvalue streams.  This
> action will modify the stream, so the reference can not be const.
>
> -Howard
>
> ---
if it is not to late, I would preffer a different syntax for
hot(rvalue) refrence ,I wanna keep the boolean 'and-operator' for
probable later syntax changes because we have used the bitwise 'and-
operator' for cold(lvalue) references and we had better keep the
remaining '&&'.I would rather write:

int  int_var;//read as 'integer'
int* int_ptr;//read as 'something which is dereferenced to int'
int *& hot_int ref=int(1);//read as 'somethimg whose address is
dereferenced to int'

regards,
FM.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Aug 2, 6:12 pm, howard.hinn...@gmail.com (Howard Hinnant) wrote:
> In article <f8cs0o$68...@news.inter.net.il>,
>  "Ofer Porat" <opo...@yahoo.com> wrote:
>
> > 1) Shouldn't the following be considered copy constructors?
>
> > X::X(X const &&)
> > X::X(X const volatile &&)
>
> > They don't clobber their argument and they can match both rvalue and
> > lvalue arguments.
>
> No, they shouldn't.  Copy constructors are "special" as defined by
> chapter 12.  The constructors above aren't special.
>
> > 2) OTOH, should the following really be considered copy constructors?
>
> > X::(X&)
> > X::(X volatile &)
>
> > These do clobber their argument and should more properly be considered
> > move constructors.  std::auto_ptr used this form for what must be
> > considered a move constructor before rvalue references became available.
>
> But the current language does define them as copy constructors and are
> thus chapter-12-special.
>
> > 3) Now that rvalue references are available, why are const lvalue
> > references still allowed to bind to rvalues?  Is there any reason to
> > support this other than compatibility with existing code?
>
> To support existing code that does this.  We're updating an existing
> language in very widespread use.  We're not creating a new language.
>
> Besides there are many, many use cases where one wants to bind both
> lvalue and rvalues to a reference and consider it const.
>
> class A {...};
>
> std::ostream&
> operator<<(std::ostream&& os, const A& a)
> {
>     return os << a.data_;
>
> }
>
> In the above example I don't care whether "a" bound to an lvalue or
> rvalue, and I want to promise that I don't change it while I'm printing
> it out.
>
> > 4) OTOH, why are non-const rvalue references allowed to bind directly to
> > lvalues?  This could inadvertently cause an lvalue to be clobbered, when
> > such an action was not intended.  It seems more prudent to specify that
> > when a non-const rvalue reference is initialized with an lvalue, a
> > temporary copy of the lvalue is made, the rvalue reference binds
> > directly to the temporary, and the copy may not be elided.
>
> Because there are use cases where this is a useful thing to do.
>
> class A {...};
>
> std::ostream&
> operator<<(std::ostream&& os, const A& a)
> {
>     return os << a.data_;
>
> }
>
> I want to be able to print my A to both lvalue and rvalue streams.  This
> action will modify the stream, so the reference can not be const.
>
> -Howard
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]

I should apologize for the stupid mistake that I made in the my post a
few minutes ago;
>int *& int_hot_ref;
how could I be so silly?, it means ref to ptr to int.I am an
idiot.please forgive me.

regards,
FM.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]