Topic: Any plans to remove need for boilerplate code
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sun, 11 Nov 2012 01:31:00 -0600
Raw View
--00151750e552483fed04ce332d50
Content-Type: text/plain; charset=ISO-8859-1
On 11 November 2012 00:25, Nicol Bolas <jmckesson@gmail.com> wrote:
> Considering how relatively infrequently one wants to write a type that has
> comparisons (there are types you want to compare, it's just not most of the
> types you write),
There are lots of times people would write types that have comparisons, but
the burden is so high that they fall back on using types that already have
comparison implemented (fundamental types, std::string, etc.), use
inheritance instead of composition, etc. I'd like to see that burden
significantly reduced.
it just seems to me that it's better to let the reflection study group do
> their job and provide it as a library feature. I just don't feel it is
> important enough to rise to the level where we want compilers to write that
> code.
>
I have no idea what level it will rise to. Reflection needs to be a
language feature, but what form it will take, how much it will cover if we
want to ship it in C++17, etc., haven't even begun to be debated (other
than . I think it is way too early to state whether or not "=default" will
be part of it.
> Also, using the "= default" syntax makes it slightly confusing, compared
> to the standard meaning. "default" doesn't just mean that the compiler
> generates the function. It's only defined for functions that the compiler
> would have automatically generated code for; the reason you need it is to
> override times when the C++ rules would forbid generating one. Now you're
> using it in a circumstance where the compiler would *never* have
> automatically generated code for it. Something like "= generate" would show
> that it's different from "default", since there is no actual default
> version.
That all depends on how you look at it. With the exception of destructors,
"=default" can be defined to mean generate a base class(es) + non-static
member-wise default/copy/move construction/assignment. That definition
isn't hard to generalize.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--00151750e552483fed04ce332d50
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 11 November 2012 00:25, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mai=
lto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></spa=
n> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Considering how relatively infrequently one wants to write a type that has =
comparisons (there are types you want to compare, it's just not most of=
the types you write),</blockquote><div><br></div><div>There are lots of ti=
mes people would write types that have comparisons, but the burden is so hi=
gh that they fall back on using types that already have comparison implemen=
ted (fundamental types, std::string, etc.), use inheritance instead of comp=
osition, etc. =A0I'd like to see that burden significantly reduced.</di=
v>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"> it just seems to me that it&=
#39;s better to let the reflection study group do their job and provide it =
as a library feature. I just don't feel it is important enough to rise =
to the level where we want compilers to write that code.<br>
</blockquote><div><br></div><div>I have no idea what level it will rise to.=
=A0Reflection needs to be a language feature, but what form it will take, =
how much it will cover if we want to ship it in C++17, etc., haven't ev=
en begun to be debated (other than . =A0I think it is way too early to stat=
e whether or not "=3Ddefault" will be part of it.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Also, using the "=3D defa=
ult" syntax makes it slightly confusing, compared to the standard mean=
ing. "default" doesn't just mean that the compiler generates =
the function. It's only defined for functions that the compiler would h=
ave automatically generated code for; the reason you need it is to override=
times when the C++ rules would forbid generating one. Now you're using=
it in a circumstance where the compiler would <i>never</i> have automatica=
lly generated code for it. Something like "=3D generate" would sh=
ow that it's different from "default", since there is no actu=
al default version.</blockquote>
<div><br></div><div>That all depends on how you look at it. =A0With the exc=
eption of destructors, "=3Ddefault" can be defined to mean genera=
te a base class(es) + non-static member-wise default/copy/move construction=
/assignment. =A0That definition isn't hard to generalize.</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<br>
<p></p>
-- <br />
<br />
<br />
<br />
--00151750e552483fed04ce332d50--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 11 Nov 2012 00:04:25 -0800 (PST)
Raw View
------=_Part_373_18503713.1352621065212
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, November 10, 2012 11:31:47 PM UTC-8, Nevin ":-)" Liber wrote:
>
> it just seems to me that it's better to let the reflection study group do
>> their job and provide it as a library feature. I just don't feel it is
>> important enough to rise to the level where we want compilers to write that
>> code.
>>
>
> I have no idea what level it will rise to. Reflection needs to be a
> language feature, but what form it will take, how much it will cover if we
> want to ship it in C++17, etc., haven't even begun to be debated (other
> than . I think it is way too early to state whether or not "=default" will
> be part of it.
>
It's not going to be part of reflection (as a language feature). That's the
point: with reflection, we won't *need* it to be a language feature
anymore. It can just be a function call.
> Also, using the "= default" syntax makes it slightly confusing, compared
>> to the standard meaning. "default" doesn't just mean that the compiler
>> generates the function. It's only defined for functions that the compiler
>> would have automatically generated code for; the reason you need it is to
>> override times when the C++ rules would forbid generating one. Now you're
>> using it in a circumstance where the compiler would *never* have
>> automatically generated code for it. Something like "= generate" would show
>> that it's different from "default", since there is no actual default
>> version.
>
>
> That all depends on how you look at it. With the exception of
> destructors, "=default" can be defined to mean generate a base class(es) +
> non-static member-wise default/copy/move construction/assignment. That
> definition isn't hard to generalize.
>
But that's *not* what it means. If that were what it meant, then you could
do it yourself. These are not equivalent:
struct A
{
int a;
A(const A&_a) : a(_a.a) {}
};
struct B
{
int b;
B(const B&) = default;
};
`B` is trivially copyable (assuming that it also gets a trivial copy
operator. I forget the rule on whether this syntax requires explicitly
defaulting it too). `A` is not.
It isn't about generating the code. It's about saying, "Do what you would
normally do." IE: the *default*. The default for `operator ==` is nothing.
So how can you generalize it?
--
------=_Part_373_18503713.1352621065212
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, November 10, 2012 11:31:47 PM UTC-8, Nevin ":-)" Liber=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quo=
te"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"> it just seems to me that it'=
s better to let the reflection study group do their job and provide it as a=
library feature. I just don't feel it is important enough to rise to the l=
evel where we want compilers to write that code.<br>
</blockquote><div><br></div><div>I have no idea what level it will rise to.=
Reflection needs to be a language feature, but what form it will tak=
e, how much it will cover if we want to ship it in C++17, etc., haven't eve=
n begun to be debated (other than . I think it is way too early to st=
ate whether or not "=3Ddefault" will be part of it.</div></div></blockquote=
><div><br>It's not going to be part of reflection (as a language feature). =
That's the point: with reflection, we won't <i>need</i> it to be a language=
feature anymore. It can just be a function call.<br> <br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Also, using the "=3D default" syntax makes i=
t slightly confusing, compared to the standard meaning. "default" doesn't j=
ust mean that the compiler generates the function. It's only defined for fu=
nctions that the compiler would have automatically generated code for; the =
reason you need it is to override times when the C++ rules would forbid gen=
erating one. Now you're using it in a circumstance where the compiler would=
<i>never</i> have automatically generated code for it. Something like "=3D=
generate" would show that it's different from "default", since there is no=
actual default version.</blockquote>
<div><br></div><div>That all depends on how you look at it. With the =
exception of destructors, "=3Ddefault" can be defined to mean generate a ba=
se class(es) + non-static member-wise default/copy/move construction/assign=
ment. That definition isn't hard to generalize.</div></div></blockquo=
te><div><br>But that's <i>not</i> what it means. If that were what it meant=
, then you could do it yourself. These are not equivalent:<br><br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> A<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><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> A</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_a</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">_a</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a<=
/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: #660;" class=3D"styled-by-prettify">{}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> B<br></span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> B</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">default</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div=
></code></div><br>`B` is trivially copyable (assuming that it also gets a t=
rivial copy operator. I forget the rule on whether this syntax requires exp=
licitly defaulting it too). `A` is not.<br><br>It isn't about generating th=
e code. It's about saying, "Do what you would normally do." IE: the <i>defa=
ult</i>. The default for `operator =3D=3D` is nothing. So how can you gener=
alize it?<br></div><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_373_18503713.1352621065212--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 11 Nov 2012 08:26:20 -0000
Raw View
--047d7bd7504690b8a304ce33f0e6
Content-Type: text/plain; charset=ISO-8859-1
I come from the Stepanov school of "code is math". I want almost all my
types to be RegularTypes. That includes equality comparable.
As for =default or =generate -
If we use =default as in existing use, and introduce =generate for these
new uses,
Can I also use =generate in the places we currently use =default?
If so, does it change anything (ie change trivially copyable, etc)?
If not, I can just use =generate everywhere?
Then can I spell =generate as "=default" so as to not make a new keyword?
Tony
------------------------------
*From:* "Nicol Bolas" <jmckesson@gmail.com>
*To:* "std-proposals@isocpp.org" <std-proposals@isocpp.org>
*CC:* "nx02columbia@gmail.com" <nx02columbia@gmail.com>, "
hivemaster@hotmail.de" <hivemaster@hotmail.de>
*Sent:* 11 November, 2012 1:25 AM
*Subject:* [std-proposals] Re: Any plans to remove need for boilerplate
code in struct/class comparison operators ?
"= default" syntax wasn't added for that reason. It wasn't added to make
auto-generated copy constructors; it was added because it allowed you to
force the compiler to generate what it would have before. You
*can't*replicate the behavior of "= default". A class that has a
defaulted copy
constructor may be trivially copyable, while a class that has a
user-provided one, even if it does the *exact same thing*, isn't.
It also happens to have nice visual properties and ease of understanding
while it's doing that. But the main purpose was to tell the compiler that,
"I know your rules say you won't auto-generate the copy constructor, but I
want you to do that now anyway".
Considering how relatively infrequently one wants to write a type that has
comparisons (there are types you want to compare, it's just not most of the
types you write), it just seems to me that it's better to let the
reflection study group do their job and provide it as a library feature. I
just don't feel it is important enough to rise to the level where we want
compilers to write that code.
Also, using the "= default" syntax makes it slightly confusing, compared to
the standard meaning. "default" doesn't just mean that the compiler
generates the function. It's only defined for functions that the compiler
would have automatically generated code for; the reason you need it is to
override times when the C++ rules would forbid generating one. Now you're
using it in a circumstance where the compiler would *never* have
automatically generated code for it. Something like "= generate" would show
that it's different from "default", since there is no actual default
version.
On Saturday, November 10, 2012 8:53:31 PM UTC-8, nx02co...@gmail.com wrote:
>
> tbh i prefer "codeless" declerative syntax. For the same reason why Herb
> prefers for_each over for()... it makes clear what code does more quickly
> (in Herbs example you know there is no break, in this case when you have
> seen once operator /*...*/ = default or operator = /*...*/ using in the
> future youll know *what* it does, aka you can quickly learn to move
> "abstraction level" above from *how *it is being done to *what *is being
> done).
> That being said there needs to be a uniform way of doing things and if CTR
> group does 10 things it would be ugly to make exception from their style
> for this one.
> For example IIRC std::to_string is not templated despite the fact that
> std::string is typedef of basic_string. For me that is example of things
> not fitting nicely.
>
> On Sunday, November 11, 2012 6:27:07 AM UTC+2, Nicol Bolas wrote:
>>
>>
>>
>> On Saturday, November 10, 2012 8:13:19 PM UTC-8, nx02co...@gmail.comwrote:
>>>
>>>
>>>
>>> On Sunday, November 11, 2012 5:36:13 AM UTC+2, Xeo wrote:
>>>>
>>>> Just a quick comment on one thing.
>>>>
>>>> On Sunday, November 11, 2012 2:22:10 AM UTC+1, nx02co...@gmail.comwrote:
>>>>>
>>>>> would work only for "C++" code aka wont work on structs that have raw
>>>>> pointer members
>>>>>
>>>> Having raw pointers in C++ is perfectly fine, *as long as they don't
>>>> own anything*.
>>>>
>>> Ill elaborate:
>>> problem is the following, if there is "declarative" syntax for == there
>>> must be one for <, <=...
>>> now pointers have multiple problems when it comes to what is default :
>>> - it is possible that p1<p2, but *p1>*p2
>>> - for == is default comparison on pointers or on the pointed to, aka do
>>> you care if they point to the same instance or if the instances are the same
>>> -if one pointer is null how do you do < , >=... comparisons
>>> one could argue that you can fix first 2 problems by having
>>> specializations for smart pointers, but still they dont solve third one.
>>> fact is that empty std::string can be compared to other string... but if
>>> you have option "not set" (nullptr) I dont see way around it
>>>
>>>
>> I don't know. For this kind of thing, I'm trusting the compile-time
>> reflection study group to provide simple ways to solve this problem. So you
>> simply write:
>>
>> bool operator ==(const T& rhs) const { return std::double_reflect_equals<
>> T>(*this, rhs); }
>>
>> Or something to that effect.
>>
> --
--
--047d7bd7504690b8a304ce33f0e6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>I come from the Stepanov school of "code is m=
ath". I want almost all my types to be RegularTypes. That includes equ=
ality comparable.<div><br></div><div>As for =3Ddefault or =3Dgenerate -</di=
v>
<div>If we use =3Ddefault as in existing use, and introduce =3Dgenerate for=
these new uses,</div><div>Can I also use =3Dgenerate in the places we curr=
ently use =3Ddefault?</div><div>If so, does it change anything (ie change t=
rivially copyable, etc)?</div>
<div>If not, I can just use =3Dgenerate everywhere?=A0</div><div>Then can I=
spell =3Dgenerate as "=3Ddefault" so as to not make a new keywor=
d?</div><div><br></div><div><div id=3D"1330154144936-sig-id">Tony</div><div=
id=3D"1330154144936-sig-id">
<br></div><hr><div><strong>From:</strong> "Nicol Bolas" <<a hr=
ef=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>><br><strong>To=
:</strong> "<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@=
isocpp.org</a>" <<a href=3D"mailto:std-proposals@isocpp.org">std-pr=
oposals@isocpp.org</a>><br>
<strong>CC:</strong> "<a href=3D"mailto:nx02columbia@gmail.com">nx02co=
lumbia@gmail.com</a>" <<a href=3D"mailto:nx02columbia@gmail.com">nx=
02columbia@gmail.com</a>>, "<a href=3D"mailto:hivemaster@hotmail.de=
">hivemaster@hotmail.de</a>" <<a href=3D"mailto:hivemaster@hotmail.=
de">hivemaster@hotmail.de</a>><br>
<strong>Sent:</strong> 11 November, 2012 1:25 AM<br><strong>Subject:</stron=
g> [std-proposals] Re: Any plans to remove need for boilerplate code in str=
uct/class comparison operators ?<br></div><br>"=3D default" synta=
x wasn't added for that reason. It wasn't added to make auto-genera=
ted copy constructors; it was added because it allowed you to force the com=
piler to generate what it would have before. You <i>can't</i> replicate=
the behavior of "=3D default". A class that has a defaulted copy=
constructor may be trivially copyable, while a class that has a user-provi=
ded one, even if it does the <i>exact same thing</i>, isn't.<br>
<br>It also happens to have nice visual properties and ease of understandin=
g while it's doing that. But the main purpose was to tell the compiler =
that, "I know your rules say you won't auto-generate the copy cons=
tructor, but I want you to do that now anyway".<br>
<br>Considering how relatively infrequently one wants to write a type that =
has comparisons (there are types you want to compare, it's just not mos=
t of the types you write), it just seems to me that it's better to let =
the reflection study group do their job and provide it as a library feature=
.. I just don't feel it is important enough to rise to the level where w=
e want compilers to write that code.<br>
<br>Also, using the "=3D default" syntax makes it slightly confus=
ing, compared to the standard meaning. "default" doesn't just=
mean that the compiler generates the function. It's only defined for f=
unctions that the compiler would have automatically generated code for; the=
reason you need it is to override times when the C++ rules would forbid ge=
nerating one. Now you're using it in a circumstance where the compiler =
would <i>never</i> have automatically generated code for it. Something like=
"=3D generate" would show that it's different from "def=
ault", since there is no actual default version.<br>
<br>On Saturday, November 10, 2012 8:53:31 PM UTC-8, <a href=3D"mailto:nx02=
co...@gmail.com">nx02co...@gmail.com</a> wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">
tbh i prefer "codeless" declerative syntax. For the same reason w=
hy Herb prefers for_each over for()... it makes clear what code does more q=
uickly (in Herbs example you know there is no break, in this case when you =
have seen once operator /*...*/ =3D default or=A0=A0=A0 operator =3D /*...*=
/ using=A0 in the future youll=A0 know <i>what</i> it does, aka=A0 you can =
quickly learn to move "abstraction level" above from=A0 <i>how </=
i>it is being done to <i>what </i>is being done).<br>
That being said there needs to be a uniform way of doing things and if CTR =
group does 10 things it would be ugly to make exception from their style fo=
r this one. <br>For example IIRC std::to_string is not templated despite th=
e fact that std::string is typedef of basic_string. For me that is example =
of things not fitting nicely. <br>
<br>On Sunday, November 11, 2012 6:27:07 AM UTC+2, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><br><br>On Saturday, November 10, 2012 8:=
13:19 PM UTC-8, <a>nx02co...@gmail.com</a> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br><br>On Sunday, November 11, 2012 5:36:13 AM UTC+2, Xeo wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex">Just a quick comment on one thing.<br><br>On =
Sunday, November 11, 2012 2:22:10 AM UTC+1, <a>nx02co...@gmail.com</a> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
would work only for "C++" code aka wont work on structs that have=
raw pointer members<br></blockquote><div>Having raw pointers in C++ is per=
fectly fine, <i>as long as they don't own anything</i>.<br></div></bloc=
kquote>
<div>Ill elaborate:<br>problem is the following, if there is "declarat=
ive"=A0 syntax for =3D=3D there must be one for <, <=3D...<br>no=
w pointers have multiple problems when it comes to what is default :<br>- i=
t is possible that p1<p2, but *p1>*p2<br>
- for =3D=3D is default comparison on pointers or on the pointed to, aka do=
you care if they point to the same instance or if the instances are the sa=
me<br>-if one pointer is null how do you do < , >=3D... comparisons<b=
r>
one could argue that you can fix first 2 problems by having specializations=
for=A0 smart pointers, but still they dont solve third one. fact is that e=
mpty std::string can be compared to other string... but if you have option =
"not set" (nullptr) I dont see way around it<br>
<br></div></blockquote><div><br>I don't know. For this kind of thing, I=
'm trusting the compile-time reflection study group to provide simple w=
ays to solve this problem. So you simply write:<br><br><div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px;word-wrap:break-word">
<code><div><span style=3D"color:#008">bool</span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">operator</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">=3D=3D(</span><span style=3D"color:#0=
08">const</span><span style=3D"color:#000"> T</span><span style=3D"color:#6=
60">&</span><span style=3D"color:#000"> rhs</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>const</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"> </span><span style=3D"color:#008">retur=
n</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::=
</span><span style=3D"color:#000">double_reflect_equals</span><span style=
=3D"color:#660"><</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">>(*</span><span style=3D"color:#008">this</span><span st=
yle=3D"color:#660">,</span><span style=3D"color:#000"> =A0rhs</span><span s=
tyle=3D"color:#660">);</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">}</span><span style=3D"color:#000"><br>
</span></div></code></div><br>Or something to that effect.<br></div></block=
quote></blockquote>
<p></p>
-- <br>
=A0<br>
=A0<br>
=A0<br>
</div></body></html>
<p></p>
-- <br />
<br />
<br />
<br />
--047d7bd7504690b8a304ce33f0e6--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 11 Nov 2012 00:49:48 -0800 (PST)
Raw View
------=_Part_1564_1523185.1352623788313
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, November 11, 2012 12:26:23 AM UTC-8, Tony V E wrote:
>
> I come from the Stepanov school of "code is math". I want almost all my
> types to be RegularTypes. That includes equality comparable.
>
> As for =default or =generate -
> If we use =default as in existing use, and introduce =generate for these
> new uses,
> Can I also use =generate in the places we currently use =default?
>
No more than you can use default everywhere. They mean different things,
and you wouldn't want to apply them to the same functions. However, if you
did:
> If so, does it change anything (ie change trivially copyable, etc)?
>
Yes. `default` means "do what you would normally do if I hadn't done the
thing that made you not do that". `generate` means "create a function
definition based on some heuristic." If we allow `generate` to be used on
special functions, they would not be explicitly defaulted and therefore not
be trivially copyable.
`generate` generates code. `default` is about doing the default. See the
difference? `generate` does something you could do; `default` does
something you *can't* do.
> If not, I can just use =generate everywhere?
>
No. See above.
> Then can I spell =generate as "=default" so as to not make a new keyword?
>
It's no more a keyword than "final" and "override".
>
> Tony
>
> ------------------------------
> *From:* "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> *To:* "std-pr...@isocpp.org <javascript:>" <std-pr...@isocpp.org<javascript:>
> >
> *CC:* "nx02co...@gmail.com <javascript:>" <nx02co...@gmail.com<javascript:>>,
> "hivem...@hotmail.de <javascript:>" <hivem...@hotmail.de <javascript:>>
> *Sent:* 11 November, 2012 1:25 AM
> *Subject:* [std-proposals] Re: Any plans to remove need for boilerplate
> code in struct/class comparison operators ?
>
> "= default" syntax wasn't added for that reason. It wasn't added to make
> auto-generated copy constructors; it was added because it allowed you to
> force the compiler to generate what it would have before. You *can't*replicate the behavior of "= default". A class that has a defaulted copy
> constructor may be trivially copyable, while a class that has a
> user-provided one, even if it does the *exact same thing*, isn't.
>
> It also happens to have nice visual properties and ease of understanding
> while it's doing that. But the main purpose was to tell the compiler that,
> "I know your rules say you won't auto-generate the copy constructor, but I
> want you to do that now anyway".
>
> Considering how relatively infrequently one wants to write a type that has
> comparisons (there are types you want to compare, it's just not most of the
> types you write), it just seems to me that it's better to let the
> reflection study group do their job and provide it as a library feature. I
> just don't feel it is important enough to rise to the level where we want
> compilers to write that code.
>
> Also, using the "= default" syntax makes it slightly confusing, compared
> to the standard meaning. "default" doesn't just mean that the compiler
> generates the function. It's only defined for functions that the compiler
> would have automatically generated code for; the reason you need it is to
> override times when the C++ rules would forbid generating one. Now you're
> using it in a circumstance where the compiler would *never* have
> automatically generated code for it. Something like "= generate" would show
> that it's different from "default", since there is no actual default
> version.
>
> On Saturday, November 10, 2012 8:53:31 PM UTC-8, nx02co...@gmail.comwrote:
>>
>> tbh i prefer "codeless" declerative syntax. For the same reason why Herb
>> prefers for_each over for()... it makes clear what code does more quickly
>> (in Herbs example you know there is no break, in this case when you have
>> seen once operator /*...*/ = default or operator = /*...*/ using in the
>> future youll know *what* it does, aka you can quickly learn to move
>> "abstraction level" above from *how *it is being done to *what *is
>> being done).
>> That being said there needs to be a uniform way of doing things and if
>> CTR group does 10 things it would be ugly to make exception from their
>> style for this one.
>> For example IIRC std::to_string is not templated despite the fact that
>> std::string is typedef of basic_string. For me that is example of things
>> not fitting nicely.
>>
>> On Sunday, November 11, 2012 6:27:07 AM UTC+2, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Saturday, November 10, 2012 8:13:19 PM UTC-8, nx02co...@gmail.comwrote:
>>>>
>>>>
>>>>
>>>> On Sunday, November 11, 2012 5:36:13 AM UTC+2, Xeo wrote:
>>>>>
>>>>> Just a quick comment on one thing.
>>>>>
>>>>> On Sunday, November 11, 2012 2:22:10 AM UTC+1, nx02co...@gmail.comwrote:
>>>>>>
>>>>>> would work only for "C++" code aka wont work on structs that have raw
>>>>>> pointer members
>>>>>>
>>>>> Having raw pointers in C++ is perfectly fine, *as long as they don't
>>>>> own anything*.
>>>>>
>>>> Ill elaborate:
>>>> problem is the following, if there is "declarative" syntax for ==
>>>> there must be one for <, <=...
>>>> now pointers have multiple problems when it comes to what is default :
>>>> - it is possible that p1<p2, but *p1>*p2
>>>> - for == is default comparison on pointers or on the pointed to, aka do
>>>> you care if they point to the same instance or if the instances are the same
>>>> -if one pointer is null how do you do < , >=... comparisons
>>>> one could argue that you can fix first 2 problems by having
>>>> specializations for smart pointers, but still they dont solve third one.
>>>> fact is that empty std::string can be compared to other string... but if
>>>> you have option "not set" (nullptr) I dont see way around it
>>>>
>>>>
>>> I don't know. For this kind of thing, I'm trusting the compile-time
>>> reflection study group to provide simple ways to solve this problem. So you
>>> simply write:
>>>
>>> bool operator ==(const T& rhs) const { return std::double_reflect_equals
>>> <T>(*this, rhs); }
>>>
>>> Or something to that effect.
>>>
>> --
>
>
>
>
--
------=_Part_1564_1523185.1352623788313
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, November 11, 2012 12:26:23 AM UTC-8, Tony V E wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div>I come from the Stepanov scho=
ol of "code is math". I want almost all my types to be RegularTypes. That i=
ncludes equality comparable.<div><br></div><div>As for =3Ddefault or =3Dgen=
erate -</div>
<div>If we use =3Ddefault as in existing use, and introduce =3Dgenerate for=
these new uses,</div><div>Can I also use =3Dgenerate in the places we curr=
ently use =3Ddefault?</div></div></blockquote><div><br>No more than you can=
use default everywhere. They mean different things, and you wouldn't want =
to apply them to the same functions. However, if you did:<br> </div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div><div>If so, does it change =
anything (ie change trivially copyable, etc)?</div></div></blockquote><div>=
<br>Yes. `default` means "do what you would normally do if I hadn't done th=
e thing that made you not do that". `generate` means "create a function def=
inition based on some heuristic." If we allow `generate` to be used on spec=
ial functions, they would not be explicitly defaulted and therefore not be =
trivially copyable.<br><br>`generate` generates code. `default` is about do=
ing the default. See the difference? `generate` does something you could do=
; `default` does something you <i>can't</i> do.<br> <br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div>
<div>If not, I can just use =3Dgenerate everywhere? </div></div></bloc=
kquote><div><br>No. See above.<br> </div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div><div>Then can I spell =3Dgenerate as "=3Ddefault" so a=
s to not make a new keyword?</div></div></blockquote><div><br>It's no more =
a keyword than "final" and "override".<br> </div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div><div><br></div><div><div>Tony</div><div>
<br></div><hr><div><b>From:</b> "Nicol Bolas" <<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"vBAEz3C8ZoIJ">jmck...@gmail.com</=
a>><br><b>To:</b> "<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"vBAEz3C8ZoIJ">std-pr...@isocpp.org</a>" <<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"vBAEz3C8ZoIJ">std-pr...@i=
socpp.org</a>><br>
<b>CC:</b> "<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"vBAEz3C8ZoIJ">nx02co...@gmail.com</a>" <<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"vBAEz3C8ZoIJ">nx02co...@gmail.com</a=
>>, "<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
vBAEz3C8ZoIJ">hivem...@hotmail.de</a>" <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"vBAEz3C8ZoIJ">hivem...@hotmail.de</a>&=
gt;<br>
<b>Sent:</b> 11 November, 2012 1:25 AM<br><b>Subject:</b> [std-proposals] R=
e: Any plans to remove need for boilerplate code in struct/class comparison=
operators ?<br></div><br>"=3D default" syntax wasn't added for that reason=
.. It wasn't added to make auto-generated copy constructors; it was added be=
cause it allowed you to force the compiler to generate what it would have b=
efore. You <i>can't</i> replicate the behavior of "=3D default". A class th=
at has a defaulted copy constructor may be trivially copyable, while a clas=
s that has a user-provided one, even if it does the <i>exact same thing</i>=
, isn't.<br>
<br>It also happens to have nice visual properties and ease of understandin=
g while it's doing that. But the main purpose was to tell the compiler that=
, "I know your rules say you won't auto-generate the copy constructor, but =
I want you to do that now anyway".<br>
<br>Considering how relatively infrequently one wants to write a type that =
has comparisons (there are types you want to compare, it's just not most of=
the types you write), it just seems to me that it's better to let the refl=
ection study group do their job and provide it as a library feature. I just=
don't feel it is important enough to rise to the level where we want compi=
lers to write that code.<br>
<br>Also, using the "=3D default" syntax makes it slightly confusing, compa=
red to the standard meaning. "default" doesn't just mean that the compiler =
generates the function. It's only defined for functions that the compiler w=
ould have automatically generated code for; the reason you need it is to ov=
erride times when the C++ rules would forbid generating one. Now you're usi=
ng it in a circumstance where the compiler would <i>never</i> have automati=
cally generated code for it. Something like "=3D generate" would show that =
it's different from "default", since there is no actual default version.<br=
>
<br>On Saturday, November 10, 2012 8:53:31 PM UTC-8, <a>nx02co...@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">
tbh i prefer "codeless" declerative syntax. For the same reason why Herb pr=
efers for_each over for()... it makes clear what code does more quickly (in=
Herbs example you know there is no break, in this case when you have seen =
once operator /*...*/ =3D default or operator =3D /*...*/=
using in the future youll know <i>what</i> it does, aka =
you can quickly learn to move "abstraction level" above from <i>how <=
/i>it is being done to <i>what </i>is being done).<br>
That being said there needs to be a uniform way of doing things and if CTR =
group does 10 things it would be ugly to make exception from their style fo=
r this one. <br>For example IIRC std::to_string is not templated despite th=
e fact that std::string is typedef of basic_string. For me that is example =
of things not fitting nicely. <br>
<br>On Sunday, November 11, 2012 6:27:07 AM UTC+2, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><br><br>On Saturday, November 10, 2012 8:=
13:19 PM UTC-8, <a>nx02co...@gmail.com</a> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br><br>On Sunday, November 11, 2012 5:36:13 AM UTC+2, Xeo wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex">Just a quick comment on one thing.<br><br>On =
Sunday, November 11, 2012 2:22:10 AM UTC+1, <a>nx02co...@gmail.com</a> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
would work only for "C++" code aka wont work on structs that have raw point=
er members<br></blockquote><div>Having raw pointers in C++ is perfectly fin=
e, <i>as long as they don't own anything</i>.<br></div></blockquote>
<div>Ill elaborate:<br>problem is the following, if there is "declarative"&=
nbsp; syntax for =3D=3D there must be one for <, <=3D...<br>now point=
ers have multiple problems when it comes to what is default :<br>- it is po=
ssible that p1<p2, but *p1>*p2<br>
- for =3D=3D is default comparison on pointers or on the pointed to, aka do=
you care if they point to the same instance or if the instances are the sa=
me<br>-if one pointer is null how do you do < , >=3D... comparisons<b=
r>
one could argue that you can fix first 2 problems by having specializations=
for smart pointers, but still they dont solve third one. fact is tha=
t empty std::string can be compared to other string... but if you have opti=
on "not set" (nullptr) I dont see way around it<br>
<br></div></blockquote><div><br>I don't know. For this kind of thing, I'm t=
rusting the compile-time reflection study group to provide simple ways to s=
olve this problem. So you simply write:<br><br><div style=3D"background-col=
or: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">bool</span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">operator</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">=3D=3D(</span><span style=3D"color:#0=
08">const</span><span style=3D"color:#000"> T</span><span style=3D"color:#6=
60">&</span><span style=3D"color:#000"> rhs</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>const</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"> </span><span style=3D"color:#008">retur=
n</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::=
</span><span style=3D"color:#000">double_reflect_equals</span><span style=
=3D"color:#660"><</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">>(<wbr>*</span><span style=3D"color:#008">this</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> rhs</span=
><span style=3D"color:#660">);</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">}</span><span style=3D"color:#000"><br>
</span></div></code></div><br>Or something to that effect.<br></div></block=
quote></blockquote>
<p></p>
-- <br>
<br>
<br>
<br>
</div></div>
</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1564_1523185.1352623788313--
.
Author: nx02columbia@gmail.com
Date: Sun, 11 Nov 2012 13:02:39 -0800 (PST)
Raw View
------=_Part_747_8424722.1352667759705
Content-Type: text/plain; charset=ISO-8859-1
Hi, tnx for your answers.
Me personally would still be able to write default/generate or operator
>=()/*..*/ using operator <
but tbh Im a big believer in data beats opinions. And I guess there are ppl
that know things about lang design, and human psychology in a scientific
way(what design will cause less bugs, be more maintainable...) that are
much more better suited to decide what is the optimal way to do it, ofc
regarding real constraints of a real language like C++. Also declarative
things arent really new to C++, regex is example of declerative thing in
C++, though it is not a language feature, I guess RAII and try/catch are
better examples .
On Sunday, November 11, 2012 10:49:48 AM UTC+2, Nicol Bolas wrote:
>
>
>
> On Sunday, November 11, 2012 12:26:23 AM UTC-8, Tony V E wrote:
>>
>> I come from the Stepanov school of "code is math". I want almost all my
>> types to be RegularTypes. That includes equality comparable.
>>
>> As for =default or =generate -
>> If we use =default as in existing use, and introduce =generate for these
>> new uses,
>> Can I also use =generate in the places we currently use =default?
>>
>
> No more than you can use default everywhere. They mean different things,
> and you wouldn't want to apply them to the same functions. However, if you
> did:
>
>
>> If so, does it change anything (ie change trivially copyable, etc)?
>>
>
> Yes. `default` means "do what you would normally do if I hadn't done the
> thing that made you not do that". `generate` means "create a function
> definition based on some heuristic." If we allow `generate` to be used on
> special functions, they would not be explicitly defaulted and therefore not
> be trivially copyable.
>
> `generate` generates code. `default` is about doing the default. See the
> difference? `generate` does something you could do; `default` does
> something you *can't* do.
>
>
>> If not, I can just use =generate everywhere?
>>
>
> No. See above.
>
>
>> Then can I spell =generate as "=default" so as to not make a new keyword?
>>
>
> It's no more a keyword than "final" and "override".
>
>
>>
>> Tony
>>
>> ------------------------------
>> *From:* "Nicol Bolas" <jmck...@gmail.com>
>> *To:* "std-pr...@isocpp.org" <std-pr...@isocpp.org>
>> *CC:* "nx02co...@gmail.com" <nx02co...@gmail.com>, "hivem...@hotmail.de"
>> <hivem...@hotmail.de>
>> *Sent:* 11 November, 2012 1:25 AM
>> *Subject:* [std-proposals] Re: Any plans to remove need for boilerplate
>> code in struct/class comparison operators ?
>>
>> "= default" syntax wasn't added for that reason. It wasn't added to make
>> auto-generated copy constructors; it was added because it allowed you to
>> force the compiler to generate what it would have before. You *can't*replicate the behavior of "= default". A class that has a defaulted copy
>> constructor may be trivially copyable, while a class that has a
>> user-provided one, even if it does the *exact same thing*, isn't.
>>
>> It also happens to have nice visual properties and ease of understanding
>> while it's doing that. But the main purpose was to tell the compiler that,
>> "I know your rules say you won't auto-generate the copy constructor, but I
>> want you to do that now anyway".
>>
>> Considering how relatively infrequently one wants to write a type that
>> has comparisons (there are types you want to compare, it's just not most of
>> the types you write), it just seems to me that it's better to let the
>> reflection study group do their job and provide it as a library feature. I
>> just don't feel it is important enough to rise to the level where we want
>> compilers to write that code.
>>
>> Also, using the "= default" syntax makes it slightly confusing, compared
>> to the standard meaning. "default" doesn't just mean that the compiler
>> generates the function. It's only defined for functions that the compiler
>> would have automatically generated code for; the reason you need it is to
>> override times when the C++ rules would forbid generating one. Now you're
>> using it in a circumstance where the compiler would *never* have
>> automatically generated code for it. Something like "= generate" would show
>> that it's different from "default", since there is no actual default
>> version.
>>
>> On Saturday, November 10, 2012 8:53:31 PM UTC-8, nx02co...@gmail.comwrote:
>>>
>>> tbh i prefer "codeless" declerative syntax. For the same reason why Herb
>>> prefers for_each over for()... it makes clear what code does more quickly
>>> (in Herbs example you know there is no break, in this case when you have
>>> seen once operator /*...*/ = default or operator = /*...*/ using in the
>>> future youll know *what* it does, aka you can quickly learn to move
>>> "abstraction level" above from *how *it is being done to *what *is
>>> being done).
>>> That being said there needs to be a uniform way of doing things and if
>>> CTR group does 10 things it would be ugly to make exception from their
>>> style for this one.
>>> For example IIRC std::to_string is not templated despite the fact that
>>> std::string is typedef of basic_string. For me that is example of things
>>> not fitting nicely.
>>>
>>> On Sunday, November 11, 2012 6:27:07 AM UTC+2, Nicol Bolas wrote:
>>>>
>>>>
>>>>
>>>> On Saturday, November 10, 2012 8:13:19 PM UTC-8, nx02co...@gmail.comwrote:
>>>>>
>>>>>
>>>>>
>>>>> On Sunday, November 11, 2012 5:36:13 AM UTC+2, Xeo wrote:
>>>>>>
>>>>>> Just a quick comment on one thing.
>>>>>>
>>>>>> On Sunday, November 11, 2012 2:22:10 AM UTC+1, nx02co...@gmail.comwrote:
>>>>>>>
>>>>>>> would work only for "C++" code aka wont work on structs that have
>>>>>>> raw pointer members
>>>>>>>
>>>>>> Having raw pointers in C++ is perfectly fine, *as long as they don't
>>>>>> own anything*.
>>>>>>
>>>>> Ill elaborate:
>>>>> problem is the following, if there is "declarative" syntax for ==
>>>>> there must be one for <, <=...
>>>>> now pointers have multiple problems when it comes to what is default :
>>>>> - it is possible that p1<p2, but *p1>*p2
>>>>> - for == is default comparison on pointers or on the pointed to, aka
>>>>> do you care if they point to the same instance or if the instances are the
>>>>> same
>>>>> -if one pointer is null how do you do < , >=... comparisons
>>>>> one could argue that you can fix first 2 problems by having
>>>>> specializations for smart pointers, but still they dont solve third one.
>>>>> fact is that empty std::string can be compared to other string... but if
>>>>> you have option "not set" (nullptr) I dont see way around it
>>>>>
>>>>>
>>>> I don't know. For this kind of thing, I'm trusting the compile-time
>>>> reflection study group to provide simple ways to solve this problem. So you
>>>> simply write:
>>>>
>>>> bool operator ==(const T& rhs) const { return std::
>>>> double_reflect_equals<T>(*this, rhs); }
>>>>
>>>> Or something to that effect.
>>>>
>>> --
>>
>>
>>
>>
>
--
------=_Part_747_8424722.1352667759705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi, tnx for your answers.<br>Me personally would still be able to write def=
ault/generate or operator >=3D()/*..*/ using operator <<b=
r>but tbh Im a big believer in data beats opinions. And I guess there are p=
pl that know things about lang design, and human psychology in a scientific=
way(what design will cause less bugs, be more maintainable...) that are mu=
ch more better suited to decide what is the optimal way to do it, ofc regar=
ding real constraints of a real language like C++. Also declarative t=
hings arent really new to C++, regex is example of declerative thing in C++=
, though it is not a language feature, I guess RAII and try/catch are bette=
r examples . <br><br><br>On Sunday, November 11, 2012 10:49:48 AM UTC+2, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Sun=
day, November 11, 2012 12:26:23 AM UTC-8, Tony V E wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div>I come from the Stepanov school of "code is mat=
h". I want almost all my types to be RegularTypes. That includes equality c=
omparable.<div><br></div><div>As for =3Ddefault or =3Dgenerate -</div>
<div>If we use =3Ddefault as in existing use, and introduce =3Dgenerate for=
these new uses,</div><div>Can I also use =3Dgenerate in the places we curr=
ently use =3Ddefault?</div></div></blockquote><div><br>No more than you can=
use default everywhere. They mean different things, and you wouldn't want =
to apply them to the same functions. However, if you did:<br> </div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div><div>If so, does it change anyth=
ing (ie change trivially copyable, etc)?</div></div></blockquote><div><br>Y=
es. `default` means "do what you would normally do if I hadn't done the thi=
ng that made you not do that". `generate` means "create a function definiti=
on based on some heuristic." If we allow `generate` to be used on special f=
unctions, they would not be explicitly defaulted and therefore not be trivi=
ally copyable.<br><br>`generate` generates code. `default` is about doing t=
he default. See the difference? `generate` does something you could do; `de=
fault` does something you <i>can't</i> do.<br> <br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>
<div>If not, I can just use =3Dgenerate everywhere? </div></div></bloc=
kquote><div><br>No. See above.<br> </div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div><div>Then can I spell =3Dgenerate as "=3Ddefault" so as to =
not make a new keyword?</div></div></blockquote><div><br>It's no more a key=
word than "final" and "override".<br> </div><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div><br></div><div><div>Tony</div><div>
<br></div><hr><div><b>From:</b> "Nicol Bolas" <<a>jmck...@gmail.com</a>&=
gt;<br><b>To:</b> "<a>std-pr...@isocpp.org</a>" <<a>std-pr...@isocpp.org=
</a>><br>
<b>CC:</b> "<a>nx02co...@gmail.com</a>" <<a>nx02co...@gmail.com</a>>,=
"<a>hivem...@hotmail.de</a>" <<a>hivem...@hotmail.de</a>><br>
<b>Sent:</b> 11 November, 2012 1:25 AM<br><b>Subject:</b> [std-proposals] R=
e: Any plans to remove need for boilerplate code in struct/class comparison=
operators ?<br></div><br>"=3D default" syntax wasn't added for that reason=
.. It wasn't added to make auto-generated copy constructors; it was added be=
cause it allowed you to force the compiler to generate what it would have b=
efore. You <i>can't</i> replicate the behavior of "=3D default". A class th=
at has a defaulted copy constructor may be trivially copyable, while a clas=
s that has a user-provided one, even if it does the <i>exact same thing</i>=
, isn't.<br>
<br>It also happens to have nice visual properties and ease of understandin=
g while it's doing that. But the main purpose was to tell the compiler that=
, "I know your rules say you won't auto-generate the copy constructor, but =
I want you to do that now anyway".<br>
<br>Considering how relatively infrequently one wants to write a type that =
has comparisons (there are types you want to compare, it's just not most of=
the types you write), it just seems to me that it's better to let the refl=
ection study group do their job and provide it as a library feature. I just=
don't feel it is important enough to rise to the level where we want compi=
lers to write that code.<br>
<br>Also, using the "=3D default" syntax makes it slightly confusing, compa=
red to the standard meaning. "default" doesn't just mean that the compiler =
generates the function. It's only defined for functions that the compiler w=
ould have automatically generated code for; the reason you need it is to ov=
erride times when the C++ rules would forbid generating one. Now you're usi=
ng it in a circumstance where the compiler would <i>never</i> have automati=
cally generated code for it. Something like "=3D generate" would show that =
it's different from "default", since there is no actual default version.<br=
>
<br>On Saturday, November 10, 2012 8:53:31 PM UTC-8, <a>nx02co...@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">
tbh i prefer "codeless" declerative syntax. For the same reason why Herb pr=
efers for_each over for()... it makes clear what code does more quickly (in=
Herbs example you know there is no break, in this case when you have seen =
once operator /*...*/ =3D default or operator =3D /*...*/=
using in the future youll know <i>what</i> it does, aka =
you can quickly learn to move "abstraction level" above from <i>how <=
/i>it is being done to <i>what </i>is being done).<br>
That being said there needs to be a uniform way of doing things and if CTR =
group does 10 things it would be ugly to make exception from their style fo=
r this one. <br>For example IIRC std::to_string is not templated despite th=
e fact that std::string is typedef of basic_string. For me that is example =
of things not fitting nicely. <br>
<br>On Sunday, November 11, 2012 6:27:07 AM UTC+2, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><br><br>On Saturday, November 10, 2012 8:=
13:19 PM UTC-8, <a>nx02co...@gmail.com</a> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br><br>On Sunday, November 11, 2012 5:36:13 AM UTC+2, Xeo wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex">Just a quick comment on one thing.<br><br>On =
Sunday, November 11, 2012 2:22:10 AM UTC+1, <a>nx02co...@gmail.com</a> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
would work only for "C++" code aka wont work on structs that have raw point=
er members<br></blockquote><div>Having raw pointers in C++ is perfectly fin=
e, <i>as long as they don't own anything</i>.<br></div></blockquote>
<div>Ill elaborate:<br>problem is the following, if there is "declarative"&=
nbsp; syntax for =3D=3D there must be one for <, <=3D...<br>now point=
ers have multiple problems when it comes to what is default :<br>- it is po=
ssible that p1<p2, but *p1>*p2<br>
- for =3D=3D is default comparison on pointers or on the pointed to, aka do=
you care if they point to the same instance or if the instances are the sa=
me<br>-if one pointer is null how do you do < , >=3D... comparisons<b=
r>
one could argue that you can fix first 2 problems by having specializations=
for smart pointers, but still they dont solve third one. fact is tha=
t empty std::string can be compared to other string... but if you have opti=
on "not set" (nullptr) I dont see way around it<br>
<br></div></blockquote><div><br>I don't know. For this kind of thing, I'm t=
rusting the compile-time reflection study group to provide simple ways to s=
olve this problem. So you simply write:<br><br><div style=3D"background-col=
or: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">bool</span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">operator</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">=3D=3D(</span><span style=3D"color:#0=
08">const</span><span style=3D"color:#000"> T</span><span style=3D"color:#6=
60">&</span><span style=3D"color:#000"> rhs</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>const</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"> </span><span style=3D"color:#008">retur=
n</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::=
</span><span style=3D"color:#000">double_reflect_equals</span><span style=
=3D"color:#660"><</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">>(<wbr>*</span><span style=3D"color:#008">this</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> rhs</span=
><span style=3D"color:#660">);</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">}</span><span style=3D"color:#000"><br>
</span></div></code></div><br>Or something to that effect.<br></div></block=
quote></blockquote>
<p></p>
-- <br>
<br>
<br>
<br>
</div></div>
</blockquote></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_747_8424722.1352667759705--
.