Topic: Default operator==() for regular types
Author: oleg.smolsky@gmail.com
Date: Fri, 20 Dec 2013 12:14:04 -0800 (PST)
Raw View
------=_Part_109_4605466.1387570444456
Content-Type: text/plain; charset=ISO-8859-1
Hi all, it seems that it would be straightforward for the C++ compiler to
emit a default version of operator==() and its inverse given that a
composite type consists of "regular" members. We even have notation for
member operator already:
struct Thing {
bool operator==(const Thing &) const = default;
...
};
The emitted code would be trivial, yet I am not sure about everything else:
- does the language grammar work with the "const"?
- is it hard to check whether members possess equality?
And then there are philosophical questions like "what about a struct that
is full of pointers"?
What do you folks think? Is this worth writing a paper?
Thanks in advance,
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_109_4605466.1387570444456
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi all, it seems that it would be straightforward for the =
C++ compiler to emit a default version of operator=3D=3D() and its inverse =
given that a composite type consists of "regular" members. We even have not=
ation for member operator already:<br><br>struct Thing {<br> bo=
ol operator=3D=3D(const Thing &) const =3D default;<br><br> =
...<br>};<br><br>The emitted code would be trivial, yet I am not sure abou=
t everything else:<br> - does the language grammar work with the "cons=
t"?<br> - is it hard to check whether members possess equality?<br><br=
>And then there are philosophical questions like "what about a struct that =
is full of pointers"?<br><br>What do you folks think? Is this worth writing=
a paper?<br><br>Thanks in advance,<br>Oleg.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_109_4605466.1387570444456--
.
Author: xavi <gratal@gmail.com>
Date: Fri, 20 Dec 2013 21:29:02 +0100
Raw View
--001a11c3ce54f9862a04edfd204a
Content-Type: text/plain; charset=ISO-8859-1
One possible problem is that the equality operator, unlike everything that
is currently generated by default, can be declared outside of the class
definition.
This might make it impossible to know if one of these "regular" members has
an equality operator defined. Unless in "regular" you don't include
aggregates, but only builtin types.
2013/12/20 <oleg.smolsky@gmail.com>
> Hi all, it seems that it would be straightforward for the C++ compiler to
> emit a default version of operator==() and its inverse given that a
> composite type consists of "regular" members. We even have notation for
> member operator already:
>
> struct Thing {
> bool operator==(const Thing &) const = default;
>
> ...
> };
>
> The emitted code would be trivial, yet I am not sure about everything else:
> - does the language grammar work with the "const"?
> - is it hard to check whether members possess equality?
>
> And then there are philosophical questions like "what about a struct that
> is full of pointers"?
>
> What do you folks think? Is this worth writing a paper?
>
> Thanks in advance,
> Oleg.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3ce54f9862a04edfd204a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One possible problem is that the equality operator, unlike=
everything that is currently generated by default, can be declared outside=
of the class definition.<div>This might make it impossible to know if one =
of these "regular" members has an equality operator defined. Unle=
ss in "regular" you don't include aggregates, but only builti=
n types.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/12=
/20 <span dir=3D"ltr"><<a href=3D"mailto:oleg.smolsky@gmail.com" target=
=3D"_blank">oleg.smolsky@gmail.com</a>></span><br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div dir=3D"ltr">Hi all, it seems that it would be straightforward for the =
C++ compiler to emit a default version of operator=3D=3D() and its inverse =
given that a composite type consists of "regular" members. We eve=
n have notation for member operator already:<br>
<br>struct Thing {<br>=A0=A0 bool operator=3D=3D(const Thing &) const =
=3D default;<br><br>=A0=A0 ...<br>};<br><br>The emitted code would be trivi=
al, yet I am not sure about everything else:<br>=A0- does the language gram=
mar work with the "const"?<br>
=A0- is it hard to check whether members possess equality?<br><br>And then =
there are philosophical questions like "what about a struct that is fu=
ll of pointers"?<br><br>What do you folks think? Is this worth writing=
a paper?<br>
<br>Thanks in advance,<br>Oleg.<span class=3D"HOEnZb"><font color=3D"#88888=
8"><br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3ce54f9862a04edfd204a--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Fri, 20 Dec 2013 15:59:25 -0800 (PST)
Raw View
------=_Part_203_13461045.1387583965775
Content-Type: text/plain; charset=ISO-8859-1
On Friday, December 20, 2013 12:29:02 PM UTC-8, Xavi Gratal wrote:
>
> One possible problem is that the equality operator, unlike everything that
> is currently generated by default, can be declared outside of the class
> definition.
> This might make it impossible to know if one of these "regular" members
> has an equality operator defined. Unless in "regular" you don't include
> aggregates, but only builtin types.
>
I don't see the problem. When the compiler sees the =default for an
equality operator, it generates the code and looks up by all the usual
rules the equality operator for each member. It'd be no different than
manually writing out the equality operator inline for each member; you
don't need to tell the compiler whether to use a free or member operator
then.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_203_13461045.1387583965775
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 20, 2013 12:29:02 PM UTC-8, Xavi Grata=
l wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">One p=
ossible problem is that the equality operator, unlike everything that is cu=
rrently generated by default, can be declared outside of the class definiti=
on.<div>This might make it impossible to know if one of these "regular" mem=
bers has an equality operator defined. Unless in "regular" you don't includ=
e aggregates, but only builtin types.</div></div></blockquote><div><br></di=
v><div>I don't see the problem. When the compiler sees the =3Ddefault=
for an equality operator, it generates the code and looks up by all the us=
ual rules the equality operator for each member. It'd be no different than =
manually writing out the equality operator inline for each member; you don'=
t need to tell the compiler whether to use a free or member operator then.<=
/div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_203_13461045.1387583965775--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Fri, 20 Dec 2013 17:33:14 -0800
Raw View
--089e011607a453adca04ee016323
Content-Type: text/plain; charset=ISO-8859-1
Then this has nothing to do with the types being "regular". You would be
asking for a memberwise comparison.
What would we expect to happen if one of the members is not comparable? Ill
formed?
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Fri, Dec 20, 2013 at 3:59 PM, Sean Middleditch <
sean.middleditch@gmail.com> wrote:
> On Friday, December 20, 2013 12:29:02 PM UTC-8, Xavi Gratal wrote:
>>
>> One possible problem is that the equality operator, unlike everything
>> that is currently generated by default, can be declared outside of the
>> class definition.
>> This might make it impossible to know if one of these "regular" members
>> has an equality operator defined. Unless in "regular" you don't include
>> aggregates, but only builtin types.
>>
>
> I don't see the problem. When the compiler sees the =default for an
> equality operator, it generates the code and looks up by all the usual
> rules the equality operator for each member. It'd be no different than
> manually writing out the equality operator inline for each member; you
> don't need to tell the compiler whether to use a free or member operator
> then.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e011607a453adca04ee016323
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Then this has nothing to do with the types being &quo=
t;regular". You would be asking for a memberwise comparison.</div><div=
><br></div><div>What would we expect to happen if one of the members is not=
comparable? Ill formed?</div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Dec 20, 2013 at 3:59 PM, Sean Mi=
ddleditch <span dir=3D"ltr"><<a href=3D"mailto:sean.middleditch@gmail.co=
m" target=3D"_blank">sean.middleditch@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div dir=3D"ltr">On Friday, December 20, 2013 12:29:02 PM UTC-8, Xavi Grata=
l wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">
<div dir=3D"ltr">One possible problem is that the equality operator, unlike=
everything that is currently generated by default, can be declared outside=
of the class definition.<div>This might make it impossible to know if one =
of these "regular" members has an equality operator defined. Unle=
ss in "regular" you don't include aggregates, but only builti=
n types.</div>
</div></blockquote><div><br></div><div>I don't see the problem. =A0When=
the compiler sees the =3Ddefault for an equality operator, it generates th=
e code and looks up by all the usual rules the equality operator for each m=
ember. It'd be no different than manually writing out the equality oper=
ator inline for each member; you don't need to tell the compiler whethe=
r to use a free or member operator then.</div>
</div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e011607a453adca04ee016323--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 20 Dec 2013 19:42:48 -0800
Raw View
On sexta-feira, 20 de dezembro de 2013 17:33:14, Billy O'Neal wrote:
> Then this has nothing to do with the types being "regular". You would be
> asking for a memberwise comparison.
>
> What would we expect to happen if one of the members is not comparable? Ill
> formed?
Yes, in the same way that the implicit default constructor cannot be generated
for a class with references as members.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 21 Dec 2013 11:53:43 +0800
Raw View
On 12/21/13 4:29 AM, xavi wrote:
> One possible problem is that the equality operator, unlike everything that
> is currently generated by default, can be declared outside of the class
> definition.
> This might make it impossible to know if one of these "regular" members has
> an equality operator defined. Unless in "regular" you don't include
> aggregates, but only builtin types.
One possible solution would be to make the implicit declaration visible
only if it were used. Already class-scope friend definitions without a
namespace-scope declaration can only be found by ADL. The implicit
operator could be implicitly declared as such, as a fallback to lookup
that already failed.
This doesn't sound like a *good* solution to me, but it may be workable.
Actually I don't like the idea of implicit equality at all, but allowing
an explicit "= default" could be reasonable.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Fri, 20 Dec 2013 22:10:28 -0800
Raw View
--e89a8ff1cbdab4167804ee0542ed
Content-Type: text/plain; charset=ISO-8859-1
Doing it implicitly would allow far too much broken code to compile -- how
many years did we have to disable C++'s automatic generation of things with
hacky workarounds? Seems a bad idea to go down that road again.
But if the designer of the type asks for it, that's an entirely different
story :)
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Fri, Dec 20, 2013 at 7:53 PM, David Krauss <potswa@gmail.com> wrote:
> On 12/21/13 4:29 AM, xavi wrote:
>
>> One possible problem is that the equality operator, unlike everything that
>> is currently generated by default, can be declared outside of the class
>> definition.
>> This might make it impossible to know if one of these "regular" members
>> has
>> an equality operator defined. Unless in "regular" you don't include
>> aggregates, but only builtin types.
>>
>
> One possible solution would be to make the implicit declaration visible
> only if it were used. Already class-scope friend definitions without a
> namespace-scope declaration can only be found by ADL. The implicit operator
> could be implicitly declared as such, as a fallback to lookup that already
> failed.
>
> This doesn't sound like a *good* solution to me, but it may be workable.
> Actually I don't like the idea of implicit equality at all, but allowing an
> explicit "= default" could be reasonable.
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--e89a8ff1cbdab4167804ee0542ed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Doing it implicitly would allow far too much broken code t=
o compile -- how many years did we have to disable C++'s automatic gene=
ration of things with hacky workarounds? Seems a bad idea to go down that r=
oad again.<div>
<br></div><div>But if the designer of the type asks for it, that's an e=
ntirely different story :)</div></div><div class=3D"gmail_extra"><br clear=
=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"h=
ttps://bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com/Bill=
yONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Dec 20, 2013 at 7:53 PM, David K=
rauss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" target=3D"_=
blank">potswa@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"im">On 12/21/13 4:29 AM, xavi wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
One possible problem is that the equality operator, unlike everything that<=
br>
is currently generated by default, can be declared outside of the class<br>
definition.<br>
This might make it impossible to know if one of these "regular" m=
embers has<br>
an equality operator defined. Unless in "regular" you don't i=
nclude<br>
aggregates, but only builtin types.<br>
</blockquote>
<br></div>
One possible solution would be to make the implicit declaration visible onl=
y if it were used. Already class-scope friend definitions without a namespa=
ce-scope declaration can only be found by ADL. The implicit operator could =
be implicitly declared as such, as a fallback to lookup that already failed=
..<br>
<br>
This doesn't sound like a *good* solution to me, but it may be workable=
.. Actually I don't like the idea of implicit equality at all, but allow=
ing an explicit "=3D default" could be reasonable.<div class=3D"H=
OEnZb">
<div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--e89a8ff1cbdab4167804ee0542ed--
.
Author: masse.nicolas@gmail.com
Date: Sat, 21 Dec 2013 08:09:34 -0800 (PST)
Raw View
------=_Part_177_9348207.1387642174197
Content-Type: text/plain; charset=ISO-8859-1
I agree on the fact that it should not be implicit.
But if the designer ask for the == operator with a default implementation,
we could assume he knows what he is doing.
Also note that this proposal can also be applied for other operators like
the "+" (wich will result in a memberwise addition) for example.
On Saturday, December 21, 2013 7:10:28 AM UTC+1, Billy O'Neal wrote:
>
> Doing it implicitly would allow far too much broken code to compile -- how
> many years did we have to disable C++'s automatic generation of things with
> hacky workarounds? Seems a bad idea to go down that road again.
>
> But if the designer of the type asks for it, that's an entirely different
> story :)
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Fri, Dec 20, 2013 at 7:53 PM, David Krauss <pot...@gmail.com<javascript:>
> > wrote:
>
>> On 12/21/13 4:29 AM, xavi wrote:
>>
>>> One possible problem is that the equality operator, unlike everything
>>> that
>>> is currently generated by default, can be declared outside of the class
>>> definition.
>>> This might make it impossible to know if one of these "regular" members
>>> has
>>> an equality operator defined. Unless in "regular" you don't include
>>> aggregates, but only builtin types.
>>>
>>
>> One possible solution would be to make the implicit declaration visible
>> only if it were used. Already class-scope friend definitions without a
>> namespace-scope declaration can only be found by ADL. The implicit operator
>> could be implicitly declared as such, as a fallback to lookup that already
>> failed.
>>
>> This doesn't sound like a *good* solution to me, but it may be workable.
>> Actually I don't like the idea of implicit equality at all, but allowing an
>> explicit "= default" could be reasonable.
>>
>>
>> --
>>
>> --- You received this message because you are subscribed to the Google
>> Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_177_9348207.1387642174197
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I agree on the fact that it should not be implicit.<b=
r></div><div>But if the designer ask for the =3D=3D operator with a default=
implementation, we could assume he knows what he is doing.</div><div>Also =
note that this proposal can also be applied for other operators like the "+=
" (wich will result in a memberwise addition) for example. </div><div>=
<br></div><br>On Saturday, December 21, 2013 7:10:28 AM UTC+1, Billy O'Neal=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Doing =
it implicitly would allow far too much broken code to compile -- how many y=
ears did we have to disable C++'s automatic generation of things with hacky=
workarounds? Seems a bad idea to go down that road again.<div>
<br></div><div>But if the designer of the type asks for it, that's an entir=
ely different story :)</div></div><div><br clear=3D"all"><div><div dir=3D"l=
tr"><div>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url=
?q\75https%3A%2F%2Fbitbucket.org%2FBillyONeal%2F\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fbitbucket.org%2FBillyONeal=
%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return=
true;">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Fstackoverflow.com%2Fusers%2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNHY_gA133vyg0yY-U2PNMVA8cCSBg';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fusers%=
2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\46usg\75AFQjCNHY_gA133vyg0yY-U2P=
NMVA8cCSBg';return true;">http://stackoverflow.com/users/82320/billy-oneal<=
/a></div><div>Malware Response Instructor - BleepingComputer.com</div></div=
></div>
<br><br><div class=3D"gmail_quote">On Fri, Dec 20, 2013 at 7:53 PM, David K=
rauss <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"FIZANvtZbMMJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">pot...@gma=
il.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 12/21/13 4:29 AM, xavi wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
One possible problem is that the equality operator, unlike everything that<=
br>
is currently generated by default, can be declared outside of the class<br>
definition.<br>
This might make it impossible to know if one of these "regular" members has=
<br>
an equality operator defined. Unless in "regular" you don't include<br>
aggregates, but only builtin types.<br>
</blockquote>
<br></div>
One possible solution would be to make the implicit declaration visible onl=
y if it were used. Already class-scope friend definitions without a namespa=
ce-scope declaration can only be found by ADL. The implicit operator could =
be implicitly declared as such, as a fallback to lookup that already failed=
..<br>
<br>
This doesn't sound like a *good* solution to me, but it may be workable. Ac=
tually I don't like the idea of implicit equality at all, but allowing an e=
xplicit "=3D default" could be reasonable.<div>
<div><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
FIZANvtZbMMJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@isocpp.org</a>=
..<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"FIZANvtZbMMJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br=
>
</div></div></blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_177_9348207.1387642174197--
.
Author: vadim.petrochenkov@gmail.com
Date: Sat, 21 Dec 2013 11:47:25 -0800 (PST)
Raw View
------=_Part_731_11783936.1387655245232
Content-Type: text/plain; charset=ISO-8859-1
Well, there is a broad class of operations which can be generated
memberwise.
Maybe Reflection study group have some general solutions for such things?
On Saturday, December 21, 2013 8:09:34 PM UTC+4, masse....@gmail.com wrote:
>
> I agree on the fact that it should not be implicit.
> But if the designer ask for the == operator with a default implementation,
> we could assume he knows what he is doing.
> Also note that this proposal can also be applied for other operators like
> the "+" (wich will result in a memberwise addition) for example.
>
>
> On Saturday, December 21, 2013 7:10:28 AM UTC+1, Billy O'Neal wrote:
>>
>> Doing it implicitly would allow far too much broken code to compile --
>> how many years did we have to disable C++'s automatic generation of things
>> with hacky workarounds? Seems a bad idea to go down that road again.
>>
>> But if the designer of the type asks for it, that's an entirely different
>> story :)
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Fri, Dec 20, 2013 at 7:53 PM, David Krauss <pot...@gmail.com> wrote:
>>
>>> On 12/21/13 4:29 AM, xavi wrote:
>>>
>>>> One possible problem is that the equality operator, unlike everything
>>>> that
>>>> is currently generated by default, can be declared outside of the class
>>>> definition.
>>>> This might make it impossible to know if one of these "regular" members
>>>> has
>>>> an equality operator defined. Unless in "regular" you don't include
>>>> aggregates, but only builtin types.
>>>>
>>>
>>> One possible solution would be to make the implicit declaration visible
>>> only if it were used. Already class-scope friend definitions without a
>>> namespace-scope declaration can only be found by ADL. The implicit operator
>>> could be implicitly declared as such, as a fallback to lookup that already
>>> failed.
>>>
>>> This doesn't sound like a *good* solution to me, but it may be workable.
>>> Actually I don't like the idea of implicit equality at all, but allowing an
>>> explicit "= default" could be reasonable.
>>>
>>>
>>> --
>>>
>>> --- You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_731_11783936.1387655245232
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Well, there is a broad class of operations which=
can be generated memberwise.<br></div><div>Maybe Reflection study group ha=
ve some general solutions for such things?</div><br>On Saturday, December 2=
1, 2013 8:09:34 PM UTC+4, masse....@gmail.com wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>I agree on the fact that it sho=
uld not be implicit.<br></div><div>But if the designer ask for the =3D=3D o=
perator with a default implementation, we could assume he knows what he is =
doing.</div><div>Also note that this proposal can also be applied for other=
operators like the "+" (wich will result in a memberwise addition) for exa=
mple. </div><div><br></div><br>On Saturday, December 21, 2013 7:10:28 =
AM UTC+1, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Doing it implicitly would allow far too much broken code to comp=
ile -- how many years did we have to disable C++'s automatic generation of =
things with hacky workarounds? Seems a bad idea to go down that road again.=
<div>
<br></div><div>But if the designer of the type asks for it, that's an entir=
ely different story :)</div></div><div><br clear=3D"all"><div><div dir=3D"l=
tr"><div>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url=
?q\75https%3A%2F%2Fbitbucket.org%2FBillyONeal%2F\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fbitbucket.org%2FBillyONeal=
%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return=
true;">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Fstackoverflow.com%2Fusers%2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNHY_gA133vyg0yY-U2PNMVA8cCSBg';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fusers%=
2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\46usg\75AFQjCNHY_gA133vyg0yY-U2P=
NMVA8cCSBg';return true;">http://stackoverflow.com/users/82320/billy-oneal<=
/a></div><div>Malware Response Instructor - BleepingComputer.com</div></div=
></div>
<br><br><div class=3D"gmail_quote">On Fri, Dec 20, 2013 at 7:53 PM, David K=
rauss <span dir=3D"ltr"><<a>pot...@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div>On 12/21/13 4:29 AM, xavi wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
One possible problem is that the equality operator, unlike everything that<=
br>
is currently generated by default, can be declared outside of the class<br>
definition.<br>
This might make it impossible to know if one of these "regular" members has=
<br>
an equality operator defined. Unless in "regular" you don't include<br>
aggregates, but only builtin types.<br>
</blockquote>
<br></div>
One possible solution would be to make the implicit declaration visible onl=
y if it were used. Already class-scope friend definitions without a namespa=
ce-scope declaration can only be found by ADL. The implicit operator could =
be implicitly declared as such, as a fallback to lookup that already failed=
..<br>
<br>
This doesn't sound like a *good* solution to me, but it may be workable. Ac=
tually I don't like the idea of implicit equality at all, but allowing an e=
xplicit "=3D default" could be reasonable.<div>
<div><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br=
>
</div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_731_11783936.1387655245232--
.
Author: oleg.smolsky@gmail.com
Date: Sat, 21 Dec 2013 12:00:45 -0800 (PST)
Raw View
------=_Part_804_14999786.1387656047037
Content-Type: text/plain; charset=ISO-8859-1
Lets not get side-tracked here with wild language features. My proposal is
for member (in)equality generation which is trivial to write by hand and,
thus, can be generated automatically. I my opinion, this is indifferent
from assignment and construction that work in this very way already.
P.S. I am not even going try imposing these things by default, as this
changes the meaning of existing code. This should be an "opt in" feature.
On Saturday, December 21, 2013 11:47:25 AM UTC-8, vadim.pet...@gmail.com
wrote:
>
> Well, there is a broad class of operations which can be generated
> memberwise.
> Maybe Reflection study group have some general solutions for such things?
>
> On Saturday, December 21, 2013 8:09:34 PM UTC+4, masse....@gmail.comwrote:
>>
>> I agree on the fact that it should not be implicit.
>> But if the designer ask for the == operator with a default
>> implementation, we could assume he knows what he is doing.
>> Also note that this proposal can also be applied for other operators like
>> the "+" (wich will result in a memberwise addition) for example.
>>
>>
>> On Saturday, December 21, 2013 7:10:28 AM UTC+1, Billy O'Neal wrote:
>>>
>>> Doing it implicitly would allow far too much broken code to compile --
>>> how many years did we have to disable C++'s automatic generation of things
>>> with hacky workarounds? Seems a bad idea to go down that road again.
>>>
>>> But if the designer of the type asks for it, that's an entirely
>>> different story :)
>>>
>>> Billy O'Neal
>>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>>> http://stackoverflow.com/users/82320/billy-oneal
>>> Malware Response Instructor - BleepingComputer.com
>>>
>>>
>>> On Fri, Dec 20, 2013 at 7:53 PM, David Krauss <pot...@gmail.com> wrote:
>>>
>>>> On 12/21/13 4:29 AM, xavi wrote:
>>>>
>>>>> One possible problem is that the equality operator, unlike everything
>>>>> that
>>>>> is currently generated by default, can be declared outside of the class
>>>>> definition.
>>>>> This might make it impossible to know if one of these "regular"
>>>>> members has
>>>>> an equality operator defined. Unless in "regular" you don't include
>>>>> aggregates, but only builtin types.
>>>>>
>>>>
>>>> One possible solution would be to make the implicit declaration visible
>>>> only if it were used. Already class-scope friend definitions without a
>>>> namespace-scope declaration can only be found by ADL. The implicit operator
>>>> could be implicitly declared as such, as a fallback to lookup that already
>>>> failed.
>>>>
>>>> This doesn't sound like a *good* solution to me, but it may be
>>>> workable. Actually I don't like the idea of implicit equality at all, but
>>>> allowing an explicit "= default" could be reasonable.
>>>>
>>>>
>>>> --
>>>>
>>>> --- You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> Visit this group at
>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>>
>>>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_804_14999786.1387656047037
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Lets not get side-tracked here with wild language features=
.. My proposal is for member (in)equality generation which is trivial to wri=
te by hand and, thus, can be generated automatically. I my opinion, this is=
indifferent from assignment and construction that work in this very way al=
ready.<br><br>P.S. I am not even going try imposing these things by default=
, as this changes the meaning of existing code. This should be an "opt in" =
feature.<br><br>On Saturday, December 21, 2013 11:47:25 AM UTC-8, vadim.pet=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Well, there is a broad class of operations which can be =
generated memberwise.<br></div><div>Maybe Reflection study group have some =
general solutions for such things?</div><br>On Saturday, December 21, 2013 =
8:09:34 PM UTC+4, <a>masse....@gmail.com</a> wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>I agree on the fact that it should no=
t be implicit.<br></div><div>But if the designer ask for the =3D=3D operato=
r with a default implementation, we could assume he knows what he is doing.=
</div><div>Also note that this proposal can also be applied for other opera=
tors like the "+" (wich will result in a memberwise addition) for example.&=
nbsp;</div><div><br></div><br>On Saturday, December 21, 2013 7:10:28 AM UTC=
+1, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">Doing it implicitly would allow far too much broken code to compile --=
how many years did we have to disable C++'s automatic generation of things=
with hacky workarounds? Seems a bad idea to go down that road again.<div>
<br></div><div>But if the designer of the type asks for it, that's an entir=
ely different story :)</div></div><div><br clear=3D"all"><div><div dir=3D"l=
tr"><div>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url=
?q\75https%3A%2F%2Fbitbucket.org%2FBillyONeal%2F\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fbitbucket.org%2FBillyONeal=
%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return=
true;">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Fstackoverflow.com%2Fusers%2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNHY_gA133vyg0yY-U2PNMVA8cCSBg';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fusers%=
2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\46usg\75AFQjCNHY_gA133vyg0yY-U2P=
NMVA8cCSBg';return true;">http://stackoverflow.com/<wbr>users/82320/billy-o=
neal</a></div><div>Malware Response Instructor - BleepingComputer.com</div>=
</div></div>
<br><br><div class=3D"gmail_quote">On Fri, Dec 20, 2013 at 7:53 PM, David K=
rauss <span dir=3D"ltr"><<a>pot...@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div>On 12/21/13 4:29 AM, xavi wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
One possible problem is that the equality operator, unlike everything that<=
br>
is currently generated by default, can be declared outside of the class<br>
definition.<br>
This might make it impossible to know if one of these "regular" members has=
<br>
an equality operator defined. Unless in "regular" you don't include<br>
aggregates, but only builtin types.<br>
</blockquote>
<br></div>
One possible solution would be to make the implicit declaration visible onl=
y if it were used. Already class-scope friend definitions without a namespa=
ce-scope declaration can only be found by ADL. The implicit operator could =
be implicitly declared as such, as a fallback to lookup that already failed=
..<br>
<br>
This doesn't sound like a *good* solution to me, but it may be workable. Ac=
tually I don't like the idea of implicit equality at all, but allowing an e=
xplicit "=3D default" could be reasonable.<div>
<div><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_804_14999786.1387656047037--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Sun, 22 Dec 2013 09:13:58 -0800 (PST)
Raw View
------=_Part_40_11160757.1387732438650
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I too thought about this a while ago, and not only for operator=3D=3D, but =
also=20
for operator<, <=3D, >, >=3D. I used to work with a codebase that had exten=
ded=20
amount of std::maps with compound keys. For each key, we had to write both=
=20
operator=3D=3D and operator< (as std::map needs that), with the following c=
ode:
struct Foo {
Member1 m1; Member2 m2; Member3 m3;
};
bool operator=3D=3D(const Foo& l, const Foo& r) {
return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m3;
}
bool operator<(const Foo& l, const Foo& r) {
bool result=3Dfalse;
result =3D result || l.m1 < r.m1;
result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2 && l.m3 < l.=
m3;
return result;
}
(I hope noone is surprised on the code). Now, operator=3D=3D is not so bad,=
but=20
operator< is horrible if you have 5+ members. We had a variadic macro to=20
get less mistakes on implementing the operators, but it is very hard to=20
make it readable, and still requires typing the member names twice.
It would be a incomparably lot cleaner if instead of the above, we could=20
just write
struct Foo {
Member1 m1; Member2 m2; Member3 m3;
};
bool operator=3D=3D(const Foo& l, const Foo& r) =3D default;
bool operator< (const Foo& l, const Foo& r) =3D default;
Or alternatively, as a member function:
struct Foo {
Member1 m1; Member2 m2; Member3 m3;
bool operator=3D=3D(const Foo& r) =3D default;
bool operator< (const Foo& r) =3D default;
};
I guess the non-member would need some reflection-like feature (I don't=20
even think the benefit of non-member comparators is that great anyway), but=
=20
the compiler has every information to generate the second.
I already see the question, in what order should operator< do the=20
comparison? I see two options:
a, same way as the constructors work.
b, implementation defined, allowing for any possible optimizations.
I actually don't care what order it is doing that, if I do, I can still=20
implement the function normally.
None of these should be implicit, explicit "=3Ddefault" should be there, to=
=20
not break any current code. I don't think tweaking lookup rules for this is=
=20
a viable alternative.
I would be more than happy to help working on such a proposal.
2013. december 21., szombat 2:33:14 UTC+1 id=C5=91pontban Billy O'Neal a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> What would we expect to happen if one of the members is not comparable?=
=20
> Ill formed?
>
That's exactly the same problem as a =3Ddefault default/copy/move=20
constructor/assignment op if one of the members don't have one. Although I=
=20
can't remember how this works for the current =3Ddefault functions, I'd say=
=20
in that case it should be just deleted to allow proper usage in class=20
templates with template-param members.
Regards, Robert
PS: Drifting away from comparisons, it can be also possible to generator=20
operator?=3D from operator? or vica versa. A default operator+ meaning=20
memberwise op+ is less useful in my opinion than having op+ generated from=
=20
op+=3D (what should be consistent) and op*=3D from op*. But this is a matte=
r of=20
another thread.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_40_11160757.1387732438650
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I too thought about this a while ago, and not only for ope=
rator=3D=3D, but=20
also for operator<, <=3D, >, >=3D. I used to work with a=20
codebase that had extended amount of std::maps with compound keys. For=20
each key, we had to write both operator=3D=3D and operator< (as std::map=
=20
needs that), with the following code:<br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Foo</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Member=
1</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m1</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Member2</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> m2</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Member3</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> m3</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><code c=
lass=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D(</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> l, const Foo& r</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> {<br> return l.m1 =3D=3D r.m1 =
&& l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m3;<br>}<br>bool opera=
tor<(const Foo& l, const Foo& r) {<br> bool re=
sult=3Dfalse;<br> result =3D result || l.m1 < r.=
m1;<br> result =3D result || l.m1 =3D=3D r.m1 && =
l.m2 < l.m2;<br> result =3D result || l.m1 =3D=
=3D r.m1 && l.m2 =3D=3D l.m2 && l.m3 < l.m3;<br>&n=
bsp; return result;<br>}<br></span><span style=3D"color: #660;"=
class=3D"styled-by-prettify"></span></code></div></code></div><br>(I
hope noone is surprised on the code). Now, operator=3D=3D is not so bad,=
=20
but operator< is horrible if you have 5+ members. We had a variadic=20
macro to get less mistakes on implementing the operators, but it is very
hard to make it readable, and still requires typing the member names=20
twice.<br><br>It would be a incomparably lot cleaner if instead of the abov=
e, we could just write<br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><code class=3D"prettyprint"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Foo</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Member1</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> m1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Member2</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> m2</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Member3</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> m3</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"></span=
></code><br><code class=3D"prettyprint"><code class=3D"prettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D=3D(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> l, const Foo& r</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> =3D default;</span></code></code><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"></span><br><code class=3D"prettyprint"><code class=
=3D"prettyprint"><code class=3D"prettyprint"><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">operator</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">< (</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> l, const Foo&=
; r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> =3D default;</s=
pan></code></code><span style=3D"color: #660;" class=3D"styled-by-prettify"=
></span></code></div></code></div><br>Or alternatively, as a member functio=
n:<br><code class=3D"prettyprint"><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><code class=3D"prettyprint"><code class=3D"prettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">Member1</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> m1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">M=
ember2</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m2<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Member3</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> m3</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span></code></code> <code class=3D"=
prettyprint"><code class=3D"prettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #=
660;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><code class=
=3D"prettyprint"><code class=3D"prettyprint"><code class=3D"prettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D=3D(</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">const Foo& r</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> =3D default;</span></code></code><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"></span><br><code class=3D=
"prettyprint"><code class=3D"prettyprint"><code class=3D"prettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify"> bool</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">< (</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">const Foo& r</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> =3D default;</span></code></code><=
/code></code></code></span></code></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><br>};</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"></span></code><br><code class=3D"prettyprint"><code cla=
ss=3D"prettyprint"><code class=3D"prettyprint"><span style=3D"color: #000;"=
class=3D"styled-by-prettify"></span></code></code></code></code><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"></span></div></code></div><=
br></span></code>I guess the non-member would need some reflection-like fea=
ture (I don't even think the benefit of non-member comparators is that grea=
t anyway), but the compiler has every information to generate the second.<b=
r><br>I already see the question, in what order should operator< do the =
comparison? I see two options:<br>a, same way as the constructors work.<br>=
b, implementation defined, allowing for any possible optimizations.<br>I ac=
tually don't care what order it is doing that, if I do, I can still impleme=
nt the function normally.<br><br>None
of these should be implicit, explicit "=3Ddefault" should be there, to=20
not break any current code. I don't think tweaking lookup rules for this
is a viable alternative.<br><code class=3D"prettyprint"><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><code c=
lass=3D"prettyprint"><code class=3D"prettyprint"><code class=3D"prettyprint=
"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span></code></code></code></code></code></span></code>I =
would be more than happy to help working on such a proposal.<br><br>2013. d=
ecember 21., szombat 2:33:14 UTC+1 id=F5pontban Billy O'Neal a k=F6vetkez=
=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>What would we expect to happen if one of the members is not comparable?=
Ill formed?</div></div></blockquote><div><br>That's
exactly the same problem as a =3Ddefault default/copy/move=20
constructor/assignment op if one of the members don't have one. Although
I can't remember how this works for the current =3Ddefault functions, I'd
say in that case it should be just deleted to allow proper usage in class=
=20
templates with template-param members.<br><br>Regards, Robert<br><br>PS: Dr=
ifting away from comparisons, it can be also possible to generator operator=
?=3D from operator? or vica versa. A default operator+ meaning memberwise o=
p+ is less useful in my opinion than having op+ generated from op+=3D (what=
should be consistent) and op*=3D from op*. But this is a matter of another=
thread.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_40_11160757.1387732438650--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Sun, 22 Dec 2013 09:58:45 -0800
Raw View
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Indeed, operator<() is the next
logical step here, and my motivation is exactly the same to what
you mentioned. This, however, moves types from "regular" to
"totally ordered" using Stepanov's terms. (btw, you can use
std::tie for implementing it).<br>
<br>
Now, back to equality. I'm trying to implement the code-gen in
Clang. If successful, I'll get a proposal number and submit a
draft for the absolute minimal feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13, R=C3=B3bert D=C3=A1vid wrote:<br>
</div>
<blockquote
cite=3D"mid:8413e21c-c13b-4419-b692-4b6907ec2db8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">I too thought about this a while ago, and not only
for operator=3D=3D, but also for operator<, <=3D, >, >=
=3D. I
used to work with a codebase that had extended amount of
std::maps with compound keys. For each key, we had to write both
operator=3D=3D and operator< (as std::map needs that), with the
following code:<br>
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
250); border-color: rgb(187, 187, 187); border-style: solid;
border-width: 1px; word-wrap: break-word;"><code
class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">struct</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #606;" class=3D"styled-by-prettify">Foo</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
=C2=A0 </span><span style=3D"color: #606;"
class=3D"styled-by-prettify">Member1</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> m1</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #606;" class=3D"styled-by-prettify">Member2=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> m2</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #606;" class=3D"styled-by-prettify">Member3=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> m3</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">};</span><span style=3D"color:
#000;" class=3D"styled-by-prettify"><br>
</span><code class=3D"prettyprint"><span style=3D"color:
#008;" class=3D"styled-by-prettify">bool</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #008;" class=3D"styled-by-prettify">opera=
tor</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D(</span><span
style=3D"color: #008;" class=3D"styled-by-prettify">const=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #606;" class=3D"styled-by-prettify">Foo</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">&=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> l,
const Foo& r</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">)</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"> {<br>
=C2=A0 return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m=
2
&& l.m3 =3D=3D r.m3;<br>
}<br>
bool operator<(const Foo& l, const Foo& r)
{<br>
=C2=A0=C2=A0=C2=A0 bool result=3Dfalse;<br>
=C2=A0=C2=A0=C2=A0 result =3D result || l.m1 <=C2=A0 r=
..m1;<br>
=C2=A0=C2=A0=C2=A0 result =3D result || l.m1 =3D=3D r.m1 =
&& l.m2
<=C2=A0 l.m2;<br>
=C2=A0=C2=A0=C2=A0 result =3D result || l.m1 =3D=3D r.m1 =
&& l.m2 =3D=3D
l.m2 && l.m3 <=C2=A0 l.m3;<br>
=C2=A0=C2=A0=C2=A0 return result;<br>
}<br>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify"></span></code></div>
</code></div>
<br>
(I hope noone is surprised on the code). Now, operator=3D=3D is not
so bad, but operator< is horrible if you have 5+ members. We
had a variadic macro to get less mistakes on implementing the
operators, but it is very hard to make it readable, and still
requires typing the member names twice.<br>
<br>
It would be a incomparably lot cleaner if instead of the above,
we could just write<br>
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
250); border-color: rgb(187, 187, 187); border-style: solid;
border-width: 1px; word-wrap: break-word;"><code
class=3D"prettyprint">
<div class=3D"subprettyprint"><code class=3D"prettyprint"><span
style=3D"color: #008;" class=3D"styled-by-prettify">struc=
t</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #606;" class=3D"styled-by-prettify">Foo</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
=C2=A0 </span><span style=3D"color: #606;"
class=3D"styled-by-prettify">Member1</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> m1</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #606;" class=3D"styled-by-prettify">Membe=
r2</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> m2</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #606;" class=3D"styled-by-prettify">Membe=
r3</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> m3</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">};</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"></spa=
n></code><br>
<code class=3D"prettyprint"><code class=3D"prettyprint"><span
style=3D"color: #008;" class=3D"styled-by-prettify">boo=
l</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span
style=3D"color: #008;" class=3D"styled-by-prettify">ope=
rator</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D(</span><span
style=3D"color: #008;" class=3D"styled-by-prettify">con=
st</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span
style=3D"color: #606;" class=3D"styled-by-prettify">Foo=
</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">&am=
p;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> l,
const Foo& r</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">)</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> =
=3D
default;</span></code></code><span style=3D"color:
#660;" class=3D"styled-by-prettify"></span><br>
<code class=3D"prettyprint"><code class=3D"prettyprint"><code
class=3D"prettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">bool</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span
style=3D"color: #008;" class=3D"styled-by-prettify">o=
perator</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;
(</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">const</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span
style=3D"color: #606;" class=3D"styled-by-prettify">F=
oo</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">
l, const Foo& r</span><span style=3D"color:
#660;" class=3D"styled-by-prettify">)</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> =
=3D
default;</span></code></code><span style=3D"color:
#660;" class=3D"styled-by-prettify"></span></code></div>
</code></div>
<br>
Or alternatively, as a member function:<br>
<code class=3D"prettyprint"><span style=3D"color: #660;"
class=3D"styled-by-prettify">
<div class=3D"prettyprint" style=3D"background-color: rgb(250,
250, 250); border-color: rgb(187, 187, 187); border-style:
solid; border-width: 1px; word-wrap: break-word;"><code
class=3D"prettyprint">
<div class=3D"subprettyprint"><code class=3D"prettyprint"><=
code
class=3D"prettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">struct</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
>
</span><span style=3D"color: #606;"
class=3D"styled-by-prettify">Foo</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">{</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>
=C2=A0 </span><span style=3D"color: #606;"
class=3D"styled-by-prettify">Member1</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
>
m1</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
>
</span><span style=3D"color: #606;"
class=3D"styled-by-prettify">Member2</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
>
m2</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
>
</span><span style=3D"color: #606;"
class=3D"styled-by-prettify">Member3</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
>
m3</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>
</span></code></code>=C2=A0 <code class=3D"prettyprin=
t"><code
class=3D"prettyprint"><span style=3D"color: #000;"
class=3D"styled-by-prettify"><code
class=3D"prettyprint"><span style=3D"color: #660;=
"
class=3D"styled-by-prettify"><code
class=3D"prettyprint"><code
class=3D"prettyprint"><code
class=3D"prettyprint"><code
class=3D"prettyprint"><span
style=3D"color: #008;"
class=3D"styled-by-prettify">bool</sp=
an><span
style=3D"color: #000;"
class=3D"styled-by-prettify"> </span>=
<span
style=3D"color: #008;"
class=3D"styled-by-prettify">operator=
</span><span
style=3D"color: #660;"
class=3D"styled-by-prettify">=3D=3D(<=
/span><span
style=3D"color: #000;"
class=3D"styled-by-prettify">const
Foo& r</span><span
style=3D"color: #660;"
class=3D"styled-by-prettify">)</span>=
<span
style=3D"color: #000;"
class=3D"styled-by-prettify"> =3D
default;</span></code></code><span
style=3D"color: #660;"
class=3D"styled-by-prettify"></span><br>
<code class=3D"prettyprint"><code
class=3D"prettyprint"><code
class=3D"prettyprint"><span
style=3D"color: #008;"
class=3D"styled-by-prettify">=C2=A0
bool</span><span style=3D"color:
#000;"
class=3D"styled-by-prettify"> </spa=
n><span
style=3D"color: #008;"
class=3D"styled-by-prettify">operat=
or</span><span
style=3D"color: #660;"
class=3D"styled-by-prettify"><
(</span><span style=3D"color:
#000;"
class=3D"styled-by-prettify">const
Foo& r</span><span
style=3D"color: #660;"
class=3D"styled-by-prettify">)</spa=
n><span
style=3D"color: #000;"
class=3D"styled-by-prettify"> =3D
default;</span></code></code></code=
></code></code></span></code></span><span
style=3D"color: #660;" class=3D"styled-by-prettify"=
><br>
};</span><span style=3D"color: #000;"
class=3D"styled-by-prettify"></span></code><br>
<code class=3D"prettyprint"><code class=3D"prettyprint"=
><code
class=3D"prettyprint"><span style=3D"color: #000;=
"
class=3D"styled-by-prettify"></span></code></co=
de></code></code><span
style=3D"color: #660;" class=3D"styled-by-prettify"></s=
pan></div>
</code></div>
<br>
</span></code>I guess the non-member would need some
reflection-like feature (I don't even think the benefit of
non-member comparators is that great anyway), but the compiler
has every information to generate the second.<br>
<br>
I already see the question, in what order should operator< do
the comparison? I see two options:<br>
a, same way as the constructors work.<br>
b, implementation defined, allowing for any possible
optimizations.<br>
I actually don't care what order it is doing that, if I do, I
can still implement the function normally.<br>
<br>
None of these should be implicit, explicit "=3Ddefault" should be
there, to not break any current code. I don't think tweaking
lookup rules for this is a viable alternative.<br>
<code class=3D"prettyprint"><span style=3D"color: #660;"
class=3D"styled-by-prettify"><code class=3D"prettyprint"><code
class=3D"prettyprint"><code class=3D"prettyprint"><code
class=3D"prettyprint"><code class=3D"prettyprint"><span
style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>
</span></code></code></code></code></code></span></co=
de>I
would be more than happy to help working on such a proposal.<br>
<br>
2013. december 21., szombat 2:33:14 UTC+1 id=C5=91pontban Billy
O'Neal a k=C3=B6vetkez=C5=91t =C3=ADrta:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir=3D"ltr">
<div>What would we expect to happen if one of the members is
not comparable? Ill formed?</div>
</div>
</blockquote>
<div><br>
That's exactly the same problem as a =3Ddefault
default/copy/move constructor/assignment op if one of the
members don't have one. Although I can't remember how this
works for the current =3Ddefault functions, I'd say in that case
it should be just deleted to allow proper usage in class
templates with template-param members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting away from comparisons, it can be also possible to
generator operator?=3D from operator? or vica versa. A default
operator+ meaning memberwise op+ is less useful in my opinion
than having op+ generated from op+=3D (what should be
consistent) and op*=3D from op*. But this is a matter of another
thread.<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
.
Author: corentin.schreiber@cea.fr
Date: Mon, 23 Dec 2013 09:17:28 -0800 (PST)
Raw View
------=_Part_162_30128898.1387819048644
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg Smolsky wrote:
>
> Indeed, operator<() is the next logical step here, and my motivation is=
=20
> exactly the same to what you mentioned. This, however, moves types from=
=20
> "regular" to "totally ordered" using Stepanov's terms. (btw, you can use=
=20
> std::tie for implementing it).
>
> Now, back to equality. I'm trying to implement the code-gen in Clang. If=
=20
> successful, I'll get a proposal number and submit a draft for the absolut=
e=20
> minimal feature.
>
> Oleg.
>
> On 2013-12-22 09:13, R=C3=B3bert D=C3=A1vid wrote:
> =20
> I too thought about this a while ago, and not only for operator=3D=3D, bu=
t=20
> also for operator<, <=3D, >, >=3D. I used to work with a codebase that ha=
d=20
> extended amount of std::maps with compound keys. For each key, we had to=
=20
> write both operator=3D=3D and operator< (as std::map needs that), with th=
e=20
> following code:
> struct Foo {
> Member1 m1; Member2 m2; Member3 m3;
> };
> bool operator=3D=3D(const Foo& l, const Foo& r) {
> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m3;
> }
> bool operator<(const Foo& l, const Foo& r) {
> bool result=3Dfalse;
> result =3D result || l.m1 < r.m1;
> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2 && l.m3 < =
l.m3;
> return result;
> }
> =20
> (I hope noone is surprised on the code). Now, operator=3D=3D is not so ba=
d,=20
> but operator< is horrible if you have 5+ members. We had a variadic macro=
=20
> to get less mistakes on implementing the operators, but it is very hard t=
o=20
> make it readable, and still requires typing the member names twice.
>
> It would be a incomparably lot cleaner if instead of the above, we could=
=20
> just write
> struct Foo {
> Member1 m1; Member2 m2; Member3 m3;
> };
> bool operator=3D=3D(const Foo& l, const Foo& r) =3D default;
> bool operator< (const Foo& l, const Foo& r) =3D default;
> =20
> Or alternatively, as a member function:
> struct Foo {
> Member1 m1; Member2 m2; Member3 m3;
> bool operator=3D=3D(const Foo& r) =3D default;
> bool operator< (const Foo& r) =3D default;
> };
> =20
> I guess the non-member would need some reflection-like feature (I don't=
=20
> even think the benefit of non-member comparators is that great anyway), b=
ut=20
> the compiler has every information to generate the second.
>
> I already see the question, in what order should operator< do the=20
> comparison? I see two options:
> a, same way as the constructors work.
> b, implementation defined, allowing for any possible optimizations.
> I actually don't care what order it is doing that, if I do, I can still=
=20
> implement the function normally.
>
> None of these should be implicit, explicit "=3Ddefault" should be there, =
to=20
> not break any current code. I don't think tweaking lookup rules for this =
is=20
> a viable alternative.
>
> I would be more than happy to help working on such a proposal.
>
> 2013. december 21., szombat 2:33:14 UTC+1 id=C5=91pontban Billy O'Neal a=
=20
> k=C3=B6vetkez=C5=91t =C3=ADrta:=20
>>
>> What would we expect to happen if one of the members is not comparable?=
=20
>> Ill formed?
>> =20
>
> That's exactly the same problem as a =3Ddefault default/copy/move=20
> constructor/assignment op if one of the members don't have one. Although =
I=20
> can't remember how this works for the current =3Ddefault functions, I'd s=
ay=20
> in that case it should be just deleted to allow proper usage in class=20
> templates with template-param members.
>
> Regards, Robert
>
> PS: Drifting away from comparisons, it can be also possible to generator=
=20
> operator?=3D from operator? or vica versa. A default operator+ meaning=20
> memberwise op+ is less useful in my opinion than having op+ generated fro=
m=20
> op+=3D (what should be consistent) and op*=3D from op*. But this is a mat=
ter of=20
> another thread.
> =20
> I think the =3Ddefault notation could be confusing if the operator is nev=
er=20
> generated implicitly, so that there is no "default" to start with. Maybe=
=20
> something like =3Dauto would be clearer.
> =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_162_30128898.1387819048644
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg Smolsk=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Indeed, operator<() is the next
logical step here, and my motivation is exactly the same to what
you mentioned. This, however, moves types from "regular" to
"totally ordered" using Stepanov's terms. (btw, you can use
std::tie for implementing it).<br>
<br>
Now, back to equality. I'm trying to implement the code-gen in
Clang. If successful, I'll get a proposal number and submit a
draft for the absolute minimal feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13, R=F3bert D=E1vid wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">I too thought about this a while ago, and not only
for operator=3D=3D, but also for operator<, <=3D, >, >=
=3D. I
used to work with a codebase that had extended amount of
std::maps with compound keys. For each key, we had to write both
operator=3D=3D and operator< (as std::map needs that), with the
following code:<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
<div><span style=3D"color:#008">struct</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#606">Foo</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br>
</span><span style=3D"color:#606">Member1</span><spa=
n style=3D"color:#000"> m1</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#606">Member2</span><span =
style=3D"color:#000"> m2</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#606">Member3</span><span st=
yle=3D"color:#000"> m3</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>
</span><span style=3D"color:#660">};</span><span style=3D"col=
or:#000"><br>
</span><code><span style=3D"color:#008">bool</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span st=
yle=3D"color:#660">=3D=3D(</span><span style=3D"color:#008">const</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#606">Foo</span><span =
style=3D"color:#660">&</span><span style=3D"color:#000"> l,
const Foo& r</span><span style=3D"color:#660">)</span=
><span style=3D"color:#000"> {<br>
return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m=
2
&& l.m3 =3D=3D r.m3;<br>
}<br>
bool operator<(const Foo& l, const Foo& r)
{<br>
bool result=3Dfalse;<br>
result =3D result || l.m1 < r=
..m1;<br>
result =3D result || l.m1 =3D=3D r.m1 =
&& l.m2
< l.m2;<br>
result =3D result || l.m1 =3D=3D r.m1 =
&& l.m2 =3D=3D
l.m2 && l.m3 < l.m3;<br>
return result;<br>
}<br>
</span><span style=3D"color:#660"></span></code></div>
</code></div>
<br>
(I hope noone is surprised on the code). Now, operator=3D=3D is not
so bad, but operator< is horrible if you have 5+ members. We
had a variadic macro to get less mistakes on implementing the
operators, but it is very hard to make it readable, and still
requires typing the member names twice.<br>
<br>
It would be a incomparably lot cleaner if instead of the above,
we could just write<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
<div><code><span style=3D"color:#008">struct</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Foo</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br>
</span><span style=3D"color:#606">Member1</span><s=
pan style=3D"color:#000"> m1</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"> </span><span style=3D"color:#606">Member2</span><spa=
n style=3D"color:#000"> m2</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#606">Member3</span><span =
style=3D"color:#000"> m3</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"><br>
</span><span style=3D"color:#660">};</span><span style=3D"c=
olor:#000"></span></code><br>
<code><code><span style=3D"color:#008">bool</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span sty=
le=3D"color:#660">=3D=3D(</span><span style=3D"color:#008">const</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#606">Foo</span><span s=
tyle=3D"color:#660">&</span><span style=3D"color:#000"> l,
const Foo& r</span><span style=3D"color:#660">)</sp=
an><span style=3D"color:#000"> =3D
default;</span></code></code><span style=3D"color:#660"=
></span><br>
<code><code><code><span style=3D"color:#008">bool</span><span=
style=3D"color:#000"> </span><span style=3D"color:#008">operator</span><sp=
an style=3D"color:#660"><
(</span><span style=3D"color:#008">const</span><span =
style=3D"color:#000"> </span><span style=3D"color:#606">Foo</span><span sty=
le=3D"color:#660">&</span><span style=3D"color:#000">
l, const Foo& r</span><span style=3D"color:#660">=
)</span><span style=3D"color:#000"> =3D
default;</span></code></code><span style=3D"color:#66=
0"></span></code></div>
</code></div>
<br>
Or alternatively, as a member function:<br>
<code><span style=3D"color:#660">
<div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><c=
ode>
<div><code><code><span style=3D"color:#008">struct</span><s=
pan style=3D"color:#000">
</span><span style=3D"color:#606">Foo</span><span sty=
le=3D"color:#000">
</span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>
</span><span style=3D"color:#606">Member1</s=
pan><span style=3D"color:#000">
m1</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000">
</span><span style=3D"color:#606">Member2</span><span=
style=3D"color:#000">
m2</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000">
</span><span style=3D"color:#606">Member3</span><span=
style=3D"color:#000">
m3</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"><br>
</span></code></code> <code><code><span style=
=3D"color:#000"><code><span style=3D"color:#660"><code><code><code><code><s=
pan style=3D"color:#008">bool</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">operator</span><span style=3D"color:#660">=3D=3D(</s=
pan><span style=3D"color:#000">const
Foo& r</span><span style=3D"color=
:#660">)</span><span style=3D"color:#000"> =3D
default;</span></code></code><span st=
yle=3D"color:#660"></span><br>
<code><code><code><span style=3D"color:#008=
">
bool</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">operator</span><span style=3D"color:#=
660"><
(</span><span style=3D"color:#000">=
const
Foo& r</span><span style=3D"col=
or:#660">)</span><span style=3D"color:#000"> =3D
default;</span></code></code></code=
></code></code></span></code></span><span style=3D"color:#660"><br>
};</span><span style=3D"color:#000"></span></code><=
br>
<code><code><code><span style=3D"color:#000"></span></c=
ode></code></code></code><span style=3D"color:#660"></span></div>
</code></div>
<br>
</span></code>I guess the non-member would need some
reflection-like feature (I don't even think the benefit of
non-member comparators is that great anyway), but the compiler
has every information to generate the second.<br>
<br>
I already see the question, in what order should operator< do
the comparison? I see two options:<br>
a, same way as the constructors work.<br>
b, implementation defined, allowing for any possible
optimizations.<br>
I actually don't care what order it is doing that, if I do, I
can still implement the function normally.<br>
<br>
None of these should be implicit, explicit "=3Ddefault" should be
there, to not break any current code. I don't think tweaking
lookup rules for this is a viable alternative.<br>
<code><span style=3D"color:#660"><code><code><code><code><code><spa=
n style=3D"color:#000"><br>
</span></code></code></code></code></code></span></co=
de>I
would be more than happy to help working on such a proposal.<br>
<br>
2013. december 21., szombat 2:33:14 UTC+1 id=F5pontban Billy
O'Neal a k=F6vetkez=F5t =EDrta:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>What would we expect to happen if one of the members is
not comparable? Ill formed?</div>
</div>
</blockquote>
<div><br>
That's exactly the same problem as a =3Ddefault
default/copy/move constructor/assignment op if one of the
members don't have one. Although I can't remember how this
works for the current =3Ddefault functions, I'd say in that case
it should be just deleted to allow proper usage in class
templates with template-param members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting away from comparisons, it can be also possible to
generator operator?=3D from operator? or vica versa. A default
operator+ meaning memberwise op+ is less useful in my opinion
than having op+ generated from op+=3D (what should be
consistent) and op*=3D from op*. But this is a matter of another
thread.<br>
</div>
</div>
</blockquote>I think the =3Ddefault notation could be confusing if the =
operator is never generated implicitly, so that there is no "default" to st=
art with. Maybe something like =3Dauto would be clearer.<br>
</div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_162_30128898.1387819048644--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 23 Dec 2013 10:16:04 -0800
Raw View
--089e0116167e584eb204ee37a15b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
operator=3D=3D is unambiguous because one can always fall back to memberwis=
e
comparison, and there are no constraints on ordering. operator< is a
tougher sell because the order by which the members would be compared isn't
obvious, but has a big impact on lexicographic ordering of the types.
Rather than an =3Ddefault for that, I think a library makes more sense.
Something like:
class lexicographical_less
{
bool isLess;
bool isKnown;
public:
lexicographical_less() : isLess(false), isKnown(false) {}
lexicographical_less(lexicographical_less const&) =3D delete;
lexicographical_less& operator=3D(lexicographical_less const&) =3D dele=
te;
template <typename Left, typename Right>
lexicographical_less& add(Left const& lhs, Right const& rhs)
{
if (isKnown || lhs =3D=3D rhs) return;
isKnown =3D true;
isLess =3D lhs < rhs;
return *this;
}
bool get() const
{
return isKnown && isLess;
}
};
class client
{
Member1 m1; Member2 m2; Member3 m3;
public:
bool operator<(client const& rhs) const // as usual
{
return lexicographical_less().add(m1, rhs.m1).add(m2,
rhs.m2).add(m3m, rhs.m3).get();
}
};
Here the type designer explicitly declares the less-than comparison order.
(Plus, this requires no new additions to the core language)
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Dec 23, 2013 at 9:17 AM, <corentin.schreiber@cea.fr> wrote:
> On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg Smolsky wrote:
>
>> Indeed, operator<() is the next logical step here, and my motivation is
>> exactly the same to what you mentioned. This, however, moves types from
>> "regular" to "totally ordered" using Stepanov's terms. (btw, you can use
>> std::tie for implementing it).
>>
>> Now, back to equality. I'm trying to implement the code-gen in Clang. If
>> successful, I'll get a proposal number and submit a draft for the absolu=
te
>> minimal feature.
>>
>> Oleg.
>>
>> On 2013-12-22 09:13, R=C3=B3bert D=C3=A1vid wrote:
>>
>> I too thought about this a while ago, and not only for operator=3D=3D, b=
ut
>> also for operator<, <=3D, >, >=3D. I used to work with a codebase that h=
ad
>> extended amount of std::maps with compound keys. For each key, we had to
>> write both operator=3D=3D and operator< (as std::map needs that), with t=
he
>> following code:
>> struct Foo {
>> Member1 m1; Member2 m2; Member3 m3;
>> };
>> bool operator=3D=3D(const Foo& l, const Foo& r) {
>> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m3;
>> }
>> bool operator<(const Foo& l, const Foo& r) {
>> bool result=3Dfalse;
>> result =3D result || l.m1 < r.m1;
>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2 && l.m3 < =
l.m3;
>> return result;
>> }
>>
>> (I hope noone is surprised on the code). Now, operator=3D=3D is not so b=
ad,
>> but operator< is horrible if you have 5+ members. We had a variadic macr=
o
>> to get less mistakes on implementing the operators, but it is very hard =
to
>> make it readable, and still requires typing the member names twice.
>>
>> It would be a incomparably lot cleaner if instead of the above, we could
>> just write
>> struct Foo {
>> Member1 m1; Member2 m2; Member3 m3;
>> };
>> bool operator=3D=3D(const Foo& l, const Foo& r) =3D default;
>> bool operator< (const Foo& l, const Foo& r) =3D default;
>>
>> Or alternatively, as a member function:
>> struct Foo {
>> Member1 m1; Member2 m2; Member3 m3;
>> bool operator=3D=3D(const Foo& r) =3D default;
>> bool operator< (const Foo& r) =3D default;
>> };
>>
>> I guess the non-member would need some reflection-like feature (I don't
>> even think the benefit of non-member comparators is that great anyway), =
but
>> the compiler has every information to generate the second.
>>
>> I already see the question, in what order should operator< do the
>> comparison? I see two options:
>> a, same way as the constructors work.
>> b, implementation defined, allowing for any possible optimizations.
>> I actually don't care what order it is doing that, if I do, I can still
>> implement the function normally.
>>
>> None of these should be implicit, explicit "=3Ddefault" should be there,=
to
>> not break any current code. I don't think tweaking lookup rules for this=
is
>> a viable alternative.
>>
>> I would be more than happy to help working on such a proposal.
>>
>> 2013. december 21., szombat 2:33:14 UTC+1 id=C5=91pontban Billy O'Neal a
>> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>>
>>> What would we expect to happen if one of the members is not
>>> comparable? Ill formed?
>>>
>>
>> That's exactly the same problem as a =3Ddefault default/copy/move
>> constructor/assignment op if one of the members don't have one. Although=
I
>> can't remember how this works for the current =3Ddefault functions, I'd =
say
>> in that case it should be just deleted to allow proper usage in class
>> templates with template-param members.
>>
>> Regards, Robert
>>
>> PS: Drifting away from comparisons, it can be also possible to generator
>> operator?=3D from operator? or vica versa. A default operator+ meaning
>> memberwise op+ is less useful in my opinion than having op+ generated fr=
om
>> op+=3D (what should be consistent) and op*=3D from op*. But this is a ma=
tter of
>> another thread.
>>
>> I think the =3Ddefault notation could be confusing if the operator is ne=
ver
>> generated implicitly, so that there is no "default" to start with. Maybe
>> something like =3Dauto would be clearer.
>>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e0116167e584eb204ee37a15b
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>operator=3D=3D is unambiguous because one can always =
fall back to memberwise comparison, and there are no constraints on orderin=
g. operator< is a tougher sell because the order by which the members wo=
uld be compared isn't obvious, but has a big impact on lexicographic or=
dering of the types.</div>
<div><br></div><div>Rather than an =3Ddefault for that,=A0I think a library=
makes more sense. Something like:</div><div><br></div><div><font face=3D"c=
ourier new,monospace">class lexicographical_less<br>{<br>=A0=A0=A0 bool isL=
ess;<br>
=A0=A0=A0 bool isKnown;<br>public:<br>=A0=A0=A0 lexicographical_less() : is=
Less(false), isKnown(false) {}<br>=A0=A0=A0 lexicographical_less(lexicograp=
hical_less const&) =3D delete;<br>=A0=A0=A0 lexicographical_less& o=
perator=3D(lexicographical_less const&) =3D delete;<br>
=A0=A0=A0 template <typename Left, typename Right><br>=A0=A0=A0 lexic=
ographical_less& add(Left const& lhs, Right const& rhs)<br>=A0=
=A0=A0 {<br>=A0=A0=A0=A0=A0=A0=A0 if (isKnown || lhs =3D=3D rhs) return;<br=
>=A0=A0=A0=A0=A0=A0=A0 isKnown =3D true;<br>=A0=A0=A0=A0=A0=A0=A0 isLess =
=3D lhs < rhs;<br>
=A0=A0=A0=A0=A0=A0=A0 return *this;<br>=A0=A0=A0 }<br>=A0=A0=A0 bool get() =
const<br>=A0=A0=A0 {<br>=A0=A0=A0=A0=A0=A0=A0 return isKnown && isL=
ess;<br>=A0=A0=A0 }<br>};</font></div><div><font face=3D"courier new,monosp=
ace">class client<br>{<br>=A0=A0=A0 Member1 m1; Member2 m2; Member3 m3;<br>
public:<br>=A0=A0=A0 bool operator<(client const& rhs) const // as u=
sual<br>=A0=A0=A0 {<br>=A0=A0=A0=A0=A0=A0=A0 return lexicographical_less().=
add(m1, rhs.m1).add(m2, rhs.m2).add(m3m, rhs.m3).get();<br>=A0=A0=A0 }<br>}=
;</font></div><div><br></div>
<div>Here the type designer explicitly declares the less-than comparison or=
der. (Plus, this requires no new additions to the core language)<br></div><=
/div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><di=
v>
Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" ta=
rget=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"htt=
p://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://sta=
ckoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 9:17 AM, <span =
dir=3D"ltr"><<a href=3D"mailto:corentin.schreiber@cea.fr" target=3D"_bla=
nk">corentin.schreiber@cea.fr</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<div dir=3D"ltr"><div><div class=3D"h5">On Sunday, December 22, 2013 6:58:4=
5 PM UTC+1, Oleg Smolsky wrote:</div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(=
204,204,204);border-left-width:1px;border-left-style:solid">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><div><div class=3D"h5">
<div>Indeed, operator<() is the next
logical step here, and my motivation is exactly the same to what
you mentioned. This, however, moves types from "regular" to
"totally ordered" using Stepanov's terms. (btw, you can=
use
std::tie for implementing it).<br>
<br>
Now, back to equality. I'm trying to implement the code-gen in
Clang. If successful, I'll get a proposal number and submit a
draft for the absolute minimal feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13, R=F3bert D=E1vid wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">I too thought about this a while ago, and not only
for operator=3D=3D, but also for operator<, <=3D, >, >=
=3D. I
used to work with a codebase that had extended amount of
std::maps with compound keys. For each key, we had to write both
operator=3D=3D and operator< (as std::map needs that), with the
following code:<br>
<div style=3D"border:1px solid rgb(187,187,187);background-color:rg=
b(250,250,250)"><code>
<div><span style=3D"color:rgb(0,0,136)">struct</span><span> </s=
pan><span style=3D"color:rgb(102,0,102)">Foo</span><span> </span><span styl=
e=3D"color:rgb(102,102,0)">{</span><span><br>
=A0 </span><span style=3D"color:rgb(102,0,102)">Member1</sp=
an><span> m1</span><span style=3D"color:rgb(102,102,0)">;</span><span> </sp=
an><span style=3D"color:rgb(102,0,102)">Member2</span><span> m2</span><span=
style=3D"color:rgb(102,102,0)">;</span><span> </span><span style=3D"color:=
rgb(102,0,102)">Member3</span><span> m3</span><span style=3D"color:rgb(102,=
102,0)">;</span><span><br>
</span><span style=3D"color:rgb(102,102,0)">};</span><span><b=
r>
</span><code><span style=3D"color:rgb(0,0,136)">bool</span><s=
pan> </span><span style=3D"color:rgb(0,0,136)">operator</span><span style=
=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,136)">=
const</span><span> </span><span style=3D"color:rgb(102,0,102)">Foo</span><s=
pan style=3D"color:rgb(102,102,0)">&</span><span> l,
const Foo& r</span><span style=3D"color:rgb(102,102,0=
)">)</span><span> {<br>
=A0 return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2
&& l.m3 =3D=3D r.m3;<br>
}<br>
bool operator<(const Foo& l, const Foo& r)
{<br>
=A0=A0=A0 bool result=3Dfalse;<br>
=A0=A0=A0 result =3D result || l.m1 <=A0 r.m1;<br>
=A0=A0=A0 result =3D result || l.m1 =3D=3D r.m1 &&=
; l.m2
<=A0 l.m2;<br>
=A0=A0=A0 result =3D result || l.m1 =3D=3D r.m1 &&=
; l.m2 =3D=3D
l.m2 && l.m3 <=A0 l.m3;<br>
=A0=A0=A0 return result;<br>
}<br>
</span><span style=3D"color:rgb(102,102,0)"></span></code><=
/div>
</code></div>
<br>
(I hope noone is surprised on the code). Now, operator=3D=3D is not
so bad, but operator< is horrible if you have 5+ members. We
had a variadic macro to get less mistakes on implementing the
operators, but it is very hard to make it readable, and still
requires typing the member names twice.<br>
<br>
It would be a incomparably lot cleaner if instead of the above,
we could just write<br>
<div style=3D"border:1px solid rgb(187,187,187);background-color:rg=
b(250,250,250)"><code>
<div><code><span style=3D"color:rgb(0,0,136)">struct</span><spa=
n> </span><span style=3D"color:rgb(102,0,102)">Foo</span><span> </span><spa=
n style=3D"color:rgb(102,102,0)">{</span><span><br>
=A0 </span><span style=3D"color:rgb(102,0,102)">Member1</=
span><span> m1</span><span style=3D"color:rgb(102,102,0)">;</span><span> </=
span><span style=3D"color:rgb(102,0,102)">Member2</span><span> m2</span><sp=
an style=3D"color:rgb(102,102,0)">;</span><span> </span><span style=3D"colo=
r:rgb(102,0,102)">Member3</span><span> m3</span><span style=3D"color:rgb(10=
2,102,0)">;</span><span><br>
</span><span style=3D"color:rgb(102,102,0)">};</span><span>=
</span></code><br>
<code><code><span style=3D"color:rgb(0,0,136)">bool</span><sp=
an> </span><span style=3D"color:rgb(0,0,136)">operator</span><span style=3D=
"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,136)">con=
st</span><span> </span><span style=3D"color:rgb(102,0,102)">Foo</span><span=
style=3D"color:rgb(102,102,0)">&</span><span> l,
const Foo& r</span><span style=3D"color:rgb(102,102=
,0)">)</span><span> =3D
default;</span></code></code><span style=3D"color:rgb(1=
02,102,0)"></span><br>
<code><code><code><span style=3D"color:rgb(0,0,136)">bool</sp=
an><span> </span><span style=3D"color:rgb(0,0,136)">operator</span><span st=
yle=3D"color:rgb(102,102,0)"><
(</span><span style=3D"color:rgb(0,0,136)">const</spa=
n><span> </span><span style=3D"color:rgb(102,0,102)">Foo</span><span style=
=3D"color:rgb(102,102,0)">&</span><span>
l, const Foo& r</span><span style=3D"color:rgb(10=
2,102,0)">)</span><span> =3D
default;</span></code></code><span style=3D"color:rgb=
(102,102,0)"></span></code></div>
</code></div>
<br>
Or alternatively, as a member function:<br>
<code><span style=3D"color:rgb(102,102,0)">
<div style=3D"border:1px solid rgb(187,187,187);background-colo=
r:rgb(250,250,250)"><code>
<div><code><code><span style=3D"color:rgb(0,0,136)">struct<=
/span><span style=3D"color:rgb(0,0,0)">
</span><span style=3D"color:rgb(102,0,102)">Foo</span=
><span style=3D"color:rgb(0,0,0)">
</span><span style=3D"color:rgb(102,102,0)">{</span><=
span style=3D"color:rgb(0,0,0)"><br>
=A0 </span><span style=3D"color:rgb(102,0,102)">Mem=
ber1</span><span style=3D"color:rgb(0,0,0)">
m1</span><span style=3D"color:rgb(102,102,0)">;</sp=
an><span style=3D"color:rgb(0,0,0)">
</span><span style=3D"color:rgb(102,0,102)">Member2</=
span><span style=3D"color:rgb(0,0,0)">
m2</span><span style=3D"color:rgb(102,102,0)">;</sp=
an><span style=3D"color:rgb(0,0,0)">
</span><span style=3D"color:rgb(102,0,102)">Member3</=
span><span style=3D"color:rgb(0,0,0)">
m3</span><span style=3D"color:rgb(102,102,0)">;</sp=
an><span style=3D"color:rgb(0,0,0)"><br>
</span></code></code>=A0 <code><code><span style=3D"c=
olor:rgb(0,0,0)"><code><span style=3D"color:rgb(102,102,0)"><code><code><co=
de><code><span style=3D"color:rgb(0,0,136)">bool</span><span style=3D"color=
:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">operator</span><spa=
n style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0=
,0)">const
Foo& r</span><span style=3D"color=
:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> =3D
default;</span></code></code><span st=
yle=3D"color:rgb(102,102,0)"></span><br>
<code><code><code><span style=3D"color:rgb(=
0,0,136)">=A0
bool</span><span style=3D"color:rgb=
(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">operator</span><span st=
yle=3D"color:rgb(102,102,0)"><
(</span><span style=3D"color:rgb(0,=
0,0)">const
Foo& r</span><span style=3D"col=
or:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> =3D
default;</span></code></code></code=
></code></code></span></code></span><span style=3D"color:rgb(102,102,0)"><b=
r>
};</span><span style=3D"color:rgb(0,0,0)"></span></=
code><br>
<code><code><code><span style=3D"color:rgb(0,0,0)"></sp=
an></code></code></code></code><span style=3D"color:rgb(102,102,0)"></span>=
</div>
</code></div>
<br>
</span></code>I guess the non-member would need some
reflection-like feature (I don't even think the benefit of
non-member comparators is that great anyway), but the compiler
has every information to generate the second.<br>
<br>
I already see the question, in what order should operator< do
the comparison? I see two options:<br>
a, same way as the constructors work.<br>
b, implementation defined, allowing for any possible
optimizations.<br>
I actually don't care what order it is doing that, if I do, I
can still implement the function normally.<br>
<br>
None of these should be implicit, explicit "=3Ddefault" s=
hould be
there, to not break any current code. I don't think tweaking
lookup rules for this is a viable alternative.<br>
<code><span style=3D"color:rgb(102,102,0)"><code><code><code><code>=
<code><span style=3D"color:rgb(0,0,0)"><br>
</span></code></code></code></code></code></span></co=
de>I
would be more than happy to help working on such a proposal.<br>
<br>
2013. december 21., szombat 2:33:14 UTC+1 id=F5pontban Billy
O'Neal a k=F6vetkez=F5t =EDrta:
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">
<div dir=3D"ltr">
<div>What would we expect to happen if one of the members is
not comparable? Ill formed?</div>
</div>
</blockquote>
<div><br>
That's exactly the same problem as a =3Ddefault
default/copy/move constructor/assignment op if one of the
members don't have one. Although I can't remember how thi=
s
works for the current =3Ddefault functions, I'd say in that c=
ase
it should be just deleted to allow proper usage in class
templates with template-param members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting away from comparisons, it can be also possible to
generator operator?=3D from operator? or vica versa. A default
operator+ meaning memberwise op+ is less useful in my opinion
than having op+ generated from op+=3D (what should be
consistent) and op*=3D from op*. But this is a matter of another
thread.<br>
</div>
</div>
</blockquote></div></div>I think the =3Ddefault notation could be confu=
sing if the operator is never generated implicitly, so that there is no &qu=
ot;default" to start with. Maybe something like =3Dauto would be clear=
er.<br>
</div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0116167e584eb204ee37a15b--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Mon, 23 Dec 2013 10:23:05 -0800
Raw View
This is a multi-part message in MIME format.
--------------090003070504080504040600
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: quoted-printable
Hey Billy, I believe this is already present in C++11:
http://en.cppreference.com/w/cpp/utility/tuple/tie
I wonder if generating it via some syntax would still make sense though?=20
(proposal v2)
Oleg.
On 2013-12-23 10:16, Billy O'Neal wrote:
> operator=3D=3D is unambiguous because one can always fall back to=20
> memberwise comparison, and there are no constraints on ordering.=20
> operator< is a tougher sell because the order by which the members=20
> would be compared isn't obvious, but has a big impact on lexicographic=20
> ordering of the types.
>
> Rather than an =3Ddefault for that, I think a library makes more sense.=
=20
> Something like:
>
> class lexicographical_less
> {
> bool isLess;
> bool isKnown;
> public:
> lexicographical_less() : isLess(false), isKnown(false) {}
> lexicographical_less(lexicographical_less const&) =3D delete;
> lexicographical_less& operator=3D(lexicographical_less const&) =3D de=
lete;
> template <typename Left, typename Right>
> lexicographical_less& add(Left const& lhs, Right const& rhs)
> {
> if (isKnown || lhs =3D=3D rhs) return;
> isKnown =3D true;
> isLess =3D lhs < rhs;
> return *this;
> }
> bool get() const
> {
> return isKnown && isLess;
> }
> };
> class client
> {
> Member1 m1; Member2 m2; Member3 m3;
> public:
> bool operator<(client const& rhs) const // as usual
> {
> return lexicographical_less().add(m1, rhs.m1).add(m2,=20
> rhs.m2).add(m3m, rhs.m3).get();
> }
> };
>
> Here the type designer explicitly declares the less-than comparison=20
> order. (Plus, this requires no new additions to the core language)
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Dec 23, 2013 at 9:17 AM, <corentin.schreiber@cea.fr=20
> <mailto:corentin.schreiber@cea.fr>> wrote:
>
> On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg Smolsky wrote:
>
> Indeed, operator<() is the next logical step here, and my
> motivation is exactly the same to what you mentioned. This,
> however, moves types from "regular" to "totally ordered" using
> Stepanov's terms. (btw, you can use std::tie for implementing it)=
..
>
> Now, back to equality. I'm trying to implement the code-gen in
> Clang. If successful, I'll get a proposal number and submit a
> draft for the absolute minimal feature.
>
> Oleg.
>
> On 2013-12-22 09:13, R=F3bert D=E1vid wrote:
>> I too thought about this a while ago, and not only for
>> operator=3D=3D, but also for operator<, <=3D, >, >=3D. I used to=
work
>> with a codebase that had extended amount of std::maps with
>> compound keys. For each key, we had to write both operator=3D=3D
>> and operator< (as std::map needs that), with the following code:
>> |
>> structFoo{
>> Member1m1;Member2m2;Member3m3;
>> };
>> |booloperator=3D=3D(constFoo&l, const Foo& r){
>> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m=
3;
>> }
>> bool operator<(const Foo& l, const Foo& r) {
>> bool result=3Dfalse;
>> result =3D result || l.m1 < r.m1;
>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2 &&=
l.m3
>> < l.m3;
>> return result;
>> }
>> |
>> |
>>
>> (I hope noone is surprised on the code). Now, operator=3D=3D is
>> not so bad, but operator< is horrible if you have 5+ members.
>> We had a variadic macro to get less mistakes on implementing
>> the operators, but it is very hard to make it readable, and
>> still requires typing the member names twice.
>>
>> It would be a incomparably lot cleaner if instead of the
>> above, we could just write
>> |
>> |structFoo{
>> Member1m1;Member2m2;Member3m3;
>> };|
>> ||booloperator=3D=3D(constFoo&l, const Foo& r)=3D default;||
>> |||booloperator< (constFoo&l, const Foo& r)=3D default;|||
>> |
>>
>> Or alternatively, as a member function:
>> |
>> |
>> ||structFoo{
>> Member1m1;Member2m2;Member3m3;
>> || |||||||booloperator=3D=3D(const Foo& r)=3D default;||
>> ||| booloperator< (const Foo& r)=3D default;||||||
>> };|
>> |||||||
>> |
>>
>> |I guess the non-member would need some reflection-like
>> feature (I don't even think the benefit of non-member
>> comparators is that great anyway), but the compiler has every
>> information to generate the second.
>>
>> I already see the question, in what order should operator< do
>> the comparison? I see two options:
>> a, same way as the constructors work.
>> b, implementation defined, allowing for any possible
>> optimizations.
>> I actually don't care what order it is doing that, if I do, I
>> can still implement the function normally.
>>
>> None of these should be implicit, explicit "=3Ddefault" should
>> be there, to not break any current code. I don't think
>> tweaking lookup rules for this is a viable alternative.
>> ||||||
>> ||||||I would be more than happy to help working on such a
>> proposal.
>>
>> 2013. december 21., szombat 2:33:14 UTC+1 id=F5pontban Billy
>> O'Neal a k=F6vetkez=F5t =EDrta:
>>
>> What would we expect to happen if one of the members is
>> not comparable? Ill formed?
>>
>>
>> That's exactly the same problem as a =3Ddefault
>> default/copy/move constructor/assignment op if one of the
>> members don't have one. Although I can't remember how this
>> works for the current =3Ddefault functions, I'd say in that
>> case it should be just deleted to allow proper usage in class
>> templates with template-param members.
>>
>> Regards, Robert
>>
>> PS: Drifting away from comparisons, it can be also possible
>> to generator operator?=3D from operator? or vica versa. A
>> default operator+ meaning memberwise op+ is less useful in my
>> opinion than having op+ generated from op+=3D (what should be
>> consistent) and op*=3D from op*. But this is a matter of
>> another thread.
> I think the =3Ddefault notation could be confusing if the
> operator is never generated implicitly, so that there is no
> "default" to start with. Maybe something like =3Dauto would be
> clearer.
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --=20
>
> ---
> You received this message because you are subscribed to a topic in the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to=20
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------090003070504080504040600
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-2"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Hey Billy, I believe this is already
present in C++11:<br>
=A0=A0=A0 <a class=3D"moz-txt-link-freetext" href=3D"http://en.cppref=
erence.com/w/cpp/utility/tuple/tie">http://en.cppreference.com/w/cpp/utilit=
y/tuple/tie</a><br>
<br>
I wonder if generating it via some syntax would still make sense
though? (proposal v2)<br>
<br>
Oleg.<br>
<br>
On 2013-12-23 10:16, Billy O'Neal wrote:<br>
</div>
<blockquote
cite=3D"mid:CAPBZbvxPoxKSg76iefnHcb1yr8Jd2WX6xt9TwnMcWhCberGV_Q@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div>operator=3D=3D is unambiguous because one can always fall back
to memberwise comparison, and there are no constraints on
ordering. operator< is a tougher sell because the order by
which the members would be compared isn't obvious, but has a
big impact on lexicographic ordering of the types.</div>
<div><br>
</div>
<div>Rather than an =3Ddefault for that,=A0I think a library makes
more sense. Something like:</div>
<div><br>
</div>
<div><font face=3D"courier new,monospace">class
lexicographical_less<br>
{<br>
=A0=A0=A0 bool isLess;<br>
=A0=A0=A0 bool isKnown;<br>
public:<br>
=A0=A0=A0 lexicographical_less() : isLess(false), isKnown(false=
)
{}<br>
=A0=A0=A0 lexicographical_less(lexicographical_less const&)=
=3D
delete;<br>
=A0=A0=A0 lexicographical_less& operator=3D(lexicographical=
_less
const&) =3D delete;<br>
=A0=A0=A0 template <typename Left, typename Right><br>
=A0=A0=A0 lexicographical_less& add(Left const& lhs, Ri=
ght
const& rhs)<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 if (isKnown || lhs =3D=3D rhs) return;<br=
>
=A0=A0=A0=A0=A0=A0=A0 isKnown =3D true;<br>
=A0=A0=A0=A0=A0=A0=A0 isLess =3D lhs < rhs;<br>
=A0=A0=A0=A0=A0=A0=A0 return *this;<br>
=A0=A0=A0 }<br>
=A0=A0=A0 bool get() const<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return isKnown && isLess;<br>
=A0=A0=A0 }<br>
};</font></div>
<div><font face=3D"courier new,monospace">class client<br>
{<br>
=A0=A0=A0 Member1 m1; Member2 m2; Member3 m3;<br>
public:<br>
=A0=A0=A0 bool operator<(client const& rhs) const // as
usual<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return lexicographical_less().add(m1,
rhs.m1).add(m2, rhs.m2).add(m3m, rhs.m3).get();<br>
=A0=A0=A0 }<br>
};</font></div>
<div><br>
</div>
<div>Here the type designer explicitly declares the less-than
comparison order. (Plus, this requires no new additions to the
core language)<br>
</div>
</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>
Billy O'Neal</div>
<div><a moz-do-not-send=3D"true"
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank=
">https://github.com/BillyONeal/</a></div>
<div><a moz-do-not-send=3D"true"
href=3D"http://stackoverflow.com/users/82320/billy-oneal"
target=3D"_blank">http://stackoverflow.com/users/82320/bill=
y-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 9:17 AM, <span
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:corentin.schreiber@cea.fr" target=3D"_blank">c=
orentin.schreiber@cea.fr</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>
<div class=3D"h5">On Sunday, December 22, 2013 6:58:45 PM
UTC+1, Oleg Smolsky wrote:</div>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>
<div class=3D"h5">
<div>Indeed, operator<() is the next logical
step here, and my motivation is exactly the same
to what you mentioned. This, however, moves
types from "regular" to "totally ordered" using
Stepanov's terms. (btw, you can use std::tie for
implementing it).<br>
<br>
Now, back to equality. I'm trying to implement
the code-gen in Clang. If successful, I'll get a
proposal number and submit a draft for the
absolute minimal feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13, R=F3bert D=E1vid wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">I too thought about this a while
ago, and not only for operator=3D=3D, but also fo=
r
operator<, <=3D, >, >=3D. I used to
work with a codebase that had extended amount
of std::maps with compound keys. For each key,
we had to write both operator=3D=3D and
operator< (as std::map needs that), with
the following code:<br>
<div style=3D"border:1px solid
rgb(187,187,187);background-color:rgb(250,250,2=
50)"><code>
<div><span style=3D"color:rgb(0,0,136)">struc=
t</span><span>
</span><span
style=3D"color:rgb(102,0,102)">Foo</span>=
<span>
</span><span
style=3D"color:rgb(102,102,0)">{</span><s=
pan><br>
=A0 </span><span
style=3D"color:rgb(102,0,102)">Member1</s=
pan><span>
m1</span><span
style=3D"color:rgb(102,102,0)">;</span><s=
pan>
</span><span
style=3D"color:rgb(102,0,102)">Member2</s=
pan><span>
m2</span><span
style=3D"color:rgb(102,102,0)">;</span><s=
pan>
</span><span
style=3D"color:rgb(102,0,102)">Member3</s=
pan><span>
m3</span><span
style=3D"color:rgb(102,102,0)">;</span><s=
pan><br>
</span><span
style=3D"color:rgb(102,102,0)">};</span><=
span><br>
</span><code><span
style=3D"color:rgb(0,0,136)">bool</span=
><span>
</span><span
style=3D"color:rgb(0,0,136)">operator</=
span><span
style=3D"color:rgb(102,102,0)">=3D=3D(<=
/span><span
style=3D"color:rgb(0,0,136)">const</spa=
n><span>
</span><span
style=3D"color:rgb(102,0,102)">Foo</spa=
n><span
style=3D"color:rgb(102,102,0)">&</s=
pan><span>
l, const Foo& r</span><span
style=3D"color:rgb(102,102,0)">)</span>=
<span>
{<br>
=A0 return l.m1 =3D=3D r.m1 &&
l.m2 =3D=3D r.m2 && l.m3 =3D=3D
r.m3;<br>
}<br>
bool operator<(const Foo& l,
const Foo& r) {<br>
=A0=A0=A0 bool result=3Dfalse;<br>
=A0=A0=A0 result =3D result || l.m1 <=
;=A0
r.m1;<br>
=A0=A0=A0 result =3D result || l.m1 =3D=
=3D r.m1
&& l.m2 <=A0 l.m2;<br>
=A0=A0=A0 result =3D result || l.m1 =3D=
=3D r.m1
&& l.m2 =3D=3D l.m2 &&
l.m3 <=A0 l.m3;<br>
=A0=A0=A0 return result;<br>
}<br>
</span><span
style=3D"color:rgb(102,102,0)"></span><=
/code></div>
</code></div>
<br>
(I hope noone is surprised on the code). Now,
operator=3D=3D is not so bad, but operator< is
horrible if you have 5+ members. We had a
variadic macro to get less mistakes on
implementing the operators, but it is very
hard to make it readable, and still requires
typing the member names twice.<br>
<br>
It would be a incomparably lot cleaner if
instead of the above, we could just write<br>
<div style=3D"border:1px solid
rgb(187,187,187);background-color:rgb(250,250,2=
50)"><code>
<div><code><span
style=3D"color:rgb(0,0,136)">struct</sp=
an><span>
</span><span
style=3D"color:rgb(102,0,102)">Foo</spa=
n><span>
</span><span
style=3D"color:rgb(102,102,0)">{</span>=
<span><br>
=A0 </span><span
style=3D"color:rgb(102,0,102)">Member1<=
/span><span>
m1</span><span
style=3D"color:rgb(102,102,0)">;</span>=
<span>
</span><span
style=3D"color:rgb(102,0,102)">Member2<=
/span><span>
m2</span><span
style=3D"color:rgb(102,102,0)">;</span>=
<span>
</span><span
style=3D"color:rgb(102,0,102)">Member3<=
/span><span>
m3</span><span
style=3D"color:rgb(102,102,0)">;</span>=
<span><br>
</span><span
style=3D"color:rgb(102,102,0)">};</span=
><span></span></code><br>
<code><code><span
style=3D"color:rgb(0,0,136)">bool</sp=
an><span>
</span><span
style=3D"color:rgb(0,0,136)">operator=
</span><span
style=3D"color:rgb(102,102,0)">=3D=3D=
(</span><span
style=3D"color:rgb(0,0,136)">const</s=
pan><span>
</span><span
style=3D"color:rgb(102,0,102)">Foo</s=
pan><span
style=3D"color:rgb(102,102,0)">&<=
/span><span>
l, const Foo& r</span><span
style=3D"color:rgb(102,102,0)">)</spa=
n><span>
=3D default;</span></code></code><spa=
n
style=3D"color:rgb(102,102,0)"></span><br=
>
<code><code><code><span
style=3D"color:rgb(0,0,136)">bool</=
span><span>
</span><span
style=3D"color:rgb(0,0,136)">operat=
or</span><span
style=3D"color:rgb(102,102,0)"><
(</span><span
style=3D"color:rgb(0,0,136)">const<=
/span><span>
</span><span
style=3D"color:rgb(102,0,102)">Foo<=
/span><span
style=3D"color:rgb(102,102,0)">&=
;</span><span>
l, const Foo& r</span><span
style=3D"color:rgb(102,102,0)">)</s=
pan><span>
=3D default;</span></code></code><s=
pan
style=3D"color:rgb(102,102,0)"></span><=
/code></div>
</code></div>
<br>
Or alternatively, as a member function:<br>
<code><span style=3D"color:rgb(102,102,0)">
<div style=3D"border:1px solid
rgb(187,187,187);background-color:rgb(250,2=
50,250)"><code>
<div><code><code><span
style=3D"color:rgb(0,0,136)">stru=
ct</span><span
style=3D"color:rgb(0,0,0)"> </spa=
n><span
style=3D"color:rgb(102,0,102)">Fo=
o</span><span
style=3D"color:rgb(0,0,0)"> </spa=
n><span
style=3D"color:rgb(102,102,0)">{<=
/span><span
style=3D"color:rgb(0,0,0)"><br>
=A0 </span><span
style=3D"color:rgb(102,0,102)">Me=
mber1</span><span
style=3D"color:rgb(0,0,0)"> m1</s=
pan><span
style=3D"color:rgb(102,102,0)">;<=
/span><span
style=3D"color:rgb(0,0,0)"> </spa=
n><span
style=3D"color:rgb(102,0,102)">Me=
mber2</span><span
style=3D"color:rgb(0,0,0)"> m2</s=
pan><span
style=3D"color:rgb(102,102,0)">;<=
/span><span
style=3D"color:rgb(0,0,0)"> </spa=
n><span
style=3D"color:rgb(102,0,102)">Me=
mber3</span><span
style=3D"color:rgb(0,0,0)"> m3</s=
pan><span
style=3D"color:rgb(102,102,0)">;<=
/span><span
style=3D"color:rgb(0,0,0)"><br>
</span></code></code>=A0 <code><cod=
e><span
style=3D"color:rgb(0,0,0)"><code>=
<span
style=3D"color:rgb(102,102,0)"><code><code><code><code><span
style=3D"color:rgb(=
0,0,136)">bool</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">opera=
tor</span><span
style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,0=
)">const
Foo& r</span><s=
pan
style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> =
=3D
default;</span></co=
de></code><span
style=3D"color:rgb(102,102,0)"></span><br>
<code><code><code><span
style=3D"color:rgb(0,0,136)">=A0 bool</span><span style=3D"color:rgb(0,0,0)=
">
</span><span
style=3D"color:rg=
b(0,0,136)">operator</span><span
style=3D"color:rgb(102,102,0)">< (</span><span style=3D"color:rgb(0,0,0)=
">const
Foo& r</span>=
<span
style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> =
=3D
default;</span></=
code></code></code></code></code></span></code></span><span
style=3D"color:rgb(102,102,0)"><b=
r>
};</span><span
style=3D"color:rgb(0,0,0)"></span=
></code><br>
<code><code><code><span
style=3D"color:rgb(0,0,0)"></=
span></code></code></code></code><span
style=3D"color:rgb(102,102,0)"></span=
></div>
</code></div>
<br>
</span></code>I guess the non-member would
need some reflection-like feature (I don't
even think the benefit of non-member
comparators is that great anyway), but the
compiler has every information to generate the
second.<br>
<br>
I already see the question, in what order
should operator< do the comparison? I see
two options:<br>
a, same way as the constructors work.<br>
b, implementation defined, allowing for any
possible optimizations.<br>
I actually don't care what order it is doing
that, if I do, I can still implement the
function normally.<br>
<br>
None of these should be implicit, explicit
"=3Ddefault" should be there, to not break any
current code. I don't think tweaking lookup
rules for this is a viable alternative.<br>
<code><span style=3D"color:rgb(102,102,0)"><code>=
<code><code><code><code><span
style=3D"color:rgb(0,0,0)"><br>
</span></code></code></code></code>=
</code></span></code>I
would be more than happy to help working on
such a proposal.<br>
<br>
2013. december 21., szombat 2:33:14 UTC+1
id=F5pontban Billy O'Neal a k=F6vetkez=F5t =EDrta=
:
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>What would we expect to happen if one
of the members is not comparable? Ill
formed?</div>
</div>
</blockquote>
<div><br>
That's exactly the same problem as a
=3Ddefault default/copy/move
constructor/assignment op if one of the
members don't have one. Although I can't
remember how this works for the current
=3Ddefault functions, I'd say in that case it
should be just deleted to allow proper usage
in class templates with template-param
members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting away from comparisons, it can
be also possible to generator operator?=3D
from operator? or vica versa. A default
operator+ meaning memberwise op+ is less
useful in my opinion than having op+
generated from op+=3D (what should be
consistent) and op*=3D from op*. But this is a
matter of another thread.<br>
</div>
</div>
</blockquote>
</div>
</div>
I think the =3Ddefault notation could be confusing if
the operator is never generated implicitly, so that
there is no "default" to start with. Maybe something
like =3Dauto would be clearer.<br>
</div>
</blockquote>
</div>
<div class=3D"HOEnZb">
<div class=3D"h5">
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"
target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a=
>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-p=
roposals/"
target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdi=
mIsOc/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-propo=
sals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:std-proposals=
+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------090003070504080504040600--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 23 Dec 2013 10:32:45 -0800
Raw View
--089e01229a0604d48504ee37dd78
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
What syntax would you use to indicate the correct order?
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Dec 23, 2013 at 10:23 AM, Oleg Smolsky <oleg@smolsky.net> wrote:
> Hey Billy, I believe this is already present in C++11:
> http://en.cppreference.com/w/cpp/utility/tuple/tie
>
> I wonder if generating it via some syntax would still make sense though?
> (proposal v2)
>
> Oleg.
>
>
> On 2013-12-23 10:16, Billy O'Neal wrote:
>
> operator=3D=3D is unambiguous because one can always fall back to member=
wise
> comparison, and there are no constraints on ordering. operator< is a
> tougher sell because the order by which the members would be compared isn=
't
> obvious, but has a big impact on lexicographic ordering of the types.
>
> Rather than an =3Ddefault for that, I think a library makes more sense.
> Something like:
>
> class lexicographical_less
> {
> bool isLess;
> bool isKnown;
> public:
> lexicographical_less() : isLess(false), isKnown(false) {}
> lexicographical_less(lexicographical_less const&) =3D delete;
> lexicographical_less& operator=3D(lexicographical_less const&) =3D de=
lete;
> template <typename Left, typename Right>
> lexicographical_less& add(Left const& lhs, Right const& rhs)
> {
> if (isKnown || lhs =3D=3D rhs) return;
> isKnown =3D true;
> isLess =3D lhs < rhs;
> return *this;
> }
> bool get() const
> {
> return isKnown && isLess;
> }
> };
> class client
> {
> Member1 m1; Member2 m2; Member3 m3;
> public:
> bool operator<(client const& rhs) const // as usual
> {
> return lexicographical_less().add(m1, rhs.m1).add(m2,
> rhs.m2).add(m3m, rhs.m3).get();
> }
> };
>
> Here the type designer explicitly declares the less-than comparison
> order. (Plus, this requires no new additions to the core language)
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Dec 23, 2013 at 9:17 AM, <corentin.schreiber@cea.fr> wrote:
>
>> On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg Smolsky wrote:
>>
>>> Indeed, operator<() is the next logical step here, and my motivation
>>> is exactly the same to what you mentioned. This, however, moves types f=
rom
>>> "regular" to "totally ordered" using Stepanov's terms. (btw, you can us=
e
>>> std::tie for implementing it).
>>>
>>> Now, back to equality. I'm trying to implement the code-gen in Clang. I=
f
>>> successful, I'll get a proposal number and submit a draft for the absol=
ute
>>> minimal feature.
>>>
>>> Oleg.
>>>
>>> On 2013-12-22 09:13, R=F3bert D=E1vid wrote:
>>>
>>> I too thought about this a while ago, and not only for operator=3D=3D, =
but
>>> also for operator<, <=3D, >, >=3D. I used to work with a codebase that =
had
>>> extended amount of std::maps with compound keys. For each key, we had t=
o
>>> write both operator=3D=3D and operator< (as std::map needs that), with =
the
>>> following code:
>>> struct Foo {
>>> Member1 m1; Member2 m2; Member3 m3;
>>> };
>>> bool operator=3D=3D(const Foo& l, const Foo& r) {
>>> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m3;
>>> }
>>> bool operator<(const Foo& l, const Foo& r) {
>>> bool result=3Dfalse;
>>> result =3D result || l.m1 < r.m1;
>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2 && l.m3 <=
l.m3;
>>> return result;
>>> }
>>>
>>> (I hope noone is surprised on the code). Now, operator=3D=3D is not so =
bad,
>>> but operator< is horrible if you have 5+ members. We had a variadic mac=
ro
>>> to get less mistakes on implementing the operators, but it is very hard=
to
>>> make it readable, and still requires typing the member names twice.
>>>
>>> It would be a incomparably lot cleaner if instead of the above, we coul=
d
>>> just write
>>> struct Foo {
>>> Member1 m1; Member2 m2; Member3 m3;
>>> };
>>> bool operator=3D=3D(const Foo& l, const Foo& r) =3D default;
>>> bool operator< (const Foo& l, const Foo& r) =3D default;
>>>
>>> Or alternatively, as a member function:
>>> struct Foo {
>>> Member1 m1; Member2 m2; Member3 m3;
>>> bool operator=3D=3D(const Foo& r) =3D default;
>>> bool operator< (const Foo& r) =3D default;
>>> };
>>>
>>> I guess the non-member would need some reflection-like feature (I don't
>>> even think the benefit of non-member comparators is that great anyway),=
but
>>> the compiler has every information to generate the second.
>>>
>>> I already see the question, in what order should operator< do the
>>> comparison? I see two options:
>>> a, same way as the constructors work.
>>> b, implementation defined, allowing for any possible optimizations.
>>> I actually don't care what order it is doing that, if I do, I can still
>>> implement the function normally.
>>>
>>> None of these should be implicit, explicit "=3Ddefault" should be there=
,
>>> to not break any current code. I don't think tweaking lookup rules for =
this
>>> is a viable alternative.
>>>
>>> I would be more than happy to help working on such a proposal.
>>>
>>> 2013. december 21., szombat 2:33:14 UTC+1 id=F5pontban Billy O'Neal a
>>> k=F6vetkez=F5t =EDrta:
>>>>
>>>> What would we expect to happen if one of the members is not
>>>> comparable? Ill formed?
>>>>
>>>
>>> That's exactly the same problem as a =3Ddefault default/copy/move
>>> constructor/assignment op if one of the members don't have one. Althoug=
h I
>>> can't remember how this works for the current =3Ddefault functions, I'd=
say
>>> in that case it should be just deleted to allow proper usage in class
>>> templates with template-param members.
>>>
>>> Regards, Robert
>>>
>>> PS: Drifting away from comparisons, it can be also possible to generato=
r
>>> operator?=3D from operator? or vica versa. A default operator+ meaning
>>> memberwise op+ is less useful in my opinion than having op+ generated f=
rom
>>> op+=3D (what should be consistent) and op*=3D from op*. But this is a m=
atter of
>>> another thread.
>>>
>>> I think the =3Ddefault notation could be confusing if the operator is
>>> never generated implicitly, so that there is no "default" to start with=
..
>>> Maybe something like =3Dauto would be clearer.
>>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
>
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e01229a0604d48504ee37dd78
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What syntax would you use to indicate the correct order?</=
div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div=
>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" t=
arget=3D"_blank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 10:23 AM, Oleg S=
molsky <span dir=3D"ltr"><<a href=3D"mailto:oleg@smolsky.net" target=3D"=
_blank">oleg@smolsky.net</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Hey Billy, I believe this is already
present in C++11:<br>
=A0=A0=A0 <a href=3D"http://en.cppreference.com/w/cpp/utility/tuple/t=
ie" target=3D"_blank">http://en.cppreference.com/w/cpp/utility/tuple/tie</a=
><br>
<br>
I wonder if generating it via some syntax would still make sense
though? (proposal v2)<br>
<br>
Oleg.<div><div class=3D"h5"><br>
<br>
On 2013-12-23 10:16, Billy O'Neal wrote:<br>
</div></div></div>
<blockquote type=3D"cite"><div><div class=3D"h5">
<div dir=3D"ltr">
<div>operator=3D=3D is unambiguous because one can always fall back
to memberwise comparison, and there are no constraints on
ordering. operator< is a tougher sell because the order by
which the members would be compared isn't obvious, but has a
big impact on lexicographic ordering of the types.</div>
<div><br>
</div>
<div>Rather than an =3Ddefault for that,=A0I think a library makes
more sense. Something like:</div>
<div><br>
</div>
<div><font face=3D"courier new,monospace">class
lexicographical_less<br>
{<br>
=A0=A0=A0 bool isLess;<br>
=A0=A0=A0 bool isKnown;<br>
public:<br>
=A0=A0=A0 lexicographical_less() : isLess(false), isKnown(false=
)
{}<br>
=A0=A0=A0 lexicographical_less(lexicographical_less const&)=
=3D
delete;<br>
=A0=A0=A0 lexicographical_less& operator=3D(lexicographical=
_less
const&) =3D delete;<br>
=A0=A0=A0 template <typename Left, typename Right><br>
=A0=A0=A0 lexicographical_less& add(Left const& lhs, Ri=
ght
const& rhs)<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 if (isKnown || lhs =3D=3D rhs) return;<br=
>
=A0=A0=A0=A0=A0=A0=A0 isKnown =3D true;<br>
=A0=A0=A0=A0=A0=A0=A0 isLess =3D lhs < rhs;<br>
=A0=A0=A0=A0=A0=A0=A0 return *this;<br>
=A0=A0=A0 }<br>
=A0=A0=A0 bool get() const<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return isKnown && isLess;<br>
=A0=A0=A0 }<br>
};</font></div>
<div><font face=3D"courier new,monospace">class client<br>
{<br>
=A0=A0=A0 Member1 m1; Member2 m2; Member3 m3;<br>
public:<br>
=A0=A0=A0 bool operator<(client const& rhs) const // as
usual<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return lexicographical_less().add(m1,
rhs.m1).add(m2, rhs.m2).add(m3m, rhs.m3).get();<br>
=A0=A0=A0 }<br>
};</font></div>
<div><br>
</div>
<div>Here the type designer explicitly declares the less-than
comparison order. (Plus, this requires no new additions to the
core language)<br>
</div>
</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>
Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_b=
lank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-onea=
l" target=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></=
div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 9:17 AM, <span d=
ir=3D"ltr"><<a href=3D"mailto:corentin.schreiber@cea.fr" target=3D"_blan=
k">corentin.schreiber@cea.fr</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid">
<div dir=3D"ltr">
<div>
<div>On Sunday, December 22, 2013 6:58:45 PM
UTC+1, Oleg Smolsky wrote:</div>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-widt=
h:1px;border-left-style:solid">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>
<div>
<div>Indeed, operator<() is the next logical
step here, and my motivation is exactly the same
to what you mentioned. This, however, moves
types from "regular" to "totally ord=
ered" using
Stepanov's terms. (btw, you can use std::tie fo=
r
implementing it).<br>
<br>
Now, back to equality. I'm trying to implement
the code-gen in Clang. If successful, I'll get =
a
proposal number and submit a draft for the
absolute minimal feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13, R=F3bert D=E1vid wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">I too thought about this a while
ago, and not only for operator=3D=3D, but also fo=
r
operator<, <=3D, >, >=3D. I used to
work with a codebase that had extended amount
of std::maps with compound keys. For each key,
we had to write both operator=3D=3D and
operator< (as std::map needs that), with
the following code:<br>
<div style=3D"border:1px solid rgb(187,187,187);b=
ackground-color:rgb(250,250,250)"><code>
<div><span style=3D"color:rgb(0,0,136)">struc=
t</span><span>
</span><span style=3D"color:rgb(102,0,102)"=
>Foo</span><span>
</span><span style=3D"color:rgb(102,102,0)"=
>{</span><span><br>
=A0 </span><span style=3D"color:rgb(102,0=
,102)">Member1</span><span>
m1</span><span style=3D"color:rgb(102,102=
,0)">;</span><span>
</span><span style=3D"color:rgb(102,0,102)"=
>Member2</span><span>
m2</span><span style=3D"color:rgb(102,102=
,0)">;</span><span>
</span><span style=3D"color:rgb(102,0,102)"=
>Member3</span><span>
m3</span><span style=3D"color:rgb(102,102=
,0)">;</span><span><br>
</span><span style=3D"color:rgb(102,102,0)"=
>};</span><span><br>
</span><code><span style=3D"color:rgb(0,0,1=
36)">bool</span><span>
</span><span style=3D"color:rgb(0,0,136)"=
>operator</span><span style=3D"color:rgb(102,102,0)">=3D=3D(</span><span st=
yle=3D"color:rgb(0,0,136)">const</span><span>
</span><span style=3D"color:rgb(102,0,102=
)">Foo</span><span style=3D"color:rgb(102,102,0)">&</span><span>
l, const Foo& r</span><span style=
=3D"color:rgb(102,102,0)">)</span><span>
{<br>
=A0 return l.m1 =3D=3D r.m1 &&
l.m2 =3D=3D r.m2 && l.m3 =3D=3D
r.m3;<br>
}<br>
bool operator<(const Foo& l,
const Foo& r) {<br>
=A0=A0=A0 bool result=3Dfalse;<br>
=A0=A0=A0 result =3D result || l.m1 <=
;=A0
r.m1;<br>
=A0=A0=A0 result =3D result || l.m1 =3D=
=3D r.m1
&& l.m2 <=A0 l.m2;<br>
=A0=A0=A0 result =3D result || l.m1 =3D=
=3D r.m1
&& l.m2 =3D=3D l.m2 &&
l.m3 <=A0 l.m3;<br>
=A0=A0=A0 return result;<br>
}<br>
</span><span style=3D"color:rgb(102,102,0=
)"></span></code></div>
</code></div>
<br>
(I hope noone is surprised on the code). Now,
operator=3D=3D is not so bad, but operator< is
horrible if you have 5+ members. We had a
variadic macro to get less mistakes on
implementing the operators, but it is very
hard to make it readable, and still requires
typing the member names twice.<br>
<br>
It would be a incomparably lot cleaner if
instead of the above, we could just write<br>
<div style=3D"border:1px solid rgb(187,187,187);b=
ackground-color:rgb(250,250,250)"><code>
<div><code><span style=3D"color:rgb(0,0,136)"=
>struct</span><span>
</span><span style=3D"color:rgb(102,0,102=
)">Foo</span><span>
</span><span style=3D"color:rgb(102,102,0=
)">{</span><span><br>
=A0 </span><span style=3D"color:rgb(102=
,0,102)">Member1</span><span>
m1</span><span style=3D"color:rgb(102,1=
02,0)">;</span><span>
</span><span style=3D"color:rgb(102,0,102=
)">Member2</span><span>
m2</span><span style=3D"color:rgb(102,1=
02,0)">;</span><span>
</span><span style=3D"color:rgb(102,0,102=
)">Member3</span><span>
m3</span><span style=3D"color:rgb(102,1=
02,0)">;</span><span><br>
</span><span style=3D"color:rgb(102,102,0=
)">};</span><span></span></code><br>
<code><code><span style=3D"color:rgb(0,0,13=
6)">bool</span><span>
</span><span style=3D"color:rgb(0,0,136=
)">operator</span><span style=3D"color:rgb(102,102,0)">=3D=3D(</span><span =
style=3D"color:rgb(0,0,136)">const</span><span>
</span><span style=3D"color:rgb(102,0,1=
02)">Foo</span><span style=3D"color:rgb(102,102,0)">&</span><span>
l, const Foo& r</span><span style=
=3D"color:rgb(102,102,0)">)</span><span>
=3D default;</span></code></code><spa=
n style=3D"color:rgb(102,102,0)"></span><br>
<code><code><code><span style=3D"color:rgb(=
0,0,136)">bool</span><span>
</span><span style=3D"color:rgb(0,0,1=
36)">operator</span><span style=3D"color:rgb(102,102,0)"><
(</span><span style=3D"color:rgb(0,=
0,136)">const</span><span>
</span><span style=3D"color:rgb(102,0=
,102)">Foo</span><span style=3D"color:rgb(102,102,0)">&</span><span>
l, const Foo& r</span><span sty=
le=3D"color:rgb(102,102,0)">)</span><span>
=3D default;</span></code></code><s=
pan style=3D"color:rgb(102,102,0)"></span></code></div>
</code></div>
<br>
Or alternatively, as a member function:<br>
<code><span style=3D"color:rgb(102,102,0)">
<div style=3D"border:1px solid rgb(187,187,18=
7);background-color:rgb(250,250,250)"><code>
<div><code><code><span style=3D"color:rgb=
(0,0,136)">struct</span><span style=3D"color:rgb(0,0,0)"> </span><span styl=
e=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,=
0,0)"><br>
=A0 </span><span style=3D"color:r=
gb(102,0,102)">Member1</span><span style=3D"color:rgb(0,0,0)"> m1</span><sp=
an style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)">=
</span><span style=3D"color:rgb(102,0,102)">Member2</span><span style=3D"c=
olor:rgb(0,0,0)"> m2</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">=
Member3</span><span style=3D"color:rgb(0,0,0)"> m3</span><span style=3D"col=
or:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>
</span></code></code>=A0 <code><cod=
e><span style=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(102,102,0=
)"><code><code><code><code><span style=3D"color:rgb(0,0,136)">bool</span><s=
pan style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">o=
perator</span><span style=3D"color:rgb(102,102,0)">=3D=3D(</span><span styl=
e=3D"color:rgb(0,0,0)">const
Foo& r</span><s=
pan style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"=
> =3D
default;</span></co=
de></code><span style=3D"color:rgb(102,102,0)"></span><br>
<code><code><code><span s=
tyle=3D"color:rgb(0,0,136)">=A0 bool</span><span style=3D"color:rgb(0,0,0)"=
>
</span><span style=
=3D"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)"=
>< (</span><span style=3D"color:rgb(0,0,0)">const
Foo& r</span>=
<span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0=
)"> =3D
default;</span></=
code></code></code></code></code></span></code></span><span style=3D"color:=
rgb(102,102,0)"><br>
};</span><span style=3D"color:rgb=
(0,0,0)"></span></code><br>
<code><code><code><span style=3D"colo=
r:rgb(0,0,0)"></span></code></code></code></code><span style=3D"color:rgb(1=
02,102,0)"></span></div>
</code></div>
<br>
</span></code>I guess the non-member would
need some reflection-like feature (I don't
even think the benefit of non-member
comparators is that great anyway), but the
compiler has every information to generate the
second.<br>
<br>
I already see the question, in what order
should operator< do the comparison? I see
two options:<br>
a, same way as the constructors work.<br>
b, implementation defined, allowing for any
possible optimizations.<br>
I actually don't care what order it is doing
that, if I do, I can still implement the
function normally.<br>
<br>
None of these should be implicit, explicit
"=3Ddefault" should be there, to not br=
eak any
current code. I don't think tweaking lookup
rules for this is a viable alternative.<br>
<code><span style=3D"color:rgb(102,102,0)"><code>=
<code><code><code><code><span style=3D"color:rgb(0,0,0)"><br>
</span></code></code></code></code>=
</code></span></code>I
would be more than happy to help working on
such a proposal.<br>
<br>
2013. december 21., szombat 2:33:14 UTC+1
id=F5pontban Billy O'Neal a k=F6vetkez=F5t =
=EDrta:
<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bord=
er-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>What would we expect to happen if one
of the members is not comparable? Ill
formed?</div>
</div>
</blockquote>
<div><br>
That's exactly the same problem as a
=3Ddefault default/copy/move
constructor/assignment op if one of the
members don't have one. Although I can'=
t
remember how this works for the current
=3Ddefault functions, I'd say in that case =
it
should be just deleted to allow proper usage
in class templates with template-param
members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting away from comparisons, it can
be also possible to generator operator?=3D
from operator? or vica versa. A default
operator+ meaning memberwise op+ is less
useful in my opinion than having op+
generated from op+=3D (what should be
consistent) and op*=3D from op*. But this is a
matter of another thread.<br>
</div>
</div>
</blockquote>
</div>
</div>
I think the =3Ddefault notation could be confusing if
the operator is never generated implicitly, so that
there is no "default" to start with. Maybe some=
thing
like =3Dauto would be clearer.<br>
</div>
</blockquote>
</div>
<div>
<div>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals=
"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a href=3D"mailto:std-proposals%2=
Bunsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp=
..org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-=
proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/i=
socpp.org/group/std-proposals/" target=3D"_blank">http://groups.google.com/=
a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br></div></div>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" gro=
up.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.googl=
e.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/unsubscribe" target=3D=
"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpId=
imIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"=
_blank">std-proposals+unsubscribe@isocpp.org</a>.<div class=3D"im"><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@=
isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/</a>.<br>
</div></blockquote>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01229a0604d48504ee37dd78--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Mon, 23 Dec 2013 10:35:25 -0800
Raw View
This is a multi-part message in MIME format.
--------------010803090906010901070102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
This is the main question and I only have the obvious proposition - the=20
declaration order. (this is in line with construction and assignment).
Oleg.
On 2013-12-23 10:32, Billy O'Neal wrote:
> What syntax would you use to indicate the correct order?
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Dec 23, 2013 at 10:23 AM, Oleg Smolsky <oleg@smolsky.net=20
> <mailto:oleg@smolsky.net>> wrote:
>
> Hey Billy, I believe this is already present in C++11:
> http://en.cppreference.com/w/cpp/utility/tuple/tie
>
> I wonder if generating it via some syntax would still make sense
> though? (proposal v2)
>
> Oleg.
>
>
> On 2013-12-23 10:16, Billy O'Neal wrote:
>> operator=3D=3D is unambiguous because one can always fall back to
>> memberwise comparison, and there are no constraints on ordering.
>> operator< is a tougher sell because the order by which the
>> members would be compared isn't obvious, but has a big impact on
>> lexicographic ordering of the types.
>>
>> Rather than an =3Ddefault for that, I think a library makes more
>> sense. Something like:
>>
>> class lexicographical_less
>> {
>> bool isLess;
>> bool isKnown;
>> public:
>> lexicographical_less() : isLess(false), isKnown(false) {}
>> lexicographical_less(lexicographical_less const&) =3D delete;
>> lexicographical_less& operator=3D(lexicographical_less const&)
>> =3D delete;
>> template <typename Left, typename Right>
>> lexicographical_less& add(Left const& lhs, Right const& rhs)
>> {
>> if (isKnown || lhs =3D=3D rhs) return;
>> isKnown =3D true;
>> isLess =3D lhs < rhs;
>> return *this;
>> }
>> bool get() const
>> {
>> return isKnown && isLess;
>> }
>> };
>> class client
>> {
>> Member1 m1; Member2 m2; Member3 m3;
>> public:
>> bool operator<(client const& rhs) const // as usual
>> {
>> return lexicographical_less().add(m1, rhs.m1).add(m2,
>> rhs.m2).add(m3m, rhs.m3).get();
>> }
>> };
>>
>> Here the type designer explicitly declares the less-than
>> comparison order. (Plus, this requires no new additions to the
>> core language)
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Mon, Dec 23, 2013 at 9:17 AM, <corentin.schreiber@cea.fr
>> <mailto:corentin.schreiber@cea.fr>> wrote:
>>
>> On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg Smolsky
>> wrote:
>>
>> Indeed, operator<() is the next logical step here, and my
>> motivation is exactly the same to what you mentioned.
>> This, however, moves types from "regular" to "totally
>> ordered" using Stepanov's terms. (btw, you can use
>> std::tie for implementing it).
>>
>> Now, back to equality. I'm trying to implement the
>> code-gen in Clang. If successful, I'll get a proposal
>> number and submit a draft for the absolute minimal feature.
>>
>> Oleg.
>>
>> On 2013-12-22 09:13, R=C3=B3bert D=C3=A1vid wrote:
>>> I too thought about this a while ago, and not only for
>>> operator=3D=3D, but also for operator<, <=3D, >, >=3D. I us=
ed to
>>> work with a codebase that had extended amount of
>>> std::maps with compound keys. For each key, we had to
>>> write both operator=3D=3D and operator< (as std::map needs
>>> that), with the following code:
>>> |
>>> structFoo{
>>> Member1m1;Member2m2;Member3m3;
>>> };
>>> |booloperator=3D=3D(constFoo&l, const Foo& r){
>>> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=
=3D r.m3;
>>> }
>>> bool operator<(const Foo& l, const Foo& r) {
>>> bool result=3Dfalse;
>>> result =3D result || l.m1 < r.m1;
>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.=
m2 &&
>>> l.m3 < l.m3;
>>> return result;
>>> }
>>> |
>>> |
>>>
>>> (I hope noone is surprised on the code). Now, operator=3D=
=3D
>>> is not so bad, but operator< is horrible if you have 5+
>>> members. We had a variadic macro to get less mistakes on
>>> implementing the operators, but it is very hard to make
>>> it readable, and still requires typing the member names
>>> twice.
>>>
>>> It would be a incomparably lot cleaner if instead of the
>>> above, we could just write
>>> |
>>> |structFoo{
>>> Member1m1;Member2m2;Member3m3;
>>> };|
>>> ||booloperator=3D=3D(constFoo&l, const Foo& r)=3D default;|=
|
>>> |||booloperator< (constFoo&l, const Foo& r)=3D default;|||
>>> |
>>>
>>> Or alternatively, as a member function:
>>> |
>>> |
>>> ||structFoo{
>>> Member1m1;Member2m2;Member3m3;
>>> || |||||||booloperator=3D=3D(const Foo& r)=3D default;||
>>> ||| booloperator< (const Foo& r)=3D default;||||||
>>> };|
>>> |||||||
>>> |
>>>
>>> |I guess the non-member would need some reflection-like
>>> feature (I don't even think the benefit of non-member
>>> comparators is that great anyway), but the compiler has
>>> every information to generate the second.
>>>
>>> I already see the question, in what order should
>>> operator< do the comparison? I see two options:
>>> a, same way as the constructors work.
>>> b, implementation defined, allowing for any possible
>>> optimizations.
>>> I actually don't care what order it is doing that, if I
>>> do, I can still implement the function normally.
>>>
>>> None of these should be implicit, explicit "=3Ddefault"
>>> should be there, to not break any current code. I don't
>>> think tweaking lookup rules for this is a viable
>>> alternative.
>>> ||||||
>>> ||||||I would be more than happy to help working on such
>>> a proposal.
>>>
>>> 2013. december 21., szombat 2:33:14 UTC+1 id=C5=91pontban
>>> Billy O'Neal a k=C3=B6vetkez=C5=91t =C3=ADrta:
>>>
>>> What would we expect to happen if one of the members
>>> is not comparable? Ill formed?
>>>
>>>
>>> That's exactly the same problem as a =3Ddefault
>>> default/copy/move constructor/assignment op if one of
>>> the members don't have one. Although I can't remember
>>> how this works for the current =3Ddefault functions, I'd
>>> say in that case it should be just deleted to allow
>>> proper usage in class templates with template-param members=
..
>>>
>>> Regards, Robert
>>>
>>> PS: Drifting away from comparisons, it can be also
>>> possible to generator operator?=3D from operator? or vica
>>> versa. A default operator+ meaning memberwise op+ is
>>> less useful in my opinion than having op+ generated from
>>> op+=3D (what should be consistent) and op*=3D from op*. But
>>> this is a matter of another thread.
>> I think the =3Ddefault notation could be confusing if the
>> operator is never generated implicitly, so that there is
>> no "default" to start with. Maybe something like =3Dauto
>> would be clearer.
>>
>> --=20
>>
>> ---
>> You received this message because you are subscribed to the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>> --=20
>>
>> ---
>> You received this message because you are subscribed to a topic
>> in the Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdim=
IsOc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email
>> to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>>
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --=20
>
> ---
> You received this message because you are subscribed to a topic in the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to=20
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------010803090906010901070102
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-2"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">This is the main question and I only
have the obvious proposition - the declaration order. (this is in
line with construction and assignment).<br>
<br>
Oleg.<br>
<br>
On 2013-12-23 10:32, Billy O'Neal wrote:<br>
</div>
<blockquote
cite=3D"mid:CAPBZbvxTh2FxM=3Dd-=3D6yQJ5yY=3Dfx_tKRLx-a5-RqvGx1kcN91gQ@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">What syntax would you use to indicate the correct
order?</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a moz-do-not-send=3D"true"
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank=
">https://github.com/BillyONeal/</a></div>
<div><a moz-do-not-send=3D"true"
href=3D"http://stackoverflow.com/users/82320/billy-oneal"
target=3D"_blank">http://stackoverflow.com/users/82320/bill=
y-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 10:23 AM, Oleg
Smolsky <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:oleg@smolsky.net" target=3D"_blank">oleg@smols=
ky.net</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Hey Billy, I believe this is already present in
C++11:<br>
=A0=A0=A0 <a moz-do-not-send=3D"true"
href=3D"http://en.cppreference.com/w/cpp/utility/tuple/ti=
e"
target=3D"_blank">http://en.cppreference.com/w/cpp/utilit=
y/tuple/tie</a><br>
<br>
I wonder if generating it via some syntax would still
make sense though? (proposal v2)<br>
<br>
Oleg.
<div>
<div class=3D"h5"><br>
<br>
On 2013-12-23 10:16, Billy O'Neal wrote:<br>
</div>
</div>
</div>
<blockquote type=3D"cite">
<div>
<div class=3D"h5">
<div dir=3D"ltr">
<div>operator=3D=3D is unambiguous because one can
always fall back to memberwise comparison, and
there are no constraints on ordering.
operator< is a tougher sell because the order
by which the members would be compared isn't
obvious, but has a big impact on lexicographic
ordering of the types.</div>
<div><br>
</div>
<div>Rather than an =3Ddefault for that,=A0I think a
library makes more sense. Something like:</div>
<div><br>
</div>
<div><font face=3D"courier new,monospace">class
lexicographical_less<br>
{<br>
=A0=A0=A0 bool isLess;<br>
=A0=A0=A0 bool isKnown;<br>
public:<br>
=A0=A0=A0 lexicographical_less() : isLess(false),
isKnown(false) {}<br>
=A0=A0=A0 lexicographical_less(lexicographical_le=
ss
const&) =3D delete;<br>
=A0=A0=A0 lexicographical_less&
operator=3D(lexicographical_less const&) =3D
delete;<br>
=A0=A0=A0 template <typename Left, typename
Right><br>
=A0=A0=A0 lexicographical_less& add(Left
const& lhs, Right const& rhs)<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 if (isKnown || lhs =3D=3D r=
hs) return;<br>
=A0=A0=A0=A0=A0=A0=A0 isKnown =3D true;<br>
=A0=A0=A0=A0=A0=A0=A0 isLess =3D lhs < rhs;<br=
>
=A0=A0=A0=A0=A0=A0=A0 return *this;<br>
=A0=A0=A0 }<br>
=A0=A0=A0 bool get() const<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return isKnown && i=
sLess;<br>
=A0=A0=A0 }<br>
};</font></div>
<div><font face=3D"courier new,monospace">class
client<br>
{<br>
=A0=A0=A0 Member1 m1; Member2 m2; Member3 m3;<br>
public:<br>
=A0=A0=A0 bool operator<(client const& rhs=
)
const // as usual<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return lexicographical_less=
().add(m1,
rhs.m1).add(m2, rhs.m2).add(m3m,
rhs.m3).get();<br>
=A0=A0=A0 }<br>
};</font></div>
<div><br>
</div>
<div>Here the type designer explicitly declares
the less-than comparison order. (Plus, this
requires no new additions to the core language)<br>
</div>
</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div> Billy O'Neal</div>
<div><a moz-do-not-send=3D"true"
href=3D"https://bitbucket.org/BillyONeal/"
target=3D"_blank">https://github.com/BillyONe=
al/</a></div>
<div><a moz-do-not-send=3D"true"
href=3D"http://stackoverflow.com/users/82320/=
billy-oneal"
target=3D"_blank">http://stackoverflow.com/us=
ers/82320/billy-oneal</a></div>
<div>Malware Response Instructor -
BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at
9:17 AM, <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:corentin.schreiber@cea.fr"
target=3D"_blank">corentin.schreiber@cea.fr</a>=
></span>
wrote:<br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>
<div>On Sunday, December 22, 2013 6:58:45
PM UTC+1, Oleg Smolsky wrote:</div>
</div>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>
<div>
<div>Indeed, operator<() is the
next logical step here, and my
motivation is exactly the same to
what you mentioned. This, however,
moves types from "regular" to
"totally ordered" using Stepanov's
terms. (btw, you can use std::tie
for implementing it).<br>
<br>
Now, back to equality. I'm trying
to implement the code-gen in
Clang. If successful, I'll get a
proposal number and submit a draft
for the absolute minimal feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13, R=F3bert D=E1vid
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">I too thought about
this a while ago, and not only
for operator=3D=3D, but also for
operator<, <=3D, >,
>=3D. I used to work with a
codebase that had extended
amount of std::maps with
compound keys. For each key, we
had to write both operator=3D=3D an=
d
operator< (as std::map needs
that), with the following code:<br>
<div style=3D"border:1px solid
rgb(187,187,187);background-color=
:rgb(250,250,250)"><code>
<div><span
style=3D"color:rgb(0,0,136)=
">struct</span><span>
</span><span
style=3D"color:rgb(102,0,10=
2)">Foo</span><span>
</span><span
style=3D"color:rgb(102,102,=
0)">{</span><span><br>
=A0 </span><span
style=3D"color:rgb(102,0,10=
2)">Member1</span><span>
m1</span><span
style=3D"color:rgb(102,102,=
0)">;</span><span>
</span><span
style=3D"color:rgb(102,0,10=
2)">Member2</span><span>
m2</span><span
style=3D"color:rgb(102,102,=
0)">;</span><span>
</span><span
style=3D"color:rgb(102,0,10=
2)">Member3</span><span>
m3</span><span
style=3D"color:rgb(102,102,=
0)">;</span><span><br>
</span><span
style=3D"color:rgb(102,102,=
0)">};</span><span><br>
</span><code><span
style=3D"color:rgb(0,0,13=
6)">bool</span><span>
</span><span
style=3D"color:rgb(0,0,13=
6)">operator</span><span
style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,1=
36)">const</span><span>
</span><span
style=3D"color:rgb(102,0,=
102)">Foo</span><span
style=3D"color:rgb(102,102,0)">&</span><span> l, const Foo& r</span=
><span
style=3D"color:rgb(102,102,0)">)</span><span> {<br>
=A0 return l.m1 =3D=3D r.=
m1
&& l.m2 =3D=3D
r.m2 && l.m3
=3D=3D r.m3;<br>
}<br>
bool
operator<(const
Foo& l, const
Foo& r) {<br>
=A0=A0=A0 bool result=3Df=
alse;<br>
=A0=A0=A0 result =3D resu=
lt ||
l.m1 <=A0 r.m1;<br>
=A0=A0=A0 result =3D resu=
lt ||
l.m1 =3D=3D r.m1
&& l.m2 <=A0
l.m2;<br>
=A0=A0=A0 result =3D resu=
lt ||
l.m1 =3D=3D r.m1
&& l.m2 =3D=3D
l.m2 && l.m3
<=A0 l.m3;<br>
=A0=A0=A0 return result;<=
br>
}<br>
</span><span
style=3D"color:rgb(102,10=
2,0)"></span></code></div>
</code></div>
<br>
(I hope noone is surprised on
the code). Now, operator=3D=3D is
not so bad, but operator< is
horrible if you have 5+ members.
We had a variadic macro to get
less mistakes on implementing
the operators, but it is very
hard to make it readable, and
still requires typing the member
names twice.<br>
<br>
It would be a incomparably lot
cleaner if instead of the above,
we could just write<br>
<div style=3D"border:1px solid
rgb(187,187,187);background-color=
:rgb(250,250,250)"><code>
<div><code><span
style=3D"color:rgb(0,0,13=
6)">struct</span><span>
</span><span
style=3D"color:rgb(102,0,=
102)">Foo</span><span>
</span><span
style=3D"color:rgb(102,10=
2,0)">{</span><span><br>
=A0 </span><span
style=3D"color:rgb(102,0,=
102)">Member1</span><span>
m1</span><span
style=3D"color:rgb(102,10=
2,0)">;</span><span>
</span><span
style=3D"color:rgb(102,0,=
102)">Member2</span><span>
m2</span><span
style=3D"color:rgb(102,10=
2,0)">;</span><span>
</span><span
style=3D"color:rgb(102,0,=
102)">Member3</span><span>
m3</span><span
style=3D"color:rgb(102,10=
2,0)">;</span><span><br>
</span><span
style=3D"color:rgb(102,10=
2,0)">};</span><span></span></code><br>
<code><code><span
style=3D"color:rgb(0,0,=
136)">bool</span><span>
</span><span
style=3D"color:rgb(0,0,=
136)">operator</span><span
style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,1=
36)">const</span><span>
</span><span
style=3D"color:rgb(102,=
0,102)">Foo</span><span
style=3D"color:rgb(102,102,0)">&</span><span> l, const Foo& r</span=
><span
style=3D"color:rgb(102,102,0)">)</span><span> =3D default;</span></code></c=
ode><span
style=3D"color:rgb(102,102,0)"></span><br>
<code><code><code><span
style=3D"color:rgb(0,=
0,136)">bool</span><span>
</span><span
style=3D"color:rgb(0,=
0,136)">operator</span><span
style=3D"color:rgb(102,102,0)">< (</span><span
style=3D"color:rgb(0,=
0,136)">const</span><span>
</span><span
style=3D"color:rgb(10=
2,0,102)">Foo</span><span
style=3D"color:rgb(102,102,0)">&</span><span> l, const Foo& r</span=
><span
style=3D"color:rgb(102,102,0)">)</span><span> =3D default;</span></code></c=
ode><span
style=3D"color:rgb(102,102,0)"></span></code></div>
</code></div>
<br>
Or alternatively, as a member
function:<br>
<code><span
style=3D"color:rgb(102,102,0)">
<div style=3D"border:1px solid
rgb(187,187,187);background-color:rgb(250,250,250)"><code>
<div><code><code><span
style=3D"color:rgb(=
0,0,136)">struct</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Foo=
</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</=
span><span
style=3D"color:rgb(0,0,0)"><br>
=A0 </span><span
style=3D"color:rgb(102,0,102)">Member1</span><span
style=3D"color:rgb(=
0,0,0)">
m1</span><span
style=3D"color:rgb(=
102,102,0)">;</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Mem=
ber2</span><span
style=3D"color:rgb(0,0,0)"> m2</span><span style=3D"color:rgb(102,102,0)">;=
</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Mem=
ber3</span><span
style=3D"color:rgb(0,0,0)"> m3</span><span style=3D"color:rgb(102,102,0)">;=
</span><span
style=3D"color:rgb(0,0,0)"><br>
</span></code></code>=
=A0
<code><code><span
style=3D"color:rgb(=
0,0,0)"><code><span
style=3D"color:rgb(102,102,0)"><code><code><code><code><span
style=3D"color:rg=
b(0,0,136)">bool</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">opera=
tor</span><span
style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,0=
)">const
Foo& r</span>=
<span
style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> =
=3D
default;</span></=
code></code><span
style=3D"color:rgb(102,102,0)"></span><br>
<code><code><code=
><span
style=3D"color:rgb(0,0,136)">=A0 bool</span><span style=3D"color:rgb(0,0,0)=
">
</span><span
style=3D"color:rg=
b(0,0,136)">operator</span><span
style=3D"color:rgb(102,102,0)">< (</span><span style=3D"color:rgb(0,0,0)=
">const
Foo& r</span>=
<span
style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> =
=3D
default;</span></=
code></code></code></code></code></span></code></span><span
style=3D"color:rgb(102,102,0)"><br>
};</span><span
style=3D"color:rgb(=
0,0,0)"></span></code><br>
<code><code><code><span
style=3D"color:rgb(0,0,0)"></span></code></code></code></code><span
style=3D"color:rgb(102,=
102,0)"></span></div>
</code></div>
<br>
</span></code>I guess the
non-member would need some
reflection-like feature (I don't
even think the benefit of
non-member comparators is that
great anyway), but the compiler
has every information to
generate the second.<br>
<br>
I already see the question, in
what order should operator<
do the comparison? I see two
options:<br>
a, same way as the constructors
work.<br>
b, implementation defined,
allowing for any possible
optimizations.<br>
I actually don't care what order
it is doing that, if I do, I can
still implement the function
normally.<br>
<br>
None of these should be
implicit, explicit "=3Ddefault"
should be there, to not break
any current code. I don't think
tweaking lookup rules for this
is a viable alternative.<br>
<code><span
style=3D"color:rgb(102,102,0)">=
<code><code><code><code><code><span
style=3D"color:rgb(0,0,0)"><br>
</span></code></code>=
</code></code></code></span></code>I
would be more than happy to help
working on such a proposal.<br>
<br>
2013. december 21., szombat
2:33:14 UTC+1 id=F5pontban Billy
O'Neal a k=F6vetkez=F5t =EDrta:
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>What would we expect to
happen if one of the
members is not comparable?
Ill formed?</div>
</div>
</blockquote>
<div><br>
That's exactly the same
problem as a =3Ddefault
default/copy/move
constructor/assignment op if
one of the members don't have
one. Although I can't remember
how this works for the current
=3Ddefault functions, I'd say in
that case it should be just
deleted to allow proper usage
in class templates with
template-param members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting away from
comparisons, it can be also
possible to generator
operator?=3D from operator? or
vica versa. A default
operator+ meaning memberwise
op+ is less useful in my
opinion than having op+
generated from op+=3D (what
should be consistent) and op*=3D
from op*. But this is a matter
of another thread.<br>
</div>
</div>
</blockquote>
</div>
</div>
I think the =3Ddefault notation could be
confusing if the operator is never
generated implicitly, so that there is
no "default" to start with. Maybe
something like =3Dauto would be clearer.<br=
>
</div>
</blockquote>
</div>
<div>
<div> -- <br>
=A0<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++
Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email to
<a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%2Bunsubscribe@=
isocpp.org"
target=3D"_blank">std-proposals+unsubscribe=
@isocpp.org</a>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org<=
/a>.<br>
Visit this group at <a
moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/"
target=3D"_blank">http://groups.google.com/=
a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
</div>
</div>
You received this message because you are subscribed to
a topic in the Google Groups "ISO C++ Standard - Future
Proposals" group.<br>
To unsubscribe from this topic, visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdi=
mIsOc/unsubscribe"
target=3D"_blank">https://groups.google.com/a/isocpp.org/=
d/topic/std-proposals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send
an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a=
>.
<div class=3D"im"><br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std=
-proposals/"
target=3D"_blank">http://groups.google.com/a/isocpp.org=
/group/std-proposals/</a>.<br>
</div>
</blockquote>
<br>
</div>
<div class=3D"HOEnZb">
<div class=3D"h5">
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"
target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a=
>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-p=
roposals/"
target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdi=
mIsOc/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-propo=
sals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:std-proposals=
+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------010803090906010901070102--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 23 Dec 2013 10:39:22 -0800
Raw View
--089e0116167eb044b204ee37f45c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
But construction and assignment don't give wildly different behavior when
the order of initialization is changed...
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Dec 23, 2013 at 10:35 AM, Oleg Smolsky <oleg@smolsky.net> wrote:
> This is the main question and I only have the obvious proposition - the
> declaration order. (this is in line with construction and assignment).
>
> Oleg.
>
>
> On 2013-12-23 10:32, Billy O'Neal wrote:
>
> What syntax would you use to indicate the correct order?
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Dec 23, 2013 at 10:23 AM, Oleg Smolsky <oleg@smolsky.net> wrote:
>
>> Hey Billy, I believe this is already present in C++11:
>> http://en.cppreference.com/w/cpp/utility/tuple/tie
>>
>> I wonder if generating it via some syntax would still make sense though?
>> (proposal v2)
>>
>> Oleg.
>>
>>
>> On 2013-12-23 10:16, Billy O'Neal wrote:
>>
>> operator=3D=3D is unambiguous because one can always fall back to
>> memberwise comparison, and there are no constraints on ordering. operato=
r<
>> is a tougher sell because the order by which the members would be compar=
ed
>> isn't obvious, but has a big impact on lexicographic ordering of the typ=
es.
>>
>> Rather than an =3Ddefault for that, I think a library makes more sense.
>> Something like:
>>
>> class lexicographical_less
>> {
>> bool isLess;
>> bool isKnown;
>> public:
>> lexicographical_less() : isLess(false), isKnown(false) {}
>> lexicographical_less(lexicographical_less const&) =3D delete;
>> lexicographical_less& operator=3D(lexicographical_less const&) =3D d=
elete;
>> template <typename Left, typename Right>
>> lexicographical_less& add(Left const& lhs, Right const& rhs)
>> {
>> if (isKnown || lhs =3D=3D rhs) return;
>> isKnown =3D true;
>> isLess =3D lhs < rhs;
>> return *this;
>> }
>> bool get() const
>> {
>> return isKnown && isLess;
>> }
>> };
>> class client
>> {
>> Member1 m1; Member2 m2; Member3 m3;
>> public:
>> bool operator<(client const& rhs) const // as usual
>> {
>> return lexicographical_less().add(m1, rhs.m1).add(m2,
>> rhs.m2).add(m3m, rhs.m3).get();
>> }
>> };
>>
>> Here the type designer explicitly declares the less-than comparison
>> order. (Plus, this requires no new additions to the core language)
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Mon, Dec 23, 2013 at 9:17 AM, <corentin.schreiber@cea.fr> wrote:
>>
>>> On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg Smolsky wrote:
>>>
>>>> Indeed, operator<() is the next logical step here, and my motivation
>>>> is exactly the same to what you mentioned. This, however, moves types =
from
>>>> "regular" to "totally ordered" using Stepanov's terms. (btw, you can u=
se
>>>> std::tie for implementing it).
>>>>
>>>> Now, back to equality. I'm trying to implement the code-gen in Clang.
>>>> If successful, I'll get a proposal number and submit a draft for the
>>>> absolute minimal feature.
>>>>
>>>> Oleg.
>>>>
>>>> On 2013-12-22 09:13, R=C3=B3bert D=C3=A1vid wrote:
>>>>
>>>> I too thought about this a while ago, and not only for operator=3D=3D,=
but
>>>> also for operator<, <=3D, >, >=3D. I used to work with a codebase that=
had
>>>> extended amount of std::maps with compound keys. For each key, we had =
to
>>>> write both operator=3D=3D and operator< (as std::map needs that), with=
the
>>>> following code:
>>>> struct Foo {
>>>> Member1 m1; Member2 m2; Member3 m3;
>>>> };
>>>> bool operator=3D=3D(const Foo& l, const Foo& r) {
>>>> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m3;
>>>> }
>>>> bool operator<(const Foo& l, const Foo& r) {
>>>> bool result=3Dfalse;
>>>> result =3D result || l.m1 < r.m1;
>>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
>>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2 && l.m3 =
< l.m3;
>>>> return result;
>>>> }
>>>>
>>>> (I hope noone is surprised on the code). Now, operator=3D=3D is not so=
bad,
>>>> but operator< is horrible if you have 5+ members. We had a variadic ma=
cro
>>>> to get less mistakes on implementing the operators, but it is very har=
d to
>>>> make it readable, and still requires typing the member names twice.
>>>>
>>>> It would be a incomparably lot cleaner if instead of the above, we
>>>> could just write
>>>> struct Foo {
>>>> Member1 m1; Member2 m2; Member3 m3;
>>>> };
>>>> bool operator=3D=3D(const Foo& l, const Foo& r) =3D default;
>>>> bool operator< (const Foo& l, const Foo& r) =3D default;
>>>>
>>>> Or alternatively, as a member function:
>>>> struct Foo {
>>>> Member1 m1; Member2 m2; Member3 m3;
>>>> bool operator=3D=3D(const Foo& r) =3D default;
>>>> bool operator< (const Foo& r) =3D default;
>>>> };
>>>>
>>>> I guess the non-member would need some reflection-like feature (I don'=
t
>>>> even think the benefit of non-member comparators is that great anyway)=
, but
>>>> the compiler has every information to generate the second.
>>>>
>>>> I already see the question, in what order should operator< do the
>>>> comparison? I see two options:
>>>> a, same way as the constructors work.
>>>> b, implementation defined, allowing for any possible optimizations.
>>>> I actually don't care what order it is doing that, if I do, I can stil=
l
>>>> implement the function normally.
>>>>
>>>> None of these should be implicit, explicit "=3Ddefault" should be ther=
e,
>>>> to not break any current code. I don't think tweaking lookup rules for=
this
>>>> is a viable alternative.
>>>>
>>>> I would be more than happy to help working on such a proposal.
>>>>
>>>> 2013. december 21., szombat 2:33:14 UTC+1 id=C5=91pontban Billy O'Neal=
a
>>>> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>>>>
>>>>> What would we expect to happen if one of the members is not
>>>>> comparable? Ill formed?
>>>>>
>>>>
>>>> That's exactly the same problem as a =3Ddefault default/copy/move
>>>> constructor/assignment op if one of the members don't have one. Althou=
gh I
>>>> can't remember how this works for the current =3Ddefault functions, I'=
d say
>>>> in that case it should be just deleted to allow proper usage in class
>>>> templates with template-param members.
>>>>
>>>> Regards, Robert
>>>>
>>>> PS: Drifting away from comparisons, it can be also possible to
>>>> generator operator?=3D from operator? or vica versa. A default operato=
r+
>>>> meaning memberwise op+ is less useful in my opinion than having op+
>>>> generated from op+=3D (what should be consistent) and op*=3D from op*.=
But this
>>>> is a matter of another thread.
>>>>
>>>> I think the =3Ddefault notation could be confusing if the operator is
>>>> never generated implicitly, so that there is no "default" to start wit=
h.
>>>> Maybe something like =3Dauto would be clearer.
>>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>>
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e0116167eb044b204ee37f45c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">But construction and assignment don't give wildly diff=
erent behavior when the order of initialization is changed...</div><div cla=
ss=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'=
;Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/=
users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/8=
2320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 10:35 AM, Oleg S=
molsky <span dir=3D"ltr"><<a href=3D"mailto:oleg@smolsky.net" target=3D"=
_blank">oleg@smolsky.net</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>This is the main question and I only
have the obvious proposition - the declaration order. (this is in
line with construction and assignment).<span class=3D"HOEnZb"><font c=
olor=3D"#888888"><br>
<br>
Oleg.</font></span><div><div class=3D"h5"><br>
<br>
On 2013-12-23 10:32, Billy O'Neal wrote:<br>
</div></div></div><div><div class=3D"h5">
<blockquote type=3D"cite">
<div dir=3D"ltr">What syntax would you use to indicate the correct
order?</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_b=
lank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-onea=
l" target=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></=
div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 10:23 AM, Oleg
Smolsky <span dir=3D"ltr"><<a href=3D"mailto:oleg@smolsky.net"=
target=3D"_blank">oleg@smolsky.net</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Hey Billy, I believe this is already present in
C++11:<br>
=C2=A0=C2=A0=C2=A0 <a href=3D"http://en.cppreference.com/w/=
cpp/utility/tuple/tie" target=3D"_blank">http://en.cppreference.com/w/cpp/u=
tility/tuple/tie</a><br>
<br>
I wonder if generating it via some syntax would still
make sense though? (proposal v2)<br>
<br>
Oleg.
<div>
<div><br>
<br>
On 2013-12-23 10:16, Billy O'Neal wrote:<br>
</div>
</div>
</div>
<blockquote type=3D"cite">
<div>
<div>
<div dir=3D"ltr">
<div>operator=3D=3D is unambiguous because one can
always fall back to memberwise comparison, and
there are no constraints on ordering.
operator< is a tougher sell because the order
by which the members would be compared isn't
obvious, but has a big impact on lexicographic
ordering of the types.</div>
<div><br>
</div>
<div>Rather than an =3Ddefault for that,=C2=A0I think=
a
library makes more sense. Something like:</div>
<div><br>
</div>
<div><font face=3D"courier new,monospace">class
lexicographical_less<br>
{<br>
=C2=A0=C2=A0=C2=A0 bool isLess;<br>
=C2=A0=C2=A0=C2=A0 bool isKnown;<br>
public:<br>
=C2=A0=C2=A0=C2=A0 lexicographical_less() : isLes=
s(false),
isKnown(false) {}<br>
=C2=A0=C2=A0=C2=A0 lexicographical_less(lexicogra=
phical_less
const&) =3D delete;<br>
=C2=A0=C2=A0=C2=A0 lexicographical_less&
operator=3D(lexicographical_less const&) =3D
delete;<br>
=C2=A0=C2=A0=C2=A0 template <typename Left, ty=
pename
Right><br>
=C2=A0=C2=A0=C2=A0 lexicographical_less& add(=
Left
const& lhs, Right const& rhs)<br>
=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (is=
Known || lhs =3D=3D rhs) return;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 isKnow=
n =3D true;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 isLess=
=3D lhs < rhs;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return=
*this;<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 bool get() const<br>
=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return=
isKnown && isLess;<br>
=C2=A0=C2=A0=C2=A0 }<br>
};</font></div>
<div><font face=3D"courier new,monospace">class
client<br>
{<br>
=C2=A0=C2=A0=C2=A0 Member1 m1; Member2 m2; Member=
3 m3;<br>
public:<br>
=C2=A0=C2=A0=C2=A0 bool operator<(client const=
& rhs)
const // as usual<br>
=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return=
lexicographical_less().add(m1,
rhs.m1).add(m2, rhs.m2).add(m3m,
rhs.m3).get();<br>
=C2=A0=C2=A0=C2=A0 }<br>
};</font></div>
<div><br>
</div>
<div>Here the type designer explicitly declares
the less-than comparison order. (Plus, this
requires no new additions to the core language)<br>
</div>
</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div> Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/=
" target=3D"_blank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>
<div>Malware Response Instructor -
BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at
9:17 AM, <span dir=3D"ltr"><<a href=3D"mailto:co=
rentin.schreiber@cea.fr" target=3D"_blank">corentin.schreiber@cea.fr</a>>=
;</span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>
<div>On Sunday, December 22, 2013 6:58:45
PM UTC+1, Oleg Smolsky wrote:</div>
</div>
<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>
<div>
<div>Indeed, operator<() is the
next logical step here, and my
motivation is exactly the same to
what you mentioned. This, however,
moves types from "regular" =
to
"totally ordered" using Ste=
panov's
terms. (btw, you can use std::tie
for implementing it).<br>
<br>
Now, back to equality. I'm trying
to implement the code-gen in
Clang. If successful, I'll get a
proposal number and submit a draft
for the absolute minimal feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13, R=C3=B3bert D=C3=
=A1vid
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">I too thought about
this a while ago, and not only
for operator=3D=3D, but also for
operator<, <=3D, >,
>=3D. I used to work with a
codebase that had extended
amount of std::maps with
compound keys. For each key, we
had to write both operator=3D=3D an=
d
operator< (as std::map needs
that), with the following code:<br>
<div style=3D"border:1px solid rgb(=
187,187,187);background-color:rgb(250,250,250)"><code>
<div><span style=3D"color:rgb(0=
,0,136)">struct</span><span>
</span><span style=3D"color:r=
gb(102,0,102)">Foo</span><span>
</span><span style=3D"color:r=
gb(102,102,0)">{</span><span><br>
=C2=A0 </span><span style=
=3D"color:rgb(102,0,102)">Member1</span><span>
m1</span><span style=3D"col=
or:rgb(102,102,0)">;</span><span>
</span><span style=3D"color:r=
gb(102,0,102)">Member2</span><span>
m2</span><span style=3D"col=
or:rgb(102,102,0)">;</span><span>
</span><span style=3D"color:r=
gb(102,0,102)">Member3</span><span>
m3</span><span style=3D"col=
or:rgb(102,102,0)">;</span><span><br>
</span><span style=3D"color:r=
gb(102,102,0)">};</span><span><br>
</span><code><span style=3D"c=
olor:rgb(0,0,136)">bool</span><span>
</span><span style=3D"color=
:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)">=3D=3D(<=
/span><span style=3D"color:rgb(0,0,136)">const</span><span>
</span><span style=3D"color=
:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(102,102,0)">&</span=
><span> l, const Foo& r</span><span style=3D"color:rgb(102,102,0)">)</s=
pan><span> {<br>
=C2=A0 return l.m1 =3D=3D=
r.m1
&& l.m2 =3D=3D
r.m2 && l.m3
=3D=3D r.m3;<br>
}<br>
bool
operator<(const
Foo& l, const
Foo& r) {<br>
=C2=A0=C2=A0=C2=A0 bool r=
esult=3Dfalse;<br>
=C2=A0=C2=A0=C2=A0 result=
=3D result ||
l.m1 <=C2=A0 r.m1;<br>
=C2=A0=C2=A0=C2=A0 result=
=3D result ||
l.m1 =3D=3D r.m1
&& l.m2 <=C2=
=A0
l.m2;<br>
=C2=A0=C2=A0=C2=A0 result=
=3D result ||
l.m1 =3D=3D r.m1
&& l.m2 =3D=3D
l.m2 && l.m3
<=C2=A0 l.m3;<br>
=C2=A0=C2=A0=C2=A0 return=
result;<br>
}<br>
</span><span style=3D"color=
:rgb(102,102,0)"></span></code></div>
</code></div>
<br>
(I hope noone is surprised on
the code). Now, operator=3D=3D is
not so bad, but operator< is
horrible if you have 5+ members.
We had a variadic macro to get
less mistakes on implementing
the operators, but it is very
hard to make it readable, and
still requires typing the member
names twice.<br>
<br>
It would be a incomparably lot
cleaner if instead of the above,
we could just write<br>
<div style=3D"border:1px solid rgb(=
187,187,187);background-color:rgb(250,250,250)"><code>
<div><code><span style=3D"color=
:rgb(0,0,136)">struct</span><span>
</span><span style=3D"color=
:rgb(102,0,102)">Foo</span><span>
</span><span style=3D"color=
:rgb(102,102,0)">{</span><span><br>
=C2=A0 </span><span style=
=3D"color:rgb(102,0,102)">Member1</span><span>
m1</span><span style=3D"c=
olor:rgb(102,102,0)">;</span><span>
</span><span style=3D"color=
:rgb(102,0,102)">Member2</span><span>
m2</span><span style=3D"c=
olor:rgb(102,102,0)">;</span><span>
</span><span style=3D"color=
:rgb(102,0,102)">Member3</span><span>
m3</span><span style=3D"c=
olor:rgb(102,102,0)">;</span><span><br>
</span><span style=3D"color=
:rgb(102,102,0)">};</span><span></span></code><br>
<code><code><span style=3D"co=
lor:rgb(0,0,136)">bool</span><span>
</span><span style=3D"col=
or:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)">=3D=3D=
(</span><span style=3D"color:rgb(0,0,136)">const</span><span>
</span><span style=3D"col=
or:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(102,102,0)">&</sp=
an><span> l, const Foo& r</span><span style=3D"color:rgb(102,102,0)">)<=
/span><span> =3D default;</span></code></code><span style=3D"color:rgb(102,=
102,0)"></span><br>
<code><code><code><span style=
=3D"color:rgb(0,0,136)">bool</span><span>
</span><span style=3D"c=
olor:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)"><=
(</span><span style=3D"color:rgb(0,0,136)">const</span><span>
</span><span style=3D"c=
olor:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(102,102,0)">&</=
span><span> l, const Foo& r</span><span style=3D"color:rgb(102,102,0)">=
)</span><span> =3D default;</span></code></code><span style=3D"color:rgb(10=
2,102,0)"></span></code></div>
</code></div>
<br>
Or alternatively, as a member
function:<br>
<code><span style=3D"color:rgb(102,=
102,0)">
<div style=3D"border:1px solid =
rgb(187,187,187);background-color:rgb(250,250,250)"><code>
<div><code><code><span styl=
e=3D"color:rgb(0,0,136)">struct</span><span style=3D"color:rgb(0,0,0)"> </s=
pan><span style=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb=
(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><span style=
=3D"color:rgb(0,0,0)"><br>
=C2=A0 </span><span=
style=3D"color:rgb(102,0,102)">Member1</span><span style=3D"color:rgb(0,0,=
0)">
m1</span><span styl=
e=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,0,102)">Member2</span><span style=3D"color:rg=
b(0,0,0)"> m2</span><span style=3D"color:rgb(102,102,0)">;</span><span styl=
e=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Member3=
</span><span style=3D"color:rgb(0,0,0)"> m3</span><span style=3D"color:rgb(=
102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>
</span></code></code>=
=C2=A0
<code><code><span style=
=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(102,102,0)"><code><cod=
e><code><code><span style=3D"color:rgb(0,0,136)">bool</span><span style=3D"=
color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">operator</span=
><span style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rg=
b(0,0,0)">const
Foo& r</span>=
<span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0=
)"> =3D
default;</span></=
code></code><span style=3D"color:rgb(102,102,0)"></span><br>
<code><code><code=
><span style=3D"color:rgb(0,0,136)">=C2=A0 bool</span><span style=3D"color:=
rgb(0,0,0)">
</span><span styl=
e=3D"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)=
">< (</span><span style=3D"color:rgb(0,0,0)">const
Foo& r</span>=
<span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0=
)"> =3D
default;</span></=
code></code></code></code></code></span></code></span><span style=3D"color:=
rgb(102,102,0)"><br>
};</span><span styl=
e=3D"color:rgb(0,0,0)"></span></code><br>
<code><code><code><span=
style=3D"color:rgb(0,0,0)"></span></code></code></code></code><span style=
=3D"color:rgb(102,102,0)"></span></div>
</code></div>
<br>
</span></code>I guess the
non-member would need some
reflection-like feature (I don'=
t
even think the benefit of
non-member comparators is that
great anyway), but the compiler
has every information to
generate the second.<br>
<br>
I already see the question, in
what order should operator<
do the comparison? I see two
options:<br>
a, same way as the constructors
work.<br>
b, implementation defined,
allowing for any possible
optimizations.<br>
I actually don't care what orde=
r
it is doing that, if I do, I can
still implement the function
normally.<br>
<br>
None of these should be
implicit, explicit "=3Ddefault=
"
should be there, to not break
any current code. I don't think
tweaking lookup rules for this
is a viable alternative.<br>
<code><span style=3D"color:rgb(102,=
102,0)"><code><code><code><code><code><span style=3D"color:rgb(0,0,0)"><br>
</span></code></code>=
</code></code></code></span></code>I
would be more than happy to help
working on such a proposal.<br>
<br>
2013. december 21., szombat
2:33:14 UTC+1 id=C5=91pontban Billy
O'Neal a k=C3=B6vetkez=C5=91t =
=C3=ADrta:
<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204=
,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>What would we expect to
happen if one of the
members is not comparable?
Ill formed?</div>
</div>
</blockquote>
<div><br>
That's exactly the same
problem as a =3Ddefault
default/copy/move
constructor/assignment op if
one of the members don't have
one. Although I can't remembe=
r
how this works for the current
=3Ddefault functions, I'd say=
in
that case it should be just
deleted to allow proper usage
in class templates with
template-param members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting away from
comparisons, it can be also
possible to generator
operator?=3D from operator? or
vica versa. A default
operator+ meaning memberwise
op+ is less useful in my
opinion than having op+
generated from op+=3D (what
should be consistent) and op*=3D
from op*. But this is a matter
of another thread.<br>
</div>
</div>
</blockquote>
</div>
</div>
I think the =3Ddefault notation could be
confusing if the operator is never
generated implicitly, so that there is
no "default" to start with. Maybe
something like =3Dauto would be clearer.<br=
>
</div>
</blockquote>
</div>
<div>
<div> -- <br>
=C2=A0<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++
Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email to
<a href=3D"mailto:std-proposals%2Bunsubscribe=
@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br=
>
To post to this group, send email to <a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp=
..org</a>.<br>
Visit this group at <a href=3D"http://groups.=
google.com/a/isocpp.org/group/std-proposals/" target=3D"_blank">http://grou=
ps.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=C2=A0<br>
--- <br>
</div>
</div>
You received this message because you are subscribed to
a topic in the Google Groups "ISO C++ Standard - Futur=
e
Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/unsubscribe"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-propo=
sals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send
an email to <a href=3D"mailto:std-proposals+unsubscribe@iso=
cpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.
<div><br>
To post to this group, send email to <a href=3D"mailto:st=
d-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a=
/isocpp.org/group/std-proposals/" target=3D"_blank">http://groups.google.co=
m/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</blockquote>
<br>
</div>
<div>
<div>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals=
"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a href=3D"mailto:std-proposals%2=
Bunsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp=
..org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-=
proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/i=
socpp.org/group/std-proposals/" target=3D"_blank">http://groups.google.com/=
a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" gro=
up.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.googl=
e.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/unsubscribe" target=3D=
"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpId=
imIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"=
_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@=
isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0116167eb044b204ee37f45c--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Mon, 23 Dec 2013 10:51:51 -0800
Raw View
This is a multi-part message in MIME format.
--------------050003020705050307040203
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: quoted-printable
What about cases where there is an inter-dependency in the fields'=20
constructors? Or when the fields have non-obvious side-effects, such as=20
registering themselves with an external entity?
On 2013-12-23 10:39, Billy O'Neal wrote:
> But construction and assignment don't give wildly different behavior=20
> when the order of initialization is changed...
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Dec 23, 2013 at 10:35 AM, Oleg Smolsky <oleg@smolsky.net=20
> <mailto:oleg@smolsky.net>> wrote:
>
> This is the main question and I only have the obvious proposition
> - the declaration order. (this is in line with construction and
> assignment).
>
> Oleg.
>
>
> On 2013-12-23 10:32, Billy O'Neal wrote:
>> What syntax would you use to indicate the correct order?
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Mon, Dec 23, 2013 at 10:23 AM, Oleg Smolsky <oleg@smolsky.net
>> <mailto:oleg@smolsky.net>> wrote:
>>
>> Hey Billy, I believe this is already present in C++11:
>> http://en.cppreference.com/w/cpp/utility/tuple/tie
>>
>> I wonder if generating it via some syntax would still make
>> sense though? (proposal v2)
>>
>> Oleg.
>>
>>
>> On 2013-12-23 10:16, Billy O'Neal wrote:
>>> operator=3D=3D is unambiguous because one can always fall back
>>> to memberwise comparison, and there are no constraints on
>>> ordering. operator< is a tougher sell because the order by
>>> which the members would be compared isn't obvious, but has a
>>> big impact on lexicographic ordering of the types.
>>>
>>> Rather than an =3Ddefault for that, I think a library makes
>>> more sense. Something like:
>>>
>>> class lexicographical_less
>>> {
>>> bool isLess;
>>> bool isKnown;
>>> public:
>>> lexicographical_less() : isLess(false), isKnown(false) {}
>>> lexicographical_less(lexicographical_less const&) =3D delete;
>>> lexicographical_less& operator=3D(lexicographical_less
>>> const&) =3D delete;
>>> template <typename Left, typename Right>
>>> lexicographical_less& add(Left const& lhs, Right const& rhs=
)
>>> {
>>> if (isKnown || lhs =3D=3D rhs) return;
>>> isKnown =3D true;
>>> isLess =3D lhs < rhs;
>>> return *this;
>>> }
>>> bool get() const
>>> {
>>> return isKnown && isLess;
>>> }
>>> };
>>> class client
>>> {
>>> Member1 m1; Member2 m2; Member3 m3;
>>> public:
>>> bool operator<(client const& rhs) const // as usual
>>> {
>>> return lexicographical_less().add(m1,
>>> rhs.m1).add(m2, rhs.m2).add(m3m, rhs.m3).get();
>>> }
>>> };
>>>
>>> Here the type designer explicitly declares the less-than
>>> comparison order. (Plus, this requires no new additions to
>>> the core language)
>>>
>>> Billy O'Neal
>>> https://github.com/BillyONeal/
>>> <https://bitbucket.org/BillyONeal/>
>>> http://stackoverflow.com/users/82320/billy-oneal
>>> Malware Response Instructor - BleepingComputer.com
>>>
>>>
>>> On Mon, Dec 23, 2013 at 9:17 AM, <corentin.schreiber@cea.fr
>>> <mailto:corentin.schreiber@cea.fr>> wrote:
>>>
>>> On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg
>>> Smolsky wrote:
>>>
>>> Indeed, operator<() is the next logical step here,
>>> and my motivation is exactly the same to what you
>>> mentioned. This, however, moves types from "regular"
>>> to "totally ordered" using Stepanov's terms. (btw,
>>> you can use std::tie for implementing it).
>>>
>>> Now, back to equality. I'm trying to implement the
>>> code-gen in Clang. If successful, I'll get a
>>> proposal number and submit a draft for the absolute
>>> minimal feature.
>>>
>>> Oleg.
>>>
>>> On 2013-12-22 09:13, R=F3bert D=E1vid wrote:
>>>> I too thought about this a while ago, and not only
>>>> for operator=3D=3D, but also for operator<, <=3D, >, >=
=3D.
>>>> I used to work with a codebase that had extended
>>>> amount of std::maps with compound keys. For each
>>>> key, we had to write both operator=3D=3D and operator<
>>>> (as std::map needs that), with the following code:
>>>> |
>>>> structFoo{
>>>> Member1m1;Member2m2;Member3m3;
>>>> };
>>>> |booloperator=3D=3D(constFoo&l, const Foo& r){
>>>> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =
=3D=3D r.m3;
>>>> }
>>>> bool operator<(const Foo& l, const Foo& r) {
>>>> bool result=3Dfalse;
>>>> result =3D result || l.m1 < r.m1;
>>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.=
m2;
>>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=
=3D l.m2
>>>> && l.m3 < l.m3;
>>>> return result;
>>>> }
>>>> |
>>>> |
>>>>
>>>> (I hope noone is surprised on the code). Now,
>>>> operator=3D=3D is not so bad, but operator< is horribl=
e
>>>> if you have 5+ members. We had a variadic macro to
>>>> get less mistakes on implementing the operators,
>>>> but it is very hard to make it readable, and still
>>>> requires typing the member names twice.
>>>>
>>>> It would be a incomparably lot cleaner if instead
>>>> of the above, we could just write
>>>> |
>>>> |structFoo{
>>>> Member1m1;Member2m2;Member3m3;
>>>> };|
>>>> ||booloperator=3D=3D(constFoo&l, const Foo& r)=3D defa=
ult;||
>>>> |||booloperator< (constFoo&l, const Foo& r)=3D
>>>> default;|||
>>>> |
>>>>
>>>> Or alternatively, as a member function:
>>>> |
>>>> |
>>>> ||structFoo{
>>>> Member1m1;Member2m2;Member3m3;
>>>> || |||||||booloperator=3D=3D(const Foo& r)=3D default;=
||
>>>> ||| booloperator< (const Foo& r)=3D default;||||||
>>>> };|
>>>> |||||||
>>>> |
>>>>
>>>> |I guess the non-member would need some
>>>> reflection-like feature (I don't even think the
>>>> benefit of non-member comparators is that great
>>>> anyway), but the compiler has every information to
>>>> generate the second.
>>>>
>>>> I already see the question, in what order should
>>>> operator< do the comparison? I see two options:
>>>> a, same way as the constructors work.
>>>> b, implementation defined, allowing for any
>>>> possible optimizations.
>>>> I actually don't care what order it is doing that,
>>>> if I do, I can still implement the function normally.
>>>>
>>>> None of these should be implicit, explicit
>>>> "=3Ddefault" should be there, to not break any
>>>> current code. I don't think tweaking lookup rules
>>>> for this is a viable alternative.
>>>> ||||||
>>>> ||||||I would be more than happy to help working on
>>>> such a proposal.
>>>>
>>>> 2013. december 21., szombat 2:33:14 UTC+1
>>>> id=F5pontban Billy O'Neal a k=F6vetkez=F5t =EDrta:
>>>>
>>>> What would we expect to happen if one of the
>>>> members is not comparable? Ill formed?
>>>>
>>>>
>>>> That's exactly the same problem as a =3Ddefault
>>>> default/copy/move constructor/assignment op if one
>>>> of the members don't have one. Although I can't
>>>> remember how this works for the current =3Ddefault
>>>> functions, I'd say in that case it should be just
>>>> deleted to allow proper usage in class templates
>>>> with template-param members.
>>>>
>>>> Regards, Robert
>>>>
>>>> PS: Drifting away from comparisons, it can be also
>>>> possible to generator operator?=3D from operator? or
>>>> vica versa. A default operator+ meaning memberwise
>>>> op+ is less useful in my opinion than having op+
>>>> generated from op+=3D (what should be consistent) and
>>>> op*=3D from op*. But this is a matter of another threa=
d.
>>> I think the =3Ddefault notation could be confusing if
>>> the operator is never generated implicitly, so that
>>> there is no "default" to start with. Maybe something
>>> like =3Dauto would be clearer.
>>>
>>> --=20
>>>
>>> ---
>>> You received this message because you are subscribed to
>>> the Google Groups "ISO C++ Standard - Future Proposals"
>>> group.
>>> To unsubscribe from this group and stop receiving emails
>>> from it, send an email to
>>> std-proposals+unsubscribe@isocpp.org
>>> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
>>> To post to this group, send email to
>>> std-proposals@isocpp.org <mailto:std-proposals@isocpp.org>.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>>
>>> --=20
>>>
>>> ---
>>> You received this message because you are subscribed to a
>>> topic in the Google Groups "ISO C++ Standard - Future
>>> Proposals" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7r=
pIdimIsOc/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an
>>> email to std-proposals+unsubscribe@isocpp.org
>>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>>>
>>> To post to this group, send email to
>>> std-proposals@isocpp.org <mailto:std-proposals@isocpp.org>.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>> --=20
>>
>> ---
>> You received this message because you are subscribed to the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>> --=20
>>
>> ---
>> You received this message because you are subscribed to a topic
>> in the Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdim=
IsOc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email
>> to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --=20
>
> ---
> You received this message because you are subscribed to a topic in the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to=20
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------050003020705050307040203
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">What about cases where there is an
inter-dependency in the fields' constructors? Or when the fields
have non-obvious side-effects, such as registering themselves with
an external entity?<br>
<br>
On 2013-12-23 10:39, Billy O'Neal wrote:<br>
</div>
<blockquote
cite=3D"mid:CAPBZbvw9ySV77_NBO9FosUSZJA=3DZmgKahsYPXyaOZxZpW0=3Dwdw@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">But construction and assignment don't give wildly
different behavior when the order of initialization is
changed...</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a moz-do-not-send=3D"true"
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank=
">https://github.com/BillyONeal/</a></div>
<div><a moz-do-not-send=3D"true"
href=3D"http://stackoverflow.com/users/82320/billy-oneal"
target=3D"_blank">http://stackoverflow.com/users/82320/bill=
y-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 10:35 AM, Oleg
Smolsky <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:oleg@smolsky.net" target=3D"_blank">oleg@smols=
ky.net</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>This is the main question and I only have the obvious
proposition - the declaration order. (this is in line
with construction and assignment).<span class=3D"HOEnZb"><f=
ont
color=3D"#888888"><br>
<br>
Oleg.</font></span>
<div>
<div class=3D"h5"><br>
<br>
On 2013-12-23 10:32, Billy O'Neal wrote:<br>
</div>
</div>
</div>
<div>
<div class=3D"h5">
<blockquote type=3D"cite">
<div dir=3D"ltr">What syntax would you use to indicate
the correct order?</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a moz-do-not-send=3D"true"
href=3D"https://bitbucket.org/BillyONeal/"
target=3D"_blank">https://github.com/BillyONe=
al/</a></div>
<div><a moz-do-not-send=3D"true"
href=3D"http://stackoverflow.com/users/82320/=
billy-oneal"
target=3D"_blank">http://stackoverflow.com/us=
ers/82320/billy-oneal</a></div>
<div>Malware Response Instructor -
BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at
10:23 AM, Oleg Smolsky <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:oleg@smolsky.net"
target=3D"_blank">oleg@smolsky.net</a>></spa=
n>
wrote:<br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Hey Billy, I believe this is already
present in C++11:<br>
=A0=A0=A0 <a moz-do-not-send=3D"true"
href=3D"http://en.cppreference.com/w/cpp/ut=
ility/tuple/tie"
target=3D"_blank">http://en.cppreference.co=
m/w/cpp/utility/tuple/tie</a><br>
<br>
I wonder if generating it via some syntax
would still make sense though? (proposal
v2)<br>
<br>
Oleg.
<div>
<div><br>
<br>
On 2013-12-23 10:16, Billy O'Neal
wrote:<br>
</div>
</div>
</div>
<blockquote type=3D"cite">
<div>
<div>
<div dir=3D"ltr">
<div>operator=3D=3D is unambiguous
because one can always fall back
to memberwise comparison, and
there are no constraints on
ordering. operator< is a
tougher sell because the order by
which the members would be
compared isn't obvious, but has a
big impact on lexicographic
ordering of the types.</div>
<div><br>
</div>
<div>Rather than an =3Ddefault for
that,=A0I think a library makes more
sense. Something like:</div>
<div><br>
</div>
<div><font face=3D"courier
new,monospace">class
lexicographical_less<br>
{<br>
=A0=A0=A0 bool isLess;<br>
=A0=A0=A0 bool isKnown;<br>
public:<br>
=A0=A0=A0 lexicographical_less() :
isLess(false), isKnown(false) {}<br=
>
=A0=A0=A0
lexicographical_less(lexicographica=
l_less
const&) =3D delete;<br>
=A0=A0=A0 lexicographical_less&
operator=3D(lexicographical_less
const&) =3D delete;<br>
=A0=A0=A0 template <typename Lef=
t,
typename Right><br>
=A0=A0=A0 lexicographical_less&
add(Left const& lhs, Right
const& rhs)<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 if (isKnown |=
| lhs =3D=3D
rhs) return;<br>
=A0=A0=A0=A0=A0=A0=A0 isKnown =3D t=
rue;<br>
=A0=A0=A0=A0=A0=A0=A0 isLess =3D lh=
s < rhs;<br>
=A0=A0=A0=A0=A0=A0=A0 return *this;=
<br>
=A0=A0=A0 }<br>
=A0=A0=A0 bool get() const<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return isKnow=
n
&& isLess;<br>
=A0=A0=A0 }<br>
};</font></div>
<div><font face=3D"courier
new,monospace">class client<br>
{<br>
=A0=A0=A0 Member1 m1; Member2 m2;
Member3 m3;<br>
public:<br>
=A0=A0=A0 bool operator<(client
const& rhs) const // as
usual<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return
lexicographical_less().add(m1,
rhs.m1).add(m2, rhs.m2).add(m3m,
rhs.m3).get();<br>
=A0=A0=A0 }<br>
};</font></div>
<div><br>
</div>
<div>Here the type designer
explicitly declares the less-than
comparison order. (Plus, this
requires no new additions to the
core language)<br>
</div>
</div>
<div class=3D"gmail_extra"><br
clear=3D"all">
<div>
<div dir=3D"ltr">
<div> Billy O'Neal</div>
<div><a moz-do-not-send=3D"true"
href=3D"https://bitbucket.org/B=
illyONeal/"
target=3D"_blank">https://githu=
b.com/BillyONeal/</a></div>
<div><a moz-do-not-send=3D"true"
href=3D"http://stackoverflow.co=
m/users/82320/billy-oneal"
target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor
- BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec
23, 2013 at 9:17 AM, <span
dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:corentin.schreiber=
@cea.fr"
target=3D"_blank">corentin.schrei=
ber@cea.fr</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>
<div>On Sunday, December 22,
2013 6:58:45 PM UTC+1,
Oleg Smolsky wrote:</div>
</div>
<blockquote
class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div text=3D"#000000"
bgcolor=3D"#FFFFFF">
<div>
<div>
<div>Indeed,
operator<() is
the next logical
step here, and my
motivation is
exactly the same to
what you mentioned.
This, however, moves
types from "regular"
to "totally ordered"
using Stepanov's
terms. (btw, you can
use std::tie for
implementing it).<br>
<br>
Now, back to
equality. I'm trying
to implement the
code-gen in Clang.
If successful, I'll
get a proposal
number and submit a
draft for the
absolute minimal
feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13,
R=F3bert D=E1vid wrote:=
<br>
</div>
<blockquote
type=3D"cite">
<div dir=3D"ltr">I too
thought about this
a while ago, and
not only for
operator=3D=3D, but
also for
operator<,
<=3D, >,
>=3D. I used to
work with a
codebase that had
extended amount of
std::maps with
compound keys. For
each key, we had
to write both
operator=3D=3D and
operator< (as
std::map needs
that), with the
following code:<br>
<div
style=3D"border:1px
solid
rgb(187,187,187);ba=
ckground-color:rgb(250,250,250)"><code>
<div><span
style=3D"color:rg=
b(0,0,136)">struct</span><span>
</span><span
style=3D"color:rg=
b(102,0,102)">Foo</span><span>
</span><span
style=3D"color:rg=
b(102,102,0)">{</span><span><br>
=A0 </span><span
style=3D"color:rgb(102,0,102)">Member1</span><span> m1</span><span
style=3D"color:rg=
b(102,102,0)">;</span><span>
</span><span
style=3D"color:rg=
b(102,0,102)">Member2</span><span>
m2</span><span
style=3D"color:rgb(102,102,0)">;</span><span> </span><span
style=3D"color:rg=
b(102,0,102)">Member3</span><span>
m3</span><span
style=3D"color:rgb(102,102,0)">;</span><span><br>
</span><span
style=3D"color:rg=
b(102,102,0)">};</span><span><br>
</span><code><spa=
n
style=3D"color:rgb(0,0,136)">bool</span><span> </span><span
style=3D"color:rg=
b(0,0,136)">operator</span><span
style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,1=
36)">const</span><span>
</span><span
style=3D"color:rg=
b(102,0,102)">Foo</span><span
style=3D"color:rgb(102,102,0)">&</span><span> l, const Foo& r</span=
><span
style=3D"color:rgb(102,102,0)">)</span><span> {<br>
=A0 return l.m1
=3D=3D r.m1
&&
l.m2 =3D=3D r.m2
&&
l.m3 =3D=3D r.m3;=
<br>
}<br>
bool
operator<(cons=
t
Foo& l,
const Foo&
r) {<br>
=A0=A0=A0 bool
result=3Dfalse;<b=
r>
=A0=A0=A0 result =
=3D
result || l.m1
<=A0 r.m1;<br>
=A0=A0=A0 result =
=3D
result || l.m1
=3D=3D r.m1
&&
l.m2 <=A0
l.m2;<br>
=A0=A0=A0 result =
=3D
result || l.m1
=3D=3D r.m1
&&
l.m2 =3D=3D l.m2
&&
l.m3 <=A0
l.m3;<br>
=A0=A0=A0 return
result;<br>
}<br>
</span><span
style=3D"color:rg=
b(102,102,0)"></span></code></div>
</code></div>
<br>
(I hope noone is
surprised on the
code). Now,
operator=3D=3D is not
so bad, but
operator< is
horrible if you
have 5+ members.
We had a variadic
macro to get less
mistakes on
implementing the
operators, but it
is very hard to
make it readable,
and still requires
typing the member
names twice.<br>
<br>
It would be a
incomparably lot
cleaner if instead
of the above, we
could just write<br>
<div
style=3D"border:1px
solid
rgb(187,187,187);ba=
ckground-color:rgb(250,250,250)"><code>
<div><code><span
style=3D"color:rgb(0,0,136)">struct</span><span> </span><span
style=3D"color:rg=
b(102,0,102)">Foo</span><span>
</span><span
style=3D"color:rg=
b(102,102,0)">{</span><span><br>
=A0 </span><span
style=3D"color:rgb(102,0,102)">Member1</span><span> m1</span><span
style=3D"color:rg=
b(102,102,0)">;</span><span>
</span><span
style=3D"color:rg=
b(102,0,102)">Member2</span><span>
m2</span><span
style=3D"color:rgb(102,102,0)">;</span><span> </span><span
style=3D"color:rg=
b(102,0,102)">Member3</span><span>
m3</span><span
style=3D"color:rgb(102,102,0)">;</span><span><br>
</span><span
style=3D"color:rg=
b(102,102,0)">};</span><span></span></code><br>
<code><code><span
style=3D"color:rgb(0,0,136)">bool</span><span> </span><span
style=3D"color:rg=
b(0,0,136)">operator</span><span
style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,1=
36)">const</span><span>
</span><span
style=3D"color:rg=
b(102,0,102)">Foo</span><span
style=3D"color:rgb(102,102,0)">&</span><span> l, const Foo& r</span=
><span
style=3D"color:rgb(102,102,0)">)</span><span> =3D default;</span></code></c=
ode><span
style=3D"color:rgb(102,102,0)"></span><br>
<code><code><code=
><span
style=3D"color:rgb(0,0,136)">bool</span><span> </span><span
style=3D"color:rg=
b(0,0,136)">operator</span><span
style=3D"color:rgb(102,102,0)">< (</span><span
style=3D"color:rg=
b(0,0,136)">const</span><span>
</span><span
style=3D"color:rg=
b(102,0,102)">Foo</span><span
style=3D"color:rgb(102,102,0)">&</span><span> l, const Foo& r</span=
><span
style=3D"color:rgb(102,102,0)">)</span><span> =3D default;</span></code></c=
ode><span
style=3D"color:rgb(102,102,0)"></span></code></div>
</code></div>
<br>
Or alternatively,
as a member
function:<br>
<code><span
style=3D"color:rg=
b(102,102,0)">
<div
style=3D"border:1=
px
solid
rgb(187,187,187);=
background-color:rgb(250,250,250)"><code>
<div><code><code>=
<span
style=3D"color:rgb(0,0,136)">struct</span><span style=3D"color:rgb(0,0,0)">
</span><span
style=3D"color:rg=
b(102,0,102)">Foo</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</=
span><span
style=3D"color:rgb(0,0,0)"><br>
=A0 </span><span
style=3D"color:rgb(102,0,102)">Member1</span><span
style=3D"color:rg=
b(0,0,0)">
m1</span><span
style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </=
span><span
style=3D"color:rgb(102,0,102)">Member2</span><span
style=3D"color:rg=
b(0,0,0)">
m2</span><span
style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </=
span><span
style=3D"color:rgb(102,0,102)">Member3</span><span
style=3D"color:rg=
b(0,0,0)">
m3</span><span
style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br=
>
</span></code></c=
ode>=A0
<code><code><span
style=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(102,102,0)"><code=
><code><code><code><span
style=3D"color:rgb(0,0,136)">bool</span><span style=3D"color:rgb(0,0,0)"> <=
/span><span
style=3D"color:rgb(0,0,136)">operator</span><span
style=3D"color:rg=
b(102,102,0)">=3D=3D(</span><span
style=3D"color:rgb(0,0,0)">const Foo& r</span><span
style=3D"color:rg=
b(102,102,0)">)</span><span
style=3D"color:rgb(0,0,0)"> =3D default;</span></code></code><span
style=3D"color:rg=
b(102,102,0)"></span><br>
<code><code><code=
><span
style=3D"color:rgb(0,0,136)">=A0 bool</span><span style=3D"color:rgb(0,0,0)=
">
</span><span
style=3D"color:rg=
b(0,0,136)">operator</span><span
style=3D"color:rgb(102,102,0)">< (</span><span style=3D"color:rgb(0,0,0)=
">const
Foo& r</span>=
<span
style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> =
=3D
default;</span></=
code></code></code></code></code></span></code></span><span
style=3D"color:rgb(102,102,0)"><br>
};</span><span
style=3D"color:rgb(0,0,0)"></span></code><br>
<code><code><code=
><span
style=3D"color:rgb(0,0,0)"></span></code></code></code></code><span
style=3D"color:rg=
b(102,102,0)"></span></div>
</code></div>
<br>
</span></code>I
guess the
non-member would
need some
reflection-like
feature (I don't
even think the
benefit of
non-member
comparators is
that great
anyway), but the
compiler has every
information to
generate the
second.<br>
<br>
I already see the
question, in what
order should
operator< do
the comparison? I
see two options:<br>
a, same way as the
constructors work.<br=
>
b, implementation
defined, allowing
for any possible
optimizations.<br>
I actually don't
care what order it
is doing that, if
I do, I can still
implement the
function normally.<br=
>
<br>
None of these
should be
implicit, explicit
"=3Ddefault" should
be there, to not
break any current
code. I don't
think tweaking
lookup rules for
this is a viable
alternative.<br>
<code><span
style=3D"color:rg=
b(102,102,0)"><code><code><code><code><code><span
style=3D"color:rgb(0,0,0)"><br>
</span></code></c=
ode></code></code></code></span></code>I
would be more than
happy to help
working on such a
proposal.<br>
<br>
2013. december
21., szombat
2:33:14 UTC+1
id=F5pontban Billy
O'Neal a
k=F6vetkez=F5t =EDrta=
:
<blockquote
class=3D"gmail_quot=
e"
style=3D"margin:0px
0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>What
would we
expect to
happen if one
of the members
is not
comparable?
Ill formed?</div>
</div>
</blockquote>
<div><br>
That's exactly
the same problem
as a =3Ddefault
default/copy/move
constructor/assignm=
ent
op if one of the
members don't
have one.
Although I can't
remember how
this works for
the current
=3Ddefault
functions, I'd
say in that case
it should be
just deleted to
allow proper
usage in class
templates with
template-param
members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting
away from
comparisons, it
can be also
possible to
generator
operator?=3D from
operator? or
vica versa. A
default
operator+
meaning
memberwise op+
is less useful
in my opinion
than having op+
generated from
op+=3D (what
should be
consistent) and
op*=3D from op*.
But this is a
matter of
another thread.<br>
</div>
</div>
</blockquote>
</div>
</div>
I think the =3Ddefault
notation could be
confusing if the operator
is never generated
implicitly, so that there
is no "default" to start
with. Maybe something like
=3Dauto would be clearer.<br>
</div>
</blockquote>
</div>
<div>
<div> -- <br>
=A0<br>
--- <br>
You received this message
because you are subscribed
to the Google Groups "ISO
C++ Standard - Future
Proposals" group.<br>
To unsubscribe from this
group and stop receiving
emails from it, send an
email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%=
2Bunsubscribe@isocpp.org"
target=3D"_blank">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send
email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@=
isocpp.org"
target=3D"_blank">std-proposa=
ls@isocpp.org</a>.<br>
Visit this group at <a
moz-do-not-send=3D"true"
href=3D"http://groups.google.=
com/a/isocpp.org/group/std-proposals/"
target=3D"_blank">http://grou=
ps.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
</div>
</div>
You received this message because you are
subscribed to a topic in the Google Groups
"ISO C++ Standard - Future Proposals"
group.<br>
To unsubscribe from this topic, visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdi=
mIsOc/unsubscribe"
target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its
topics, send an email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@is=
ocpp.org"
target=3D"_blank">std-proposals+unsubscribe=
@isocpp.org</a>.
<div><br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.or=
g</a>.<br>
Visit this group at <a
moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp=
..org/group/std-proposals/"
target=3D"_blank">http://groups.google.co=
m/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</blockquote>
<br>
</div>
<div>
<div> -- <br>
=A0<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++
Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email to
<a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%2Bunsubscribe@=
isocpp.org"
target=3D"_blank">std-proposals+unsubscribe=
@isocpp.org</a>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org<=
/a>.<br>
Visit this group at <a
moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/"
target=3D"_blank">http://groups.google.com/=
a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed
to a topic in the Google Groups "ISO C++ Standard -
Future Proposals" group.<br>
To unsubscribe from this topic, visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdi=
mIsOc/unsubscribe"
target=3D"_blank">https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics,
send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
target=3D"_blank">std-proposals+unsubscribe@isocpp.or=
g</a>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/s=
td-proposals/"
target=3D"_blank">http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div>
</div>
</div>
<div class=3D"HOEnZb">
<div class=3D"h5">
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"
target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a=
>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-p=
roposals/"
target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdi=
mIsOc/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-propo=
sals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:std-proposals=
+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------050003020705050307040203--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 23 Dec 2013 10:53:32 -0800
Raw View
--089e0158a92e5d78f804ee3827f4
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
You can come up with cases that cause issues, yes, but not for the vast
majority of types. operator<, in contrast, is order-dependent in *all*
cases.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Dec 23, 2013 at 10:51 AM, Oleg Smolsky <oleg@smolsky.net> wrote:
> What about cases where there is an inter-dependency in the fields'
> constructors? Or when the fields have non-obvious side-effects, such as
> registering themselves with an external entity?
>
>
> On 2013-12-23 10:39, Billy O'Neal wrote:
>
> But construction and assignment don't give wildly different behavior when
> the order of initialization is changed...
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Dec 23, 2013 at 10:35 AM, Oleg Smolsky <oleg@smolsky.net> wrote:
>
>> This is the main question and I only have the obvious proposition - the
>> declaration order. (this is in line with construction and assignment).
>>
>> Oleg.
>>
>>
>> On 2013-12-23 10:32, Billy O'Neal wrote:
>>
>> What syntax would you use to indicate the correct order?
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Mon, Dec 23, 2013 at 10:23 AM, Oleg Smolsky <oleg@smolsky.net> wrote:
>>
>>> Hey Billy, I believe this is already present in C++11:
>>> http://en.cppreference.com/w/cpp/utility/tuple/tie
>>>
>>> I wonder if generating it via some syntax would still make sense though=
?
>>> (proposal v2)
>>>
>>> Oleg.
>>>
>>>
>>> On 2013-12-23 10:16, Billy O'Neal wrote:
>>>
>>> operator=3D=3D is unambiguous because one can always fall back to
>>> memberwise comparison, and there are no constraints on ordering. operat=
or<
>>> is a tougher sell because the order by which the members would be compa=
red
>>> isn't obvious, but has a big impact on lexicographic ordering of the ty=
pes.
>>>
>>> Rather than an =3Ddefault for that, I think a library makes more sense=
..
>>> Something like:
>>>
>>> class lexicographical_less
>>> {
>>> bool isLess;
>>> bool isKnown;
>>> public:
>>> lexicographical_less() : isLess(false), isKnown(false) {}
>>> lexicographical_less(lexicographical_less const&) =3D delete;
>>> lexicographical_less& operator=3D(lexicographical_less const&) =3D
>>> delete;
>>> template <typename Left, typename Right>
>>> lexicographical_less& add(Left const& lhs, Right const& rhs)
>>> {
>>> if (isKnown || lhs =3D=3D rhs) return;
>>> isKnown =3D true;
>>> isLess =3D lhs < rhs;
>>> return *this;
>>> }
>>> bool get() const
>>> {
>>> return isKnown && isLess;
>>> }
>>> };
>>> class client
>>> {
>>> Member1 m1; Member2 m2; Member3 m3;
>>> public:
>>> bool operator<(client const& rhs) const // as usual
>>> {
>>> return lexicographical_less().add(m1, rhs.m1).add(m2,
>>> rhs.m2).add(m3m, rhs.m3).get();
>>> }
>>> };
>>>
>>> Here the type designer explicitly declares the less-than comparison
>>> order. (Plus, this requires no new additions to the core language)
>>>
>>> Billy O'Neal
>>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>>> http://stackoverflow.com/users/82320/billy-oneal
>>> Malware Response Instructor - BleepingComputer.com
>>>
>>>
>>> On Mon, Dec 23, 2013 at 9:17 AM, <corentin.schreiber@cea.fr> wrote:
>>>
>>>> On Sunday, December 22, 2013 6:58:45 PM UTC+1, Oleg Smolsky wrote:
>>>>
>>>>> Indeed, operator<() is the next logical step here, and my
>>>>> motivation is exactly the same to what you mentioned. This, however, =
moves
>>>>> types from "regular" to "totally ordered" using Stepanov's terms. (bt=
w, you
>>>>> can use std::tie for implementing it).
>>>>>
>>>>> Now, back to equality. I'm trying to implement the code-gen in Clang.
>>>>> If successful, I'll get a proposal number and submit a draft for the
>>>>> absolute minimal feature.
>>>>>
>>>>> Oleg.
>>>>>
>>>>> On 2013-12-22 09:13, R=F3bert D=E1vid wrote:
>>>>>
>>>>> I too thought about this a while ago, and not only for operator=3D=3D=
, but
>>>>> also for operator<, <=3D, >, >=3D. I used to work with a codebase tha=
t had
>>>>> extended amount of std::maps with compound keys. For each key, we had=
to
>>>>> write both operator=3D=3D and operator< (as std::map needs that), wit=
h the
>>>>> following code:
>>>>> struct Foo {
>>>>> Member1 m1; Member2 m2; Member3 m3;
>>>>> };
>>>>> bool operator=3D=3D(const Foo& l, const Foo& r) {
>>>>> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m3;
>>>>> }
>>>>> bool operator<(const Foo& l, const Foo& r) {
>>>>> bool result=3Dfalse;
>>>>> result =3D result || l.m1 < r.m1;
>>>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
>>>>> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2 && l.m3=
< l.m3;
>>>>> return result;
>>>>> }
>>>>>
>>>>> (I hope noone is surprised on the code). Now, operator=3D=3D is not s=
o
>>>>> bad, but operator< is horrible if you have 5+ members. We had a varia=
dic
>>>>> macro to get less mistakes on implementing the operators, but it is v=
ery
>>>>> hard to make it readable, and still requires typing the member names =
twice.
>>>>>
>>>>> It would be a incomparably lot cleaner if instead of the above, we
>>>>> could just write
>>>>> struct Foo {
>>>>> Member1 m1; Member2 m2; Member3 m3;
>>>>> };
>>>>> bool operator=3D=3D(const Foo& l, const Foo& r) =3D default;
>>>>> bool operator< (const Foo& l, const Foo& r) =3D default;
>>>>>
>>>>> Or alternatively, as a member function:
>>>>> struct Foo {
>>>>> Member1 m1; Member2 m2; Member3 m3;
>>>>> bool operator=3D=3D(const Foo& r) =3D default;
>>>>> bool operator< (const Foo& r) =3D default;
>>>>> };
>>>>>
>>>>> I guess the non-member would need some reflection-like feature (I
>>>>> don't even think the benefit of non-member comparators is that great
>>>>> anyway), but the compiler has every information to generate the secon=
d.
>>>>>
>>>>> I already see the question, in what order should operator< do the
>>>>> comparison? I see two options:
>>>>> a, same way as the constructors work.
>>>>> b, implementation defined, allowing for any possible optimizations.
>>>>> I actually don't care what order it is doing that, if I do, I can
>>>>> still implement the function normally.
>>>>>
>>>>> None of these should be implicit, explicit "=3Ddefault" should be the=
re,
>>>>> to not break any current code. I don't think tweaking lookup rules fo=
r this
>>>>> is a viable alternative.
>>>>>
>>>>> I would be more than happy to help working on such a proposal.
>>>>>
>>>>> 2013. december 21., szombat 2:33:14 UTC+1 id=F5pontban Billy O'Neal a
>>>>> k=F6vetkez=F5t =EDrta:
>>>>>>
>>>>>> What would we expect to happen if one of the members is not
>>>>>> comparable? Ill formed?
>>>>>>
>>>>>
>>>>> That's exactly the same problem as a =3Ddefault default/copy/move
>>>>> constructor/assignment op if one of the members don't have one. Altho=
ugh I
>>>>> can't remember how this works for the current =3Ddefault functions, I=
'd say
>>>>> in that case it should be just deleted to allow proper usage in class
>>>>> templates with template-param members.
>>>>>
>>>>> Regards, Robert
>>>>>
>>>>> PS: Drifting away from comparisons, it can be also possible to
>>>>> generator operator?=3D from operator? or vica versa. A default operat=
or+
>>>>> meaning memberwise op+ is less useful in my opinion than having op+
>>>>> generated from op+=3D (what should be consistent) and op*=3D from op*=
.. But this
>>>>> is a matter of another thread.
>>>>>
>>>>> I think the =3Ddefault notation could be confusing if the operator i=
s
>>>>> never generated implicitly, so that there is no "default" to start wi=
th.
>>>>> Maybe something like =3Dauto would be clearer.
>>>>>
>>>> --
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>> To post to this group, send email to std-proposals@isocpp.org.
>>>> Visit this group at
>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsO=
c/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposals+unsubscribe@isocpp.org.
>>>
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e0158a92e5d78f804ee3827f4
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You can come up with cases that cause issues, yes, but not=
for the vast majority of types. operator<, in contrast, is order-depend=
ent in *all* cases.</div><div class=3D"gmail_extra"><br clear=3D"all"><div>=
<div dir=3D"ltr">
<div>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 10:51 AM, Oleg S=
molsky <span dir=3D"ltr"><<a href=3D"mailto:oleg@smolsky.net" target=3D"=
_blank">oleg@smolsky.net</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>What about cases where there is an
inter-dependency in the fields' constructors? Or when the fields
have non-obvious side-effects, such as registering themselves with
an external entity?<div><div class=3D"h5"><br>
<br>
On 2013-12-23 10:39, Billy O'Neal wrote:<br>
</div></div></div><div><div class=3D"h5">
<blockquote type=3D"cite">
<div dir=3D"ltr">But construction and assignment don't give wildl=
y
different behavior when the order of initialization is
changed...</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_b=
lank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-onea=
l" target=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></=
div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 10:35 AM, Oleg
Smolsky <span dir=3D"ltr"><<a href=3D"mailto:oleg@smolsky.net"=
target=3D"_blank">oleg@smolsky.net</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>This is the main question and I only have the obvious
proposition - the declaration order. (this is in line
with construction and assignment).<span><font color=3D"#888=
888"><br>
<br>
Oleg.</font></span>
<div>
<div><br>
<br>
On 2013-12-23 10:32, Billy O'Neal wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type=3D"cite">
<div dir=3D"ltr">What syntax would you use to indicate
the correct order?</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/=
" target=3D"_blank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>
<div>Malware Response Instructor -
BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec 23, 2013 at
10:23 AM, Oleg Smolsky <span dir=3D"ltr"><<a hre=
f=3D"mailto:oleg@smolsky.net" target=3D"_blank">oleg@smolsky.net</a>></s=
pan>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Hey Billy, I believe this is already
present in C++11:<br>
=A0=A0=A0 <a href=3D"http://en.cppreference.c=
om/w/cpp/utility/tuple/tie" target=3D"_blank">http://en.cppreference.com/w/=
cpp/utility/tuple/tie</a><br>
<br>
I wonder if generating it via some syntax
would still make sense though? (proposal
v2)<br>
<br>
Oleg.
<div>
<div><br>
<br>
On 2013-12-23 10:16, Billy O'Neal
wrote:<br>
</div>
</div>
</div>
<blockquote type=3D"cite">
<div>
<div>
<div dir=3D"ltr">
<div>operator=3D=3D is unambiguous
because one can always fall back
to memberwise comparison, and
there are no constraints on
ordering. operator< is a
tougher sell because the order by
which the members would be
compared isn't obvious, but has a
big impact on lexicographic
ordering of the types.</div>
<div><br>
</div>
<div>Rather than an =3Ddefault for
that,=A0I think a library makes more
sense. Something like:</div>
<div><br>
</div>
<div><font face=3D"courier
new,monospace">class
lexicographical_less<br>
{<br>
=A0=A0=A0 bool isLess;<br>
=A0=A0=A0 bool isKnown;<br>
public:<br>
=A0=A0=A0 lexicographical_less() :
isLess(false), isKnown(false) {}<br=
>
=A0=A0=A0
lexicographical_less(lexicographica=
l_less
const&) =3D delete;<br>
=A0=A0=A0 lexicographical_less&
operator=3D(lexicographical_less
const&) =3D delete;<br>
=A0=A0=A0 template <typename Lef=
t,
typename Right><br>
=A0=A0=A0 lexicographical_less&
add(Left const& lhs, Right
const& rhs)<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 if (isKnown |=
| lhs =3D=3D
rhs) return;<br>
=A0=A0=A0=A0=A0=A0=A0 isKnown =3D t=
rue;<br>
=A0=A0=A0=A0=A0=A0=A0 isLess =3D lh=
s < rhs;<br>
=A0=A0=A0=A0=A0=A0=A0 return *this;=
<br>
=A0=A0=A0 }<br>
=A0=A0=A0 bool get() const<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return isKnow=
n
&& isLess;<br>
=A0=A0=A0 }<br>
};</font></div>
<div><font face=3D"courier
new,monospace">class client<br>
{<br>
=A0=A0=A0 Member1 m1; Member2 m2;
Member3 m3;<br>
public:<br>
=A0=A0=A0 bool operator<(client
const& rhs) const // as
usual<br>
=A0=A0=A0 {<br>
=A0=A0=A0=A0=A0=A0=A0 return
lexicographical_less().add(m1,
rhs.m1).add(m2, rhs.m2).add(m3m,
rhs.m3).get();<br>
=A0=A0=A0 }<br>
};</font></div>
<div><br>
</div>
<div>Here the type designer
explicitly declares the less-than
comparison order. (Plus, this
requires no new additions to the
core language)<br>
</div>
</div>
<div class=3D"gmail_extra"><br clear=3D"a=
ll">
<div>
<div dir=3D"ltr">
<div> Billy O'Neal</div>
<div><a href=3D"https://bitbucket.o=
rg/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflo=
w.com/users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/u=
sers/82320/billy-oneal</a></div>
<div>Malware Response Instructor
- BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"gmail_quote">On Mon, Dec
23, 2013 at 9:17 AM, <span dir=3D"ltr=
"><<a href=3D"mailto:corentin.schreiber@cea.fr" target=3D"_blank">corent=
in.schreiber@cea.fr</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,2=
04,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>
<div>On Sunday, December 22,
2013 6:58:45 PM UTC+1,
Oleg Smolsky wrote:</div>
</div>
<blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid">
<div text=3D"#000000" bgcolor=
=3D"#FFFFFF">
<div>
<div>
<div>Indeed,
operator<() is
the next logical
step here, and my
motivation is
exactly the same to
what you mentioned.
This, however, moves
types from "regula=
r"
to "totally ordere=
d"
using Stepanov's
terms. (btw, you can
use std::tie for
implementing it).<br>
<br>
Now, back to
equality. I'm tryin=
g
to implement the
code-gen in Clang.
If successful, I'll
get a proposal
number and submit a
draft for the
absolute minimal
feature.<br>
<br>
Oleg.<br>
<br>
On 2013-12-22 09:13,
R=F3bert D=E1vid wrote:=
<br>
</div>
<blockquote type=3D"cite"=
>
<div dir=3D"ltr">I too
thought about this
a while ago, and
not only for
operator=3D=3D, but
also for
operator<,
<=3D, >,
>=3D. I used to
work with a
codebase that had
extended amount of
std::maps with
compound keys. For
each key, we had
to write both
operator=3D=3D and
operator< (as
std::map needs
that), with the
following code:<br>
<div style=3D"border:=
1px solid rgb(187,187,187);background-color:rgb(250,250,250)"><code>
<div><span style=
=3D"color:rgb(0,0,136)">struct</span><span>
</span><span styl=
e=3D"color:rgb(102,0,102)">Foo</span><span>
</span><span styl=
e=3D"color:rgb(102,102,0)">{</span><span><br>
=A0 </span><span =
style=3D"color:rgb(102,0,102)">Member1</span><span> m1</span><span style=3D=
"color:rgb(102,102,0)">;</span><span>
</span><span styl=
e=3D"color:rgb(102,0,102)">Member2</span><span>
m2</span><span st=
yle=3D"color:rgb(102,102,0)">;</span><span> </span><span style=3D"color:rgb=
(102,0,102)">Member3</span><span>
m3</span><span st=
yle=3D"color:rgb(102,102,0)">;</span><span><br>
</span><span styl=
e=3D"color:rgb(102,102,0)">};</span><span><br>
</span><code><spa=
n style=3D"color:rgb(0,0,136)">bool</span><span> </span><span style=3D"colo=
r:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)">=3D=3D(=
</span><span style=3D"color:rgb(0,0,136)">const</span><span>
</span><span styl=
e=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(102,102,0)">&=
amp;</span><span> l, const Foo& r</span><span style=3D"color:rgb(102,10=
2,0)">)</span><span> {<br>
=A0 return l.m1
=3D=3D r.m1
&&
l.m2 =3D=3D r.m2
&&
l.m3 =3D=3D r.m3;=
<br>
}<br>
bool
operator<(cons=
t
Foo& l,
const Foo&
r) {<br>
=A0=A0=A0 bool
result=3Dfalse;<b=
r>
=A0=A0=A0 result =
=3D
result || l.m1
<=A0 r.m1;<br>
=A0=A0=A0 result =
=3D
result || l.m1
=3D=3D r.m1
&&
l.m2 <=A0
l.m2;<br>
=A0=A0=A0 result =
=3D
result || l.m1
=3D=3D r.m1
&&
l.m2 =3D=3D l.m2
&&
l.m3 <=A0
l.m3;<br>
=A0=A0=A0 return
result;<br>
}<br>
</span><span styl=
e=3D"color:rgb(102,102,0)"></span></code></div>
</code></div>
<br>
(I hope noone is
surprised on the
code). Now,
operator=3D=3D is not
so bad, but
operator< is
horrible if you
have 5+ members.
We had a variadic
macro to get less
mistakes on
implementing the
operators, but it
is very hard to
make it readable,
and still requires
typing the member
names twice.<br>
<br>
It would be a
incomparably lot
cleaner if instead
of the above, we
could just write<br>
<div style=3D"border:=
1px solid rgb(187,187,187);background-color:rgb(250,250,250)"><code>
<div><code><span =
style=3D"color:rgb(0,0,136)">struct</span><span> </span><span style=3D"colo=
r:rgb(102,0,102)">Foo</span><span>
</span><span styl=
e=3D"color:rgb(102,102,0)">{</span><span><br>
=A0 </span><span =
style=3D"color:rgb(102,0,102)">Member1</span><span> m1</span><span style=3D=
"color:rgb(102,102,0)">;</span><span>
</span><span styl=
e=3D"color:rgb(102,0,102)">Member2</span><span>
m2</span><span st=
yle=3D"color:rgb(102,102,0)">;</span><span> </span><span style=3D"color:rgb=
(102,0,102)">Member3</span><span>
m3</span><span st=
yle=3D"color:rgb(102,102,0)">;</span><span><br>
</span><span styl=
e=3D"color:rgb(102,102,0)">};</span><span></span></code><br>
<code><code><span=
style=3D"color:rgb(0,0,136)">bool</span><span> </span><span style=3D"color=
:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)">=3D=3D(<=
/span><span style=3D"color:rgb(0,0,136)">const</span><span>
</span><span styl=
e=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(102,102,0)">&=
amp;</span><span> l, const Foo& r</span><span style=3D"color:rgb(102,10=
2,0)">)</span><span> =3D default;</span></code></code><span style=3D"color:=
rgb(102,102,0)"></span><br>
<code><code><code=
><span style=3D"color:rgb(0,0,136)">bool</span><span> </span><span style=3D=
"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)">&l=
t; (</span><span style=3D"color:rgb(0,0,136)">const</span><span>
</span><span styl=
e=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(102,102,0)">&=
amp;</span><span> l, const Foo& r</span><span style=3D"color:rgb(102,10=
2,0)">)</span><span> =3D default;</span></code></code><span style=3D"color:=
rgb(102,102,0)"></span></code></div>
</code></div>
<br>
Or alternatively,
as a member
function:<br>
<code><span style=3D"=
color:rgb(102,102,0)">
<div style=3D"bor=
der:1px solid rgb(187,187,187);background-color:rgb(250,250,250)"><code>
<div><code><code>=
<span style=3D"color:rgb(0,0,136)">struct</span><span style=3D"color:rgb(0,=
0,0)">
</span><span styl=
e=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,=
0,0)"><br>
=A0 </span><span =
style=3D"color:rgb(102,0,102)">Member1</span><span style=3D"color:rgb(0,0,0=
)">
m1</span><span st=
yle=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(102,0,102)">Member2</span><span style=3D"color:=
rgb(0,0,0)">
m2</span><span st=
yle=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(102,0,102)">Member3</span><span style=3D"color:=
rgb(0,0,0)">
m3</span><span st=
yle=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>
</span></code></c=
ode>=A0
<code><code><span=
style=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(102,102,0)"><cod=
e><code><code><code><span style=3D"color:rgb(0,0,136)">bool</span><span sty=
le=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">operator=
</span><span style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"co=
lor:rgb(0,0,0)">const Foo& r</span><span style=3D"color:rgb(102,102,0)"=
>)</span><span style=3D"color:rgb(0,0,0)"> =3D default;</span></code></code=
><span style=3D"color:rgb(102,102,0)"></span><br>
<code><code><code=
><span style=3D"color:rgb(0,0,136)">=A0 bool</span><span style=3D"color:rgb=
(0,0,0)">
</span><span styl=
e=3D"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)=
">< (</span><span style=3D"color:rgb(0,0,0)">const
Foo& r</span>=
<span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0=
)"> =3D
default;</span></=
code></code></code></code></code></span></code></span><span style=3D"color:=
rgb(102,102,0)"><br>
};</span><span st=
yle=3D"color:rgb(0,0,0)"></span></code><br>
<code><code><code=
><span style=3D"color:rgb(0,0,0)"></span></code></code></code></code><span =
style=3D"color:rgb(102,102,0)"></span></div>
</code></div>
<br>
</span></code>I
guess the
non-member would
need some
reflection-like
feature (I don't
even think the
benefit of
non-member
comparators is
that great
anyway), but the
compiler has every
information to
generate the
second.<br>
<br>
I already see the
question, in what
order should
operator< do
the comparison? I
see two options:<br>
a, same way as the
constructors work.<br=
>
b, implementation
defined, allowing
for any possible
optimizations.<br>
I actually don't
care what order it
is doing that, if
I do, I can still
implement the
function normally.<br=
>
<br>
None of these
should be
implicit, explicit
"=3Ddefault"=
; should
be there, to not
break any current
code. I don't
think tweaking
lookup rules for
this is a viable
alternative.<br>
<code><span style=3D"=
color:rgb(102,102,0)"><code><code><code><code><code><span style=3D"color:rg=
b(0,0,0)"><br>
</span></code></c=
ode></code></code></code></span></code>I
would be more than
happy to help
working on such a
proposal.<br>
<br>
2013. december
21., szombat
2:33:14 UTC+1
id=F5pontban Billy
O'Neal a
k=F6vetkez=F5t =EDrta=
:
<blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left=
-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>What
would we
expect to
happen if one
of the members
is not
comparable?
Ill formed?</div>
</div>
</blockquote>
<div><br>
That's exactly
the same problem
as a =3Ddefault
default/copy/move
constructor/assignm=
ent
op if one of the
members don't
have one.
Although I can'=
t
remember how
this works for
the current
=3Ddefault
functions, I'd
say in that case
it should be
just deleted to
allow proper
usage in class
templates with
template-param
members.<br>
<br>
Regards, Robert<br>
<br>
PS: Drifting
away from
comparisons, it
can be also
possible to
generator
operator?=3D from
operator? or
vica versa. A
default
operator+
meaning
memberwise op+
is less useful
in my opinion
than having op+
generated from
op+=3D (what
should be
consistent) and
op*=3D from op*.
But this is a
matter of
another thread.<br>
</div>
</div>
</blockquote>
</div>
</div>
I think the =3Ddefault
notation could be
confusing if the operator
is never generated
implicitly, so that there
is no "default" to =
start
with. Maybe something like
=3Dauto would be clearer.<br>
</div>
</blockquote>
</div>
<div>
<div> -- <br>
=A0<br>
--- <br>
You received this message
because you are subscribed
to the Google Groups "ISO
C++ Standard - Future
Proposals" group.<br>
To unsubscribe from this
group and stop receiving
emails from it, send an
email to <a href=3D"mailto:std-=
proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubsc=
ribe@isocpp.org</a>.<br>
To post to this group, send
email to <a href=3D"mailto:std-=
proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"=
http://groups.google.com/a/isocpp.org/group/std-proposals/" target=3D"_blan=
k">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
</div>
</div>
You received this message because you are
subscribed to a topic in the Google Groups
"ISO C++ Standard - Future Proposals&quo=
t;
group.<br>
To unsubscribe from this topic, visit <a href=
=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsO=
c/unsubscribe" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/t=
opic/std-proposals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its
topics, send an email to <a href=3D"mailto:st=
d-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubsc=
ribe@isocpp.org</a>.
<div><br>
To post to this group, send email to <a hre=
f=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocp=
p.org</a>.<br>
Visit this group at <a href=3D"http://group=
s.google.com/a/isocpp.org/group/std-proposals/" target=3D"_blank">http://gr=
oups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</blockquote>
<br>
</div>
<div>
<div> -- <br>
=A0<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++
Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email to
<a href=3D"mailto:std-proposals%2Bunsubscribe=
@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br=
>
To post to this group, send email to <a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp=
..org</a>.<br>
Visit this group at <a href=3D"http://groups.=
google.com/a/isocpp.org/group/std-proposals/" target=3D"_blank">http://grou=
ps.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed
to a topic in the Google Groups "ISO C++ Standard =
-
Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https:=
//groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/unsubscr=
ibe" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-p=
roposals/7rpIdimIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics,
send an email to <a href=3D"mailto:std-proposals+unsubs=
cribe@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a=
>.<br>
To post to this group, send email to <a href=3D"mailto:=
std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r>
Visit this group at <a href=3D"http://groups.google.com=
/a/isocpp.org/group/std-proposals/" target=3D"_blank">http://groups.google.=
com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div>
</div>
</div>
<div>
<div>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals=
"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a href=3D"mailto:std-proposals%2=
Bunsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp=
..org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-=
proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/i=
socpp.org/group/std-proposals/" target=3D"_blank">http://groups.google.com/=
a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" gro=
up.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.googl=
e.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/unsubscribe" target=3D=
"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpId=
imIsOc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"=
_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@=
isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0158a92e5d78f804ee3827f4--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 23 Dec 2013 13:01:16 -0600
Raw View
--001a11c38594079c9004ee3843b5
Content-Type: text/plain; charset=ISO-8859-1
On 23 December 2013 12:53, Billy O'Neal <billy.oneal@gmail.com> wrote:
> You can come up with cases that cause issues, yes, but not for the vast
> majority of types. operator<, in contrast, is order-dependent in *all*
> cases.
>
If you don't like the default order, implement your own! You are no worse
off than you are now by having a proposal like this one baked into the
language.
However, operator< should be implemented only in terms of operator< of the
members, as in:
struct W {
X x;
Y y;
Z z;
bool operator<(W const& r) const
{
if (x < r.x) return true;
if (r.x < x) return false;
if (y < r.y) return true;
if (r.y < y) return false;
return z < r.z;
}
};
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c38594079c9004ee3843b5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 23 December 2013 12:53, Billy O'Neal <span dir=3D"l=
tr"><<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.on=
eal@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">You can come up with cases =
that cause issues, yes, but not for the vast majority of types. operator<=
;, in contrast, is order-dependent in *all* cases.</div>
</blockquote><div><br></div><div>If you don't like the default order, i=
mplement your own! =A0You are no worse off than you are now by having a pro=
posal like this one baked into the language.</div><div><br></div><div>Howev=
er, operator< should be implemented only in terms of operator< of the=
members, as in:</div>
<div><br></div><div>struct W {</div><div>=A0 =A0 X x;</div><div>=A0 =A0 Y y=
;</div><div>=A0 =A0 Z z;</div><div><br></div><div>=A0 =A0 bool operator<=
(W const& r) const</div><div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 if (x =
< r.x) return true;</div>
<div>=A0 =A0 =A0 =A0 if (r.x < x) return false;</div><div>=A0 =A0 =A0 =
=A0 if (y < r.y) return true;</div><div>=A0 =A0 =A0 =A0 if (r.y < y) =
return false;</div><div>=A0 =A0 =A0 =A0 return z < r.z;</div><div>=A0 =
=A0 }</div><div>};=A0</div></div>-- <br>
=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1=
404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c38594079c9004ee3843b5--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 23 Dec 2013 11:17:40 -0800
Raw View
--001a11330af2a4592204ee387db0
Content-Type: text/plain; charset=ISO-8859-1
Fair enough :)
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Dec 23, 2013 at 11:01 AM, Nevin Liber <nevin@eviloverlord.com>wrote:
> On 23 December 2013 12:53, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>> You can come up with cases that cause issues, yes, but not for the vast
>> majority of types. operator<, in contrast, is order-dependent in *all*
>> cases.
>>
>
> If you don't like the default order, implement your own! You are no worse
> off than you are now by having a proposal like this one baked into the
> language.
>
> However, operator< should be implemented only in terms of operator< of the
> members, as in:
>
> struct W {
> X x;
> Y y;
> Z z;
>
> bool operator<(W const& r) const
> {
> if (x < r.x) return true;
> if (r.x < x) return false;
> if (y < r.y) return true;
> if (r.y < y) return false;
> return z < r.z;
> }
> };
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11330af2a4592204ee387db0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Fair enough :)</div><div class=3D"gmail_extra"><br clear=
=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"h=
ttps://bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com/Bill=
yONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 11:01 AM, Nevin =
Liber <span dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" targe=
t=3D"_blank">nevin@eviloverlord.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On 23 December 2013 12:53, Billy O'N=
eal <span dir=3D"ltr"><<a href=3D"mailto:billy.oneal@gmail.com" target=
=3D"_blank">billy.oneal@gmail.com</a>></span> wrote:<br></div><div class=
=3D"gmail_extra">
<div class=3D"gmail_quote"><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">You can come up with cases that cause iss=
ues, yes, but not for the vast majority of types. operator<, in contrast=
, is order-dependent in *all* cases.</div>
</blockquote><div><br></div></div><div>If you don't like the default or=
der, implement your own! =A0You are no worse off than you are now by having=
a proposal like this one baked into the language.</div><div><br></div><div=
>
However, operator< should be implemented only in terms of operator< o=
f the members, as in:</div>
<div><br></div><div>struct W {</div><div>=A0 =A0 X x;</div><div>=A0 =A0 Y y=
;</div><div>=A0 =A0 Z z;</div><div><br></div><div>=A0 =A0 bool operator<=
(W const& r) const</div><div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 if (x =
< r.x) return true;</div>
<div>=A0 =A0 =A0 =A0 if (r.x < x) return false;</div><div>=A0 =A0 =A0 =
=A0 if (y < r.y) return true;</div><div>=A0 =A0 =A0 =A0 if (r.y < y) =
return false;</div><div>=A0 =A0 =A0 =A0 return z < r.z;</div><div>=A0 =
=A0 }</div><div>};=A0</div></div><span class=3D"HOEnZb"><font color=3D"#888=
888">-- <br>
=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 <a href=3D"=
tel:%28847%29%20691-1404" target=3D"_blank" value=3D"+18476911404">(847) 69=
1-1404</a>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11330af2a4592204ee387db0--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 23 Dec 2013 18:33:59 -0200
Raw View
--nextPart3776175.h9kQOid7Q2
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
On segunda-feira, 23 de dezembro de 2013 10:51:51, Oleg Smolsky wrote:
> What about cases where there is an inter-dependency in the fields'
> constructors? Or when the fields have non-obvious side-effects, such as
> registering themselves with an external entity?
That's not a valid use-case because you HAVE to initialise types in the order
they were declared. You can't have a type that violates that rule.
That can be violated during copy, which is why you have the opportunity to
implement your own copy- and move-assignment operators, instead of the
default.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--nextPart3776175.h9kQOid7Q2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBSuJ43M/XwBW70U1gRAt4PAJ9FQXs3vZxwi2uZfbHQ7Y/YajFjMQCgx8cI
fn+P5Fqdilo+tDnkhUcHAPg=
=8E7U
-----END PGP SIGNATURE-----
--nextPart3776175.h9kQOid7Q2--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 26 Dec 2013 11:46:16 -0800 (PST)
Raw View
------=_Part_3652_5949142.1388087176258
Content-Type: text/plain; charset=ISO-8859-1
On Friday, December 20, 2013 9:14:04 PM UTC+1, oleg.s...@gmail.com wrote:
>
> Hi all, it seems that it would be straightforward for the C++ compiler to
> emit a default version of operator==() and its inverse given that a
> composite type consists of "regular" members.
>
Would the inverse be defined as member-wise != or as !operator== ?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3652_5949142.1388087176258
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 20, 2013 9:14:04 PM UTC+1, oleg.s...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">Hi all, it seems that it would be straightforward for the C++ compiler to=
emit a default version of operator=3D=3D() and its inverse given that a co=
mposite type consists of "regular" members.<br></div></blockquote><div><br>=
</div><div>Would the inverse be defined as member-wise !=3D or as !operator=
=3D=3D ? </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3652_5949142.1388087176258--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Thu, 26 Dec 2013 11:47:31 -0800
Raw View
This is a multi-part message in MIME format.
--------------070001000407010507030208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2013-12-26 11:46, Olaf van der Spek wrote:
> On Friday, December 20, 2013 9:14:04 PM UTC+1, oleg.s...@gmail.com wrote:
>
> Hi all, it seems that it would be straightforward for the C++
> compiler to emit a default version of operator==() and its inverse
> given that a composite type consists of "regular" members.
>
>
> Would the inverse be defined as member-wise != or as !operator== ?
It must be the latter as we all value our sanity :)
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------070001000407010507030208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2013-12-26 11:46, Olaf van der Spek
wrote:<br>
</div>
<blockquote
cite=3D"mid:c3e28fdc-9d5d-4bcb-8551-c4d77184d5ad@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Friday, December 20, 2013 9:14:04 PM UTC+1,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:oleg.s...@gmai=
l.com">oleg.s...@gmail.com</a> wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir=3D"ltr">Hi all, it seems that it would be
straightforward for the C++ compiler to emit a default
version of operator=3D=3D() and its inverse given that a
composite type consists of "regular" members.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Would the inverse be defined as member-wise !=3D or as
!operator=3D=3D ?=A0</div>
</div>
</blockquote>
It must be the latter as we all value our sanity :)<br>
<br>
Oleg.<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------070001000407010507030208--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 26 Dec 2013 14:01:01 -0600
Raw View
--089e0141a0ae3245fb04ee757234
Content-Type: text/plain; charset=ISO-8859-1
On 26 December 2013 13:47, Oleg Smolsky <oleg@smolsky.net> wrote:
> On 2013-12-26 11:46, Olaf van der Spek wrote:
>
> On Friday, December 20, 2013 9:14:04 PM UTC+1, oleg.s...@gmail.com wrote:
>>
>> Hi all, it seems that it would be straightforward for the C++ compiler to
>> emit a default version of operator==() and its inverse given that a
>> composite type consists of "regular" members.
>>
>
> Would the inverse be defined as member-wise != or as !operator== ?
>
> It must be the latter as we all value our sanity :)
>
Why?
Don't get me wrong; as a class designer, I agree it is insane to have an
operator!= that is not equivalent to !operator==.
As a language feature, I would find it far easier to explain that the
generated operator!= calls the member wise operator!=.
If the discussion for relation operators for optional is anything to go by,
you'll have to spend many committee meetings debating this very point in
order to push the proposal through, no matter which choice you pick. :-(
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0141a0ae3245fb04ee757234
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 26 December 2013 13:47, Oleg Smolsky <span dir=3D"ltr">=
<<a href=3D"mailto:oleg@smolsky.net" target=3D"_blank">oleg@smolsky.net<=
/a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><div class=3D"im">
<div>On 2013-12-26 11:46, Olaf van der Spek
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Friday, December 20, 2013 9:14:04 PM UTC+1,
<a href=3D"mailto:oleg.s...@gmail.com" target=3D"_blank">oleg.s...@=
gmail.com</a> wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hi all, it seems that it would be
straightforward for the C++ compiler to emit a default
version of operator=3D=3D() and its inverse given that a
composite type consists of "regular" members.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Would the inverse be defined as member-wise !=3D or as
!operator=3D=3D ?=A0</div>
</div>
</blockquote></div>
It must be the latter as we all value our sanity :)</div></blockquote><=
div><br></div><div>Why?</div><div><br></div><div>Don't get me wrong; as=
a class designer, I agree it is insane to have an operator!=3D that is not=
equivalent to !operator=3D=3D.</div>
<div><br></div><div>As a language feature, I would find it far easier to ex=
plain that the generated operator!=3D calls the member wise operator!=3D.</=
div><div><br></div><div>If the discussion for relation operators for option=
al is anything to go by, you'll have to spend many committee meetings d=
ebating this very point in order to push the proposal through, no matter wh=
ich choice you pick. :-(</div>
</div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0141a0ae3245fb04ee757234--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Thu, 26 Dec 2013 12:20:48 -0800
Raw View
------R8I393IWU3C2P58PHFR5H78Z5HI3RW
Content-Type: text/plain; charset=ISO-8859-1
Well, my answer is twofold: the first paragraph of your reply and because Stepanov said so.
My proposed wording states "boolean inverse" and the code is easy to emit. Finally, users can implement whatever they see fit manually.
Oleg.
Nevin Liber <nevin@eviloverlord.com> wrote:
>On 26 December 2013 13:47, Oleg Smolsky <oleg@smolsky.net> wrote:
>
>> On 2013-12-26 11:46, Olaf van der Spek wrote:
>>
>> On Friday, December 20, 2013 9:14:04 PM UTC+1, oleg.s...@gmail.com
>wrote:
>>>
>>> Hi all, it seems that it would be straightforward for the C++
>compiler to
>>> emit a default version of operator==() and its inverse given that a
>>> composite type consists of "regular" members.
>>>
>>
>> Would the inverse be defined as member-wise != or as !operator== ?
>>
>> It must be the latter as we all value our sanity :)
>>
>
>Why?
>
>Don't get me wrong; as a class designer, I agree it is insane to have
>an
>operator!= that is not equivalent to !operator==.
>
>As a language feature, I would find it far easier to explain that the
>generated operator!= calls the member wise operator!=.
>
>If the discussion for relation operators for optional is anything to go
>by,
>you'll have to spend many committee meetings debating this very point
>in
>order to push the proposal through, no matter which choice you pick.
>:-(
>--
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
>--
>
>---
>You received this message because you are subscribed to a topic in the
>Google Groups "ISO C++ Standard - Future Proposals" group.
>To unsubscribe from this topic, visit
>https://groups.google.com/a/isocpp.org/d/topic/std-proposals/7rpIdimIsOc/unsubscribe.
>To unsubscribe from this group and all its topics, send an email to
>std-proposals+unsubscribe@isocpp.org.
>To post to this group, send email to std-proposals@isocpp.org.
>Visit this group at
>http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------R8I393IWU3C2P58PHFR5H78Z5HI3RW
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>Well, my answer is twofold: the first paragraph of=
your reply and because Stepanov said so.<br>
<br>
My proposed wording states "boolean inverse" and the code is easy=
to emit. Finally, users can implement whatever they see fit manually.<br>
<br>
Oleg.<br><br><div class=3D"gmail_quote">Nevin Liber <nevin@eviloverlord.=
com> wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0p=
t 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir=3D"ltr">On 26 December 2013 13:47, Oleg Smolsky <span dir=3D"ltr">=
<<a href=3D"mailto:oleg@smolsky.net" target=3D"_blank">oleg@smolsky.net<=
/a>></span> wrote:<br /><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><div class=3D"im">
<div>On 2013-12-26 11:46, Olaf van der Spek
wrote:<br />
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Friday, December 20, 2013 9:14:04 PM UTC+1,
<a href=3D"mailto:oleg.s...@gmail.com" target=3D"_blank">oleg.s...@=
gmail.com</a> wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hi all, it seems that it would be
straightforward for the C++ compiler to emit a default
version of operator=3D=3D() and its inverse given that a
composite type consists of "regular" members.<br />
</div>
</blockquote>
<div><br />
</div>
<div>Would the inverse be defined as member-wise !=3D or as
!operator=3D=3D ?=A0</div>
</div>
</blockquote></div>
It must be the latter as we all value our sanity :)</div></blockquote><=
div><br /></div><div>Why?</div><div><br /></div><div>Don't get me wrong=
; as a class designer, I agree it is insane to have an operator!=3D that is=
not equivalent to !operator=3D=3D.</div>
<div><br /></div><div>As a language feature, I would find it far easier to =
explain that the generated operator!=3D calls the member wise operator!=3D.=
</div><div><br /></div><div>If the discussion for relation operators for op=
tional is anything to go by, you'll have to spend many committee meetin=
gs debating this very point in order to push the proposal through, no matte=
r which choice you pick. :-(</div>
</div>-- <br />=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mail=
to:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404
</div></div>
<p></p>
</blockquote></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------R8I393IWU3C2P58PHFR5H78Z5HI3RW--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Thu, 26 Dec 2013 13:17:17 -0800
Raw View
--089e015376b6fd50cd04ee7682fe
Content-Type: text/plain; charset=ISO-8859-1
No, we shouldn't do that. If you want the inverse, bring in the rel_ops.
Language features should support only operator== (and arguably operator<).
rel_ops already does the "default" implementations of the other operators.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Thu, Dec 26, 2013 at 12:01 PM, Nevin Liber <nevin@eviloverlord.com>wrote:
> On 26 December 2013 13:47, Oleg Smolsky <oleg@smolsky.net> wrote:
>
>> On 2013-12-26 11:46, Olaf van der Spek wrote:
>>
>> On Friday, December 20, 2013 9:14:04 PM UTC+1, oleg.s...@gmail.comwrote:
>>>
>>> Hi all, it seems that it would be straightforward for the C++ compiler
>>> to emit a default version of operator==() and its inverse given that a
>>> composite type consists of "regular" members.
>>>
>>
>> Would the inverse be defined as member-wise != or as !operator== ?
>>
>> It must be the latter as we all value our sanity :)
>>
>
> Why?
>
> Don't get me wrong; as a class designer, I agree it is insane to have an
> operator!= that is not equivalent to !operator==.
>
> As a language feature, I would find it far easier to explain that the
> generated operator!= calls the member wise operator!=.
>
> If the discussion for relation operators for optional is anything to go
> by, you'll have to spend many committee meetings debating this very point
> in order to push the proposal through, no matter which choice you pick. :-(
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e015376b6fd50cd04ee7682fe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, we shouldn't do that. If you want the inverse, bri=
ng in the rel_ops. Language features should support only operator=3D=3D (an=
d arguably operator<). rel_ops already does the "default" impl=
ementations of the other operators.</div>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Dec 26, 2013 at 12:01 PM, Nevin =
Liber <span dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" targe=
t=3D"_blank">nevin@eviloverlord.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On 26 December 2013 13:47, Oleg Smolsky =
<span dir=3D"ltr"><<a href=3D"mailto:oleg@smolsky.net" target=3D"_blank"=
>oleg@smolsky.net</a>></span> wrote:<br></div><div class=3D"gmail_extra"=
><div class=3D"gmail_quote">
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>
<div>On 2013-12-26 11:46, Olaf van der Spek
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Friday, December 20, 2013 9:14:04 PM UTC+1,
<a href=3D"mailto:oleg.s...@gmail.com" target=3D"_blank">oleg.s...@=
gmail.com</a> wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hi all, it seems that it would be
straightforward for the C++ compiler to emit a default
version of operator=3D=3D() and its inverse given that a
composite type consists of "regular" members.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Would the inverse be defined as member-wise !=3D or as
!operator=3D=3D ?=A0</div>
</div>
</blockquote></div>
It must be the latter as we all value our sanity :)</div></blockquote><=
div><br></div></div><div>Why?</div><div><br></div><div>Don't get me wro=
ng; as a class designer, I agree it is insane to have an operator!=3D that =
is not equivalent to !operator=3D=3D.</div>
<div><br></div><div>As a language feature, I would find it far easier to ex=
plain that the generated operator!=3D calls the member wise operator!=3D.</=
div><div><br></div><div>If the discussion for relation operators for option=
al is anything to go by, you'll have to spend many committee meetings d=
ebating this very point in order to push the proposal through, no matter wh=
ich choice you pick. :-(</div>
</div><div class=3D"im">-- <br>=A0Nevin ":-)" Liber=A0 <mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>>=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911=
404" target=3D"_blank">(847) 691-1404</a>
</div></div></div>
<p></p>
-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e015376b6fd50cd04ee7682fe--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 27 Dec 2013 10:54:00 +0800
Raw View
On 12/27/13 5:17 AM, Billy O'Neal wrote:
> No, we shouldn't do that. If you want the inverse, bring in the rel_ops.
> Language features should support only operator== (and arguably operator<).
> rel_ops already does the "default" implementations of the other operators.
As far as I know, the best way to use rel_ops to provide a library
interface is with using declarations in the namespace enclosing the
target class. This imposes rel_ops on all the classes associated with
the namespace, and the rel_ops declarations potentially conflict with
class-specific template friend operator implementations.
I guess the lesson is that a cluster of similarly comparable, data-like
classes should be enclosed in a separate namespace. For what it's worth
though, my impression is that rel_ops needs to be applied very carefully.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Sat, 28 Dec 2013 12:05:12 +0100
Raw View
On 12/26/2013 09:01 PM, Nevin Liber wrote:
> As a language feature, I would find it far easier to explain that the
> generated operator!= calls the member wise operator!=.
I would expect that De Morgan's laws apply to these operators.
So if operator== is a conjuction of member-wise operator==
lhs.m1 == rhs.m1 && lhs.m2 == rhs.m2 && ...
then operator!= would be
!(lhs.m1 == rhs.m1 && lhs.m2 == rhs.m2 && ...)
which is the same as
lhs.m1 != rhs.m1 || lhs.m1 != rhs.m2 || ...
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 28 Dec 2013 12:13:31 +0100
Raw View
On Sat, Dec 28, 2013 at 12:05 PM, Bjorn Reese <breese@mail1.stofanet.dk> wrote:
> On 12/26/2013 09:01 PM, Nevin Liber wrote:
>
>> As a language feature, I would find it far easier to explain that the
>> generated operator!= calls the member wise operator!=.
>
>
> I would expect that De Morgan's laws apply to these operators.
>
> So if operator== is a conjuction of member-wise operator==
>
> lhs.m1 == rhs.m1 && lhs.m2 == rhs.m2 && ...
>
> then operator!= would be
>
> !(lhs.m1 == rhs.m1 && lhs.m2 == rhs.m2 && ...)
>
> which is the same as
>
> lhs.m1 != rhs.m1 || lhs.m1 != rhs.m2 || ...
C++ does not require != to be !(==)
If it did, it could synthesize != from == but it doesn't.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Sat, 28 Dec 2013 12:53:23 +0100
Raw View
On 12/28/2013 12:13 PM, Olaf van der Spek wrote:
> On Sat, Dec 28, 2013 at 12:05 PM, Bjorn Reese <breese@mail1.stofanet.dk> wrote:
>> On 12/26/2013 09:01 PM, Nevin Liber wrote:
>>
>>> As a language feature, I would find it far easier to explain that the
>>> generated operator!= calls the member wise operator!=.
>>
>>
>> I would expect that De Morgan's laws apply to these operators.
>>
>> So if operator== is a conjuction of member-wise operator==
>>
>> lhs.m1 == rhs.m1 && lhs.m2 == rhs.m2 && ...
>>
>> then operator!= would be
>>
>> !(lhs.m1 == rhs.m1 && lhs.m2 == rhs.m2 && ...)
>>
>> which is the same as
>>
>> lhs.m1 != rhs.m1 || lhs.m1 != rhs.m2 || ...
>
> C++ does not require != to be !(==)
> If it did, it could synthesize != from == but it doesn't.
I understand that. I was suggesting a viable rule to synthesize an
autogenerated default operator!= from operator==.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Sat, 28 Dec 2013 16:34:37 +0100
Raw View
--089e011607a4cf6ed004ee99f2cc
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Dec 28, 2013 at 12:13 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:
> C++ does not require != to be !(==)
> If it did, it could synthesize != from == but it doesn't.
>
My understanding is that the proposal provide a way to automatically
implement != as being !(==) with a very short syntax which scales
automatically with member changes.
Not to make the language add a requirement.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e011607a4cf6ed004ee99f2cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sat, Dec 28, 2013 at 12:13 PM, Olaf van der Spek <span dir=3D"ltr"><<=
a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.c=
om</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div id=3D":2oz" style=3D"overflow:hidden">C=
++ does not require !=3D to be !(=3D=3D)<br>
If it did, it could synthesize !=3D from =3D=3D but it doesn't.</div></=
blockquote></div><br>My understanding is that the proposal provide a way to=
automatically implement !=3D as being !(=3D=3D) with a very short syntax w=
hich scales automatically with member changes.</div>
<div class=3D"gmail_extra">Not to make the language add a requirement.</div=
><div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e011607a4cf6ed004ee99f2cc--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Sat, 28 Dec 2013 07:39:00 -0800
Raw View
This is a multi-part message in MIME format.
--------------000901050303080101000100
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 2013-12-28 07:34, Klaim - Jo=C4=97l Lamotte wrote:
>
> On Sat, Dec 28, 2013 at 12:13 PM, Olaf van der Spek=20
> <olafvdspek@gmail.com <mailto:olafvdspek@gmail.com>> wrote:
>
> C++ does not require !=3D to be !(=3D=3D)
> If it did, it could synthesize !=3D from =3D=3D but it doesn't.
>
>
> My understanding is that the proposal provide a way to automatically=20
> implement !=3D as being !(=3D=3D) with a very short syntax which scales=
=20
> automatically with member changes.
> Not to make the language add a requirement.
>
That's right. The programmers can opt-in for this shorthand (as I=20
believe it is useful and common), or implement their own.
Oleg.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------000901050303080101000100
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2013-12-28 07:34, Klaim - Joël
Lamotte wrote:<br>
</div>
<blockquote
cite="mid:CAOU91OMNokeiJvXmOSt2ZmnR6tQjgHQR6aCwuXaP_Pt-_gWONg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Dec 28, 2013 at 12:13 PM,
Olaf van der Spek <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:olafvdspek@gmail.com" target="_blank">olafvdspek@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2oz" style="overflow:hidden">C++ does not
require != to be !(==)<br>
If it did, it could synthesize != from == but it
doesn't.</div>
</blockquote>
</div>
<br>
My understanding is that the proposal provide a way to
automatically implement != as being !(==) with a very short
syntax which scales automatically with member changes.</div>
<div class="gmail_extra">Not to make the language add a
requirement.</div>
<br>
</div>
</blockquote>
That's right. The programmers can opt-in for this shorthand (as I
believe it is useful and common), or implement their own.<br>
<br>
Oleg.<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------000901050303080101000100--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 30 Dec 2013 09:40:12 -0500
Raw View
--001a11c3b4acda2ccc04eec16b84
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
This is probably side tracking the discussion, but just as a reminder, in
C++11 and above you should probably avoid rolling operator< manually as you
did, and rather depend on library features and in particular std::tie:
bool operator<(const Foo& lhs, const Foo& rhs) {
return std::tie(lhs.m1, lhs.m2, lhs.m3) < std::tie(rhs.m1, rhs.m2,
rhs.m3);
}
Whether this can/should be automatically generated... I don't think it
should. While equality is clear, at least in most cases, two objects are
the same if _all_ of the members in both objects are pairwise equal; in the
case of 'operator<' the order in which members are compared affects the
result. I am not confident on having a compiler decide for me, and the
order in which members are declared (same as construction) is a bit
arbitrary in that the order of the members will affect the layout and
potentially the size of the object. Binding the behavior to the layout
seems a bit arbitrary, and the implementation of operator< in terms of
std::tie is not a huge burden on the user.
On Sun, Dec 22, 2013 at 12:13 PM, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote=
:
> I too thought about this a while ago, and not only for operator=3D=3D, bu=
t
> also for operator<, <=3D, >, >=3D. I used to work with a codebase that ha=
d
> extended amount of std::maps with compound keys. For each key, we had to
> write both operator=3D=3D and operator< (as std::map needs that), with th=
e
> following code:
> struct Foo {
> Member1 m1; Member2 m2; Member3 m3;
> };
> bool operator=3D=3D(const Foo& l, const Foo& r) {
> return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=3D r.m3;
> }
> bool operator<(const Foo& l, const Foo& r) {
> bool result=3Dfalse;
> result =3D result || l.m1 < r.m1;
> result =3D result || l.m1 =3D=3D r.m1 && l.m2 < l.m2;
> result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2 && l.m3 < =
l.m3;
> return result;
> }
>
> (I hope noone is surprised on the code). Now, operator=3D=3D is not so ba=
d,
> but operator< is horrible if you have 5+ members. We had a variadic macro
> to get less mistakes on implementing the operators, but it is very hard t=
o
> make it readable, and still requires typing the member names twice.
>
> It would be a incomparably lot cleaner if instead of the above, we could
> just write
> struct Foo {
> Member1 m1; Member2 m2; Member3 m3;
> };
> bool operator=3D=3D(const Foo& l, const Foo& r) =3D default;
> bool operator< (const Foo& l, const Foo& r) =3D default;
>
> Or alternatively, as a member function:
> struct Foo {
> Member1 m1; Member2 m2; Member3 m3;
> bool operator=3D=3D(const Foo& r) =3D default;
> bool operator< (const Foo& r) =3D default;
> };
>
> I guess the non-member would need some reflection-like feature (I don't
> even think the benefit of non-member comparators is that great anyway), b=
ut
> the compiler has every information to generate the second.
>
> I already see the question, in what order should operator< do the
> comparison? I see two options:
> a, same way as the constructors work.
> b, implementation defined, allowing for any possible optimizations.
> I actually don't care what order it is doing that, if I do, I can still
> implement the function normally.
>
> None of these should be implicit, explicit "=3Ddefault" should be there, =
to
> not break any current code. I don't think tweaking lookup rules for this =
is
> a viable alternative.
>
> I would be more than happy to help working on such a proposal.
>
> 2013. december 21., szombat 2:33:14 UTC+1 id=F5pontban Billy O'Neal a
> k=F6vetkez=F5t =EDrta:
>
>> What would we expect to happen if one of the members is not comparable?
>> Ill formed?
>>
>
> That's exactly the same problem as a =3Ddefault default/copy/move
> constructor/assignment op if one of the members don't have one. Although =
I
> can't remember how this works for the current =3Ddefault functions, I'd s=
ay
> in that case it should be just deleted to allow proper usage in class
> templates with template-param members.
>
> Regards, Robert
>
> PS: Drifting away from comparisons, it can be also possible to generator
> operator?=3D from operator? or vica versa. A default operator+ meaning
> memberwise op+ is less useful in my opinion than having op+ generated fro=
m
> op+=3D (what should be consistent) and op*=3D from op*. But this is a mat=
ter of
> another thread.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c3b4acda2ccc04eec16b84
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is probably side tracking the discussion, but just as=
a reminder, in C++11 and above you should probably avoid rolling operator&=
lt; manually as you did, and rather depend on library features and in parti=
cular std::tie:<br>
<br>bool operator<(const Foo& lhs, const Foo& rhs) {<br>=A0 =A0r=
eturn std::tie(lhs.m1, lhs.m2, lhs.m3) < std::tie(rhs.m1, rhs.m2, rhs.m3=
);<br>}<br><br>Whether this can/should be automatically generated... I don&=
#39;t think it should. While equality is clear, at least in most cases, two=
objects are the same if _all_ of the members in both objects are pairwise =
equal; in the case of 'operator<' the order in which members are=
compared affects the result. I am not confident on having a compiler decid=
e for me, and the order in which members are declared (same as construction=
) is a bit arbitrary in that the order of the members will affect the layou=
t and potentially the size of the object. Binding the behavior to the layou=
t seems a bit arbitrary, and the implementation of operator< in terms of=
std::tie is not a huge burden on the user.<div>
<br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Sun, Dec 22, 2013 at 12:13 PM, R=F3bert D=E1vid <span dir=3D"ltr"><=
;<a href=3D"mailto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@gmail.com</a>=
></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I too thought about this a =
while ago, and not only for operator=3D=3D, but=20
also for operator<, <=3D, >, >=3D. I used to work with a=20
codebase that had extended amount of std::maps with compound keys. For=20
each key, we had to write both operator=3D=3D and operator< (as std::map=
=20
needs that), with the following code:<br><div style=3D"background-color:rgb=
(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width=
:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">struct</sp=
an><span style> </span><span style=3D"color:#606">Foo</span><span style> </=
span><span style=3D"color:#660">{</span><span style><br>
=A0 </span><span style=3D"color:#606">Member1</span><span style> m1</span><=
span style=3D"color:#660">;</span><span style> </span><span style=3D"color:=
#606">Member2</span><span style> m2</span><span style=3D"color:#660">;</spa=
n><span style> </span><span style=3D"color:#606">Member3</span><span style>=
m3</span><span style=3D"color:#660">;</span><span style><br>
</span><span style=3D"color:#660">};</span><span style><br></span><code><sp=
an style=3D"color:#008">bool</span><span style> </span><span style=3D"color=
:#008">operator</span><span style=3D"color:#660">=3D=3D(</span><span style=
=3D"color:#008">const</span><span style> </span><span style=3D"color:#606">=
Foo</span><span style=3D"color:#660">&</span><span style> l, const Foo&=
amp; r</span><span style=3D"color:#660">)</span><span style> {<br>
=A0 return l.m1 =3D=3D r.m1 && l.m2 =3D=3D r.m2 && l.m3 =3D=
=3D r.m3;<br>}<br>bool operator<(const Foo& l, const Foo& r) {<b=
r>=A0=A0=A0 bool result=3Dfalse;<br>=A0=A0=A0 result =3D result || l.m1 <=
;=A0 r.m1;<br>=A0=A0=A0 result =3D result || l.m1 =3D=3D r.m1 && l.=
m2 <=A0 l.m2;<br>
=A0=A0=A0 result =3D result || l.m1 =3D=3D r.m1 && l.m2 =3D=3D l.m2=
&& l.m3 <=A0 l.m3;<br>=A0=A0=A0 return result;<br>}<br></span><=
span style=3D"color:#660"></span></code></div></code></div><br>(I
hope noone is surprised on the code). Now, operator=3D=3D is not so bad,=
=20
but operator< is horrible if you have 5+ members. We had a variadic=20
macro to get less mistakes on implementing the operators, but it is very
hard to make it readable, and still requires typing the member names=20
twice.<br><br>It would be a incomparably lot cleaner if instead of the abov=
e, we could just write<br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word">
<code><div><code><span style=3D"color:#008">struct</span><span style> </spa=
n><span style=3D"color:#606">Foo</span><span style> </span><span style=3D"c=
olor:#660">{</span><span style><br>=A0 </span><span style=3D"color:#606">Me=
mber1</span><span style> m1</span><span style=3D"color:#660">;</span><span =
style> </span><span style=3D"color:#606">Member2</span><span style> m2</spa=
n><span style=3D"color:#660">;</span><span style> </span><span style=3D"col=
or:#606">Member3</span><span style> m3</span><span style=3D"color:#660">;</=
span><span style><br>
</span><span style=3D"color:#660">};</span><span style></span></code><br><c=
ode><code><span style=3D"color:#008">bool</span><span style> </span><span s=
tyle=3D"color:#008">operator</span><span style=3D"color:#660">=3D=3D(</span=
><span style=3D"color:#008">const</span><span style> </span><span style=3D"=
color:#606">Foo</span><span style=3D"color:#660">&</span><span style> l=
, const Foo& r</span><span style=3D"color:#660">)</span><span style> =
=3D default;</span></code></code><span style=3D"color:#660"></span><br>
<code><code><code><span style=3D"color:#008">bool</span><span style> </span=
><span style=3D"color:#008">operator</span><span style=3D"color:#660">< =
(</span><span style=3D"color:#008">const</span><span style> </span><span st=
yle=3D"color:#606">Foo</span><span style=3D"color:#660">&</span><span s=
tyle> l, const Foo& r</span><span style=3D"color:#660">)</span><span st=
yle> =3D default;</span></code></code><span style=3D"color:#660"></span></c=
ode></div>
</code></div><br>Or alternatively, as a member function:<br><code><span sty=
le=3D"color:#660"><div style=3D"background-color:rgb(250,250,250);border-co=
lor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wo=
rd">
<code><div><code><code><span style=3D"color:#008">struct</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Foo</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br>
=A0 </span><span style=3D"color:#606">Member1</span><span style=3D"color:#0=
00"> m1</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
> </span><span style=3D"color:#606">Member2</span><span style=3D"color:#000=
"> m2</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =
</span><span style=3D"color:#606">Member3</span><span style=3D"color:#000">=
m3</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br=
>
</span></code></code>=A0 <code><code><span style=3D"color:#000"><code><span=
style=3D"color:#660"><code><code><code><code><span style=3D"color:#008">bo=
ol</span><span style=3D"color:#000"> </span><span style=3D"color:#008">oper=
ator</span><span style=3D"color:#660">=3D=3D(</span><span style=3D"color:#0=
00">const Foo& r</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> =3D default;</span></code></code><span style=3D"color:#660=
"></span><br>
<code><code><code><span style=3D"color:#008">=A0 bool</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">operator</span><span style=
=3D"color:#660">< (</span><span style=3D"color:#000">const Foo& r</s=
pan><span style=3D"color:#660">)</span><span style=3D"color:#000"> =3D defa=
ult;</span></code></code></code></code></code></span></code></span><span st=
yle=3D"color:#660"><br>
};</span><span style=3D"color:#000"></span></code><br><code><code><code><sp=
an style=3D"color:#000"></span></code></code></code></code><span style=3D"c=
olor:#660"></span></div></code></div><br></span></code>I guess the non-memb=
er would need some reflection-like feature (I don't even think the bene=
fit of non-member comparators is that great anyway), but the compiler has e=
very information to generate the second.<br>
<br>I already see the question, in what order should operator< do the co=
mparison? I see two options:<br>a, same way as the constructors work.<br>b,=
implementation defined, allowing for any possible optimizations.<br>I actu=
ally don't care what order it is doing that, if I do, I can still imple=
ment the function normally.<br>
<br>None
of these should be implicit, explicit "=3Ddefault" should be the=
re, to=20
not break any current code. I don't think tweaking lookup rules for thi=
s
is a viable alternative.<br><code><span style=3D"color:#660"><code><code><=
code><code><code><span style=3D"color:#000"><br></span></code></code></code=
></code></code></span></code>I would be more than happy to help working on =
such a proposal.<br>
<br>2013. december 21., szombat 2:33:14 UTC+1 id=F5pontban Billy O'Neal=
a k=F6vetkez=F5t =EDrta:<div class=3D"im"><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">
<div>What would we expect to happen if one of the members is not comparable=
? Ill formed?</div></div></blockquote></div><div><br>That's
exactly the same problem as a =3Ddefault default/copy/move=20
constructor/assignment op if one of the members don't have one. Althoug=
h
I can't remember how this works for the current =3Ddefault functions, =
I'd
say in that case it should be just deleted to allow proper usage in class=
=20
templates with template-param members.<br><br>Regards, Robert<br><br>PS: Dr=
ifting away from comparisons, it can be also possible to generator operator=
?=3D from operator? or vica versa. A default operator+ meaning memberwise o=
p+ is less useful in my opinion than having op+ generated from op+=3D (what=
should be consistent) and op*=3D from op*. But this is a matter of another=
thread.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3b4acda2ccc04eec16b84--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 31 Dec 2013 00:18:36 +0800
Raw View
On 12/30/13 10:40 PM, David Rodr=EDguez Ibeas wrote:
> Whether this can/should be automatically generated... I don't think it
> should.
Just another thought: if corresponding pointer members of two objects=20
get an ordered comparison, the result is unspecified unless they point=20
to the same array. Not so user-friendly.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.