Ref-qualifiers for assignment operators in the Standard Library?
Niels Dekker - no return address
Standard Library have a ref-qualifier, looking at the latest Draft,
www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf
An ref-qualifier could be helpful to prevent people from accidentally
assigning to an rvalue, as I understand from Bronek Kozicki and Daveed
Vandevoorde, www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm
For example:
//////////////////////////////////////////////////
#include <cstdlib>
struct S {
S& operator=(S const&) &; // ref-qualifier
operator bool() const;
};
S func();
int main() {
S value;
if ( func() = value ) // Error! (Typical typo.)
return EXIT_FAILURE;
return EXIT_SUCCESS;
}
//////////////////////////////////////////////////
Are those ref-qualifiers still to be added to the assignment operators
within the Library?
Kind regards,
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
daniel....@googlemail.com
<nore...@this.is.invalid> wrote:
> As far as I can see, none of the assignment operators provided by the
> Standard Library have a ref-qualifier, looking at the latest Draft,www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf
>
> An ref-qualifier could be helpful to prevent people from accidentally
> assigning to an rvalue, as I understand from Bronek Kozicki and Daveed
> Vandevoorde,www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm
>
> For example:
>
> //////////////////////////////////////////////////
> #include <cstdlib>
>
> struct S {
> S& operator=(S const&) &; // ref-qualifier
> operator bool() const;
> };
>
> S func();
>
> int main() {
> S value;
> if ( func() = value ) // Error! (Typical typo.)
> return EXIT_FAILURE;
>
> return EXIT_SUCCESS;
> }
> //////////////////////////////////////////////////
>
> Are those ref-qualifiers still to be added to the assignment operators
> within the Library?
One important use-case for ref-qualifications for basically
all member functions seem to be all atomic types in the
recent library draft. As of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2514.html
the section "Ambiguity and Insecurity" ends with the sentence:
"In summary, atomic objects are only lvalues, never rvalues."
Just my 2 Euro cents,
Daniel
Niels Dekker - no return address
>> operators within the Library?
Daniel Kruegler wrote:
>
> One important use-case for ref-qualifications for basically
> all member functions seem to be all atomic types in the
> recent library draft. As of
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2514.html
> the section "Ambiguity and Insecurity" ends with the sentence:
> "In summary, atomic objects are only lvalues, never rvalues."
Thanks for your feedback, Daniel. A preliminary version of my issue
regarding ref-qualifiers for assignment operators is now at Howard
Hinnant's preview page:
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#941
(Note: Howard's site has a new URL!) I'll add a proposed resolution
before the end of the year, listing all the relevant assignment
operators.
I didn't include your atomic-specific comment, because I think it
might be worth another issue... Basically you're saying that all
non-const member functions of an atomic type should have a
ref-qualifier (&), right? I'm not experienced with atomic types, so
maybe you can submit an LWG issue on that particular subject?
Especially, I wonder: is it okay to create an rvalue of an atomic
type? For example by static_cast<T&&>, or by std::move, or by directly
calling its default-constructor? Otherwise it might be preferable to
prevent the _creation_ of atomic rvalues, instead of preventing their
usage. What do you think?
Kind regards, Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center
--
Niels Dekker - no return address
int int_value = 42;
int() = int_value; // Invalid.
So why does it allow assigning to a temporary of a simple POD struct?
struct foo { int data; };
foo foo_value = { 42 };
foo() = foo_value; // Okay?
The latest Draft, N2800, 12.8 Copying class objects [class.copy]/10
specifies that an implicitly-declared copy assignment operator has
either one of the following two forms (depending on the definition of
the class X):
X& X::operator=(const X&)
X& X::operator=(X&)
Shouldn't such an implicitly-declared assignment operator have a
ref-qualifier (&), to prevent assigning to an rvalue?
The assignment operator was explicitly mentioned as one of the use
cases of ref-qualifiers, in "Extending Move Semantics To *this
(Revision 1)", by Daveed Vandevoorde and Bronek Kozicki:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm
Kind regards,
Niels
Niels Dekker - no return address
> Standard Library have a ref-qualifier, looking at the latest Draft,
> www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf
>
> An ref-qualifier could be helpful to prevent people from accidentally
> assigning to an rvalue, as I understand from Bronek Kozicki and Daveed
> Vandevoorde, www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm
FYI, the paper on this subject, that I wrote together with Daniel
Kruegler, has just been published, as part of the 2009 pre-Summit mailing:
"Ref-qualifiers for assignment operators of the Standard Library"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html
Kind regards, Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center
[ comp.std.c++ is moderated. To submit articles, try just posting with ]