Topic: Thoughts/idea about N4401 vs N4475 (regarding raw
Author: lie4pan1 <lie4pan1@gmail.com>
Date: Wed, 29 Apr 2015 02:09:56 -0700 (PDT)
Raw View
------=_Part_6987_3080161.1430298596744
Content-Type: multipart/alternative;
boundary="----=_Part_6988_228658399.1430298596744"
------=_Part_6988_228658399.1430298596744
Content-Type: text/plain; charset=UTF-8
Hi!
I've read about some proposals papers on defaulted comparison operators. I
like the idea that some comparisons (see below) be default-generated, but I
don't think *inconsistent* 'default-generated operators' rules that could
only resolve part of the problem regarding raw pointers and mutables are
good for a language like C++ that is already so complicated.
Difference should look different. How about:
class MyClass
{
// Existence of '__cookie__' non-mutable raw pointers prevent the compiler
from generating defaulted copy-ctor, operator== etc.
// However, if there were no such pointers (in this example, __cookie__
Datum *newed_),
// the default-generated copy-ctor should only (shallow-)copy
non-'__cookie__' members ignoring '__cookie__' ones,
// the default-generated operator== shall only (shallow-)compare
non-'__cookie__' members ignoring '__cookie__' ones,
// and so on.
private:
const Object *one_; // non-owning observer pointer, can
be treated trivially
private:
__cookie__ Datum *newed_; // non-mutable owning pointer,
shouldn't be shallow-copied/compared, thus suppressing defaulted
__cookie__ mutable Cache_ last_; // some cache data, should be
ignored in comparisons, in common sense
__cookie__ mutable bool dirty_; // some cache invalidation flag,
same treatment as above
private /*friend class IntrsiveList*/: // <- please ignore this block
comment :-p
__cookie__ mutable MyClass *next_; // I would argue that this is
mutable because it is not part of the object's internal state,
// thus it should be ignored for
object copying and comparisons
};
// Pros:
// * New syntax/keyword.
// * Clearer expression/documentation of intention on data members of the
class author(s).
// * Provides a simple way to somehow fix the old-ish defaulted
copy-ctor/assignment issues with raw pointer / mutable members.
// * Things that should work without extra work eg. raw observer pointers
work.
// Cons:
// * New syntax/keyword.
// * Buggy code that fails to add '__cookie__' where necessary might be
misused (with the newly defaulted comparison operators).
That is basically N4401 + new '__cookie__' rules. The new rules are
consistent with all defaulted operators.
(Yes I am only talking about defaulted operator== and operator!= here
because I am unsure about other comparisons related to ordering.)
--
---
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_6988_228658399.1430298596744
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family: courier new,monospace;"><span =
style=3D"font-family: arial,sans-serif;">Hi!<br><br>I've read about some pr=
oposals papers on defaulted comparison operators</span></span><span style=
=3D"font-family: courier new,monospace;"><span style=3D"font-family: arial,=
sans-serif;">. I like the idea that some comparisons</span></span><span sty=
le=3D"font-family: courier new,monospace;"><span style=3D"font-family: aria=
l,sans-serif;"><span style=3D"font-family: courier new,monospace;"><span st=
yle=3D"font-family: arial,sans-serif;"> (see below)</span></span> be defaul=
t-generated, but I don't think </span></span><span style=3D"font-family: co=
urier new,monospace;"><span style=3D"font-family: arial,sans-serif;"><span =
style=3D"font-family: courier new,monospace;"><span style=3D"font-family: a=
rial,sans-serif;"><b>inconsistent</b> </span></span>'default-generated oper=
ators'</span></span><span style=3D"font-family: courier new,monospace;"><sp=
an style=3D"font-family: arial,sans-serif;"><span style=3D"font-family: cou=
rier new,monospace;"><span style=3D"font-family: arial,sans-serif;"> rules =
that could only resolve part of the problem</span></span></span></span><spa=
n style=3D"font-family: courier new,monospace;"><span style=3D"font-family:=
arial,sans-serif;"><span style=3D"font-family: courier new,monospace;"><sp=
an style=3D"font-family: arial,sans-serif;"><span style=3D"font-family: cou=
rier new,monospace;"><span style=3D"font-family: arial,sans-serif;"><span s=
tyle=3D"font-family: courier new,monospace;"><span style=3D"font-family: ar=
ial,sans-serif;"> regarding raw pointers and mutables</span></span></span><=
/span> are good</span></span> for a language</span></span><span style=3D"fo=
nt-family: courier new,monospace;"><span style=3D"font-family: arial,sans-s=
erif;"><span style=3D"font-family: courier new,monospace;"><span style=3D"f=
ont-family: arial,sans-serif;"> like C++</span></span> that is already so c=
omplicated.<br><br></span></span><span style=3D"font-family: courier new,mo=
nospace;"><span style=3D"font-family: arial,sans-serif;"><span style=3D"fon=
t-family: courier new,monospace;"><span style=3D"font-family: arial,sans-se=
rif;"> Difference should look different.</span></span> How about:<br><br></=
span><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">MyClass</span><span s=
tyle=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><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// Existence of '__cookie__' non-mutable ra=
w pointers prevent the compiler from generating defaulted copy-ctor, operat=
or=3D=3D etc.</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
However, if there were no such pointers (in this example, __cookie__ Datum =
*newed_),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// the =
default-generated copy-ctor should only (shallow-)copy non-'__cookie__' mem=
bers ignoring '__cookie__' ones,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// the default</span><span style=3D"color: #800;" class=
=3D"styled-by-prettify"><span style=3D"font-family: courier new,monospace;"=
><code class=3D"prettyprint"><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">-generat</span><span style=3D"color: #800;" class=3D"styled-by-=
prettify"></span></code></span>ed operator=3D=3D shall only (shallow-)compa=
re non-'__cookie__' members ignoring '__cookie__' ones,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// and so on.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">private</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br> </span><span style=3D"color: #0=
08;" 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">Object</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">on=
e_</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> &n=
bsp; </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">// non-owning observer pointer, can be treated=
trivially</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">privat=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
__cookie__ </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Datum</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">newed_</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// non-mut=
able owning pointer, shouldn't be shallow-copied/compared, thus suppressing=
defaulted</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> __cookie__ </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">mutable</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Cache_</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> last_</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: #800;" class=3D"styled-by-prettify">// some cach=
e data, should be ignored in comparisons, in common sense</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> __cookie__=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">mutable</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> dirty_</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"c=
olor: #800;" class=3D"styled-by-prettify">// some cache invalidation flag, =
same treatment as above</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">private</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/*fri=
end class IntrsiveList*/</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// &=
lt;- please ignore this block comment :-p</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> __cookie__ </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">mutable</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">MyClass</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">next_</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// I w=
ould argue that this is mutable because it is not part of the object's inte=
rnal state,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br> =
</span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">// thus it shoul=
d be ignored for object copying and comparisons</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><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// Pros:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// * New syntax/keyword.</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// * Clearer expression/documentation of intentio=
n on data members of the class author(s).</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">// * Provides a simple way to somehow fix the old-=
ish defaulted copy-ctor/assignment issues with raw pointer / mutable member=
s.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">// * Things th=
at should work without extra work eg. raw observer pointers work.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// Cons:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// * New syntax/keyword.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// * Buggy code that fails=
to add '__cookie__' where necessary might be misused (with the newly defau=
lted comparison operators).</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br></span></div></code></div><span style=3D"font-fami=
ly: arial,sans-serif;"><br>That is basically N4401 + new '__cookie__' rules=
.. The new rules are consistent with all defaulted operators.<br></span></sp=
an><span style=3D"font-family: courier new,monospace;"><span style=3D"font-=
family: arial,sans-serif;"><span style=3D"font-family: courier new,monospac=
e;"><span style=3D"font-family: arial,sans-serif;">(Yes I am only talking a=
bout </span></span><span style=3D"font-family: courier new,monospace;"><spa=
n style=3D"font-family: arial,sans-serif;"><span style=3D"font-family: cour=
ier new,monospace;"><span style=3D"font-family: arial,sans-serif;">defaulte=
d operator=3D=3D and operator!=3D</span></span> here because I am unsure ab=
out other comparisons</span></span></span></span><span style=3D"font-family=
: courier new,monospace;"><span style=3D"font-family: arial,sans-serif;"><s=
pan style=3D"font-family: courier new,monospace;"><span style=3D"font-famil=
y: arial,sans-serif;"><span style=3D"font-family: courier new,monospace;"><=
span style=3D"font-family: arial,sans-serif;"><span style=3D"font-family: c=
ourier new,monospace;"><span style=3D"font-family: arial,sans-serif;"> rela=
ted to ordering</span></span></span></span>.)<br></span></span></span></spa=
n><span style=3D"font-family: courier new,monospace;"><br></span></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_6988_228658399.1430298596744--
------=_Part_6987_3080161.1430298596744--
.
Author: lie4pan1 <lie4pan1@gmail.com>
Date: Wed, 29 Apr 2015 02:56:20 -0700 (PDT)
Raw View
------=_Part_164_664508031.1430301380612
Content-Type: multipart/alternative;
boundary="----=_Part_165_1471512617.1430301380613"
------=_Part_165_1471512617.1430301380613
Content-Type: text/plain; charset=UTF-8
After some thoughts I think any '__cookie__' non-mutable members should
suppress generating such said defaulted operators, so this mechanism can be
used to help with some non-pointer primitive handle types that also require
extra work in said operations. The rules can now be simper:
non-'__cookie__': included and used in said defaulted operators
'__cookie__' non-mutable: suppressing said defaulted operators (or even
suppressing defaulted ctor and/or dtor as well???)
'__cookie__' mutable: excluded and ignored in said defaulted operators
What do yo think?
--
---
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_165_1471512617.1430301380613
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">After some thoughts I think any '__cookie__' non-mutable m=
embers should suppress generating such said defaulted operators, so this me=
chanism can be used to help with some non-pointer primitive handle types th=
at also require extra work in said operations. The rules can now be simper:=
<br><br><div dir=3D"ltr"><span style=3D"font-family:courier new,monospace">=
non-'__cookie__': included and used in said defaulted operators<br>'__cooki=
e__' non-mutable: suppressing said defaulted operators (or even suppressing=
defaulted ctor and/or dtor as well???)<br>'__cookie__' mutable: excluded a=
nd ignored in said defaulted operators<br></span><br>What do yo think?<br><=
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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_165_1471512617.1430301380613--
------=_Part_164_664508031.1430301380612--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 30 Apr 2015 09:17:59 +0800
Raw View
--Apple-Mail=_429D5339-73A8-4AC8-AB6D-7938F9F6D1C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9329, at 5:56 PM, lie4pan1 <lie4pan1@gmail.com> =
wrote:
>=20
> After some thoughts I think any '__cookie__' non-mutable members should s=
uppress generating such said defaulted operators
What=E2=80=99s the point of declaring a __cookie__ when you can just declar=
e the operator as deleted? If we treat all pointers as implicitly __cookie_=
_, your position maps to the status quo, except that mutable members can be=
included, which is a very niche case.
N4475 already notes the ambiguity around mutable members. Oddly it overlook=
s the alternative of letting them suppress the implicit declaration, but le=
aving the implicit definition available by =3D default. That=E2=80=99s what=
I would favor.
Letting a mutable member participate in operator =3D=3D sounds like bad des=
ign. If you really want that, and there are lots of members, you can factor=
the mutable and non-mutable members into two base classes, and then a deri=
ved class can compose its operator from from the base class implicit defini=
tions.
--=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/.
--Apple-Mail=_429D5339-73A8-4AC8-AB6D-7938F9F6D1C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9329, at 5:56 PM, lie4pan1 <<a href=3D"mailto:lie4pan1@gmail.com"=
class=3D"">lie4pan1@gmail.com</a>> wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><span style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; displa=
y: inline !important;" class=3D"">After some thoughts I think any '__cookie=
__' non-mutable members should suppress generating such said defaulted oper=
ators</span></div></blockquote></div><br class=3D""><div class=3D"">What=E2=
=80=99s the point of declaring a <font face=3D"Courier" class=3D"">__cookie=
__</font> when you can just declare the operator as deleted? If we tre=
at all pointers as implicitly <span style=3D"font-family: Courier;" cl=
ass=3D"">__cookie__</span>, your position maps to the status quo, except th=
at mutable members can be included, which is a very niche case.</div><div c=
lass=3D""><br class=3D""></div><div class=3D"">N4475 already notes the ambi=
guity around mutable members. Oddly it overlooks the alternative of letting=
them suppress the implicit declaration, but leaving the implicit definitio=
n available by <font face=3D"Courier" class=3D"">=3D default</font>. That=
=E2=80=99s what I would favor.</div><div class=3D""><br class=3D""></div><d=
iv class=3D"">Letting a mutable member participate in <font face=3D"Courier=
" class=3D"">operator =3D=3D</font> sounds like bad design. If you really w=
ant that, and there are lots of members, you can factor the mutable and non=
-mutable members into two base classes, and then a derived class can compos=
e its operator from from the base class implicit definitions.</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--Apple-Mail=_429D5339-73A8-4AC8-AB6D-7938F9F6D1C1--
.
Author: lie4pan1 <lie4pan1@gmail.com>
Date: Thu, 30 Apr 2015 04:30:34 -0700 (PDT)
Raw View
------=_Part_259_778544722.1430393434519
Content-Type: multipart/alternative;
boundary="----=_Part_260_383281483.1430393434519"
------=_Part_260_383281483.1430393434519
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
What are you referring to as 'status quo'? It can't be the current C++=20
standard (C++2014) which doesn't treat pointer/mutable members differenty=
=20
from others.
Anyways, I throw (some of) my rationales out here, in a somewhat FAQs way:
*Isn't the "=3D default/delete" approach sufficient?*
No. The "=3D default/delete" approach can only control "whether to have the=
=20
operations", but cannot control "what to be included in such operations".
It's just like a boolean, which can have only true and false value and=20
cannot express "what" at the same time, which we should be able to express.
*Could we treat **all pointers as implicitly '__cookie__' to get around **"=
=3D=20
default/delete"'s boolean limitation?*
The issues to simply treat (only and) all pointers as implicitly=20
'__cookie__' (this would be virtually the same as what to do with pointers=
=20
as N4475 proposed) are:
* Some pointers shouldn't be '__cookie__'. Example: non-owning observer=20
pointers.
* Some non-pointers should be '__cookie__'. Example: owning resource=20
handles.
It would result in both "false positives" and "false negatives". Therefore,=
=20
to implicitly treat pointer members as '__cookie__' is not the exact=20
solution to the problem. This is like how garbage collection is not the=20
exact solution to the resource management problem.
*Why not just take the "=3D default/delete" approach and then explicitly=20
define what to be included in the operations?*
A list of "ReturnType operator Op(Parameters) =3D default/delete"s is alrea=
dy=20
a bit verbose to write, not to mention to implement them by hand.
Moreover, the explicit approach can be susceptible to future changes.
On the coders side, there're operations that the they don't intend to be=20
used, and they might simply ignore those, until some imlementation details=
=20
got changed in a way that the coders will be forced to care about them.=20
(You may call that "bad practice", but it happens.)
Assuming your suggested approach (N4475 + "=3D default") come true:
When the class had no mutable or pointer members, the class author could=20
rely on the implicitly generated operations. But when something like an=20
intrusive list node pointer got added to the class, the class author would=
=20
have to "=3D default" some of the used operations like operator=3D=3D (wher=
e the=20
node pointer would be excluded in the "=3D default" versions) and define th=
e=20
others like operator=3D (where the node pointer would be included in the "=
=3D=20
default" versions). Then if a observer pointer member got added, the class=
=20
author would have to explicitly implement all of them (because all of the=
=20
"=3D default" versions would be wrong).
Of course, the class author could have defined all of the operations in the=
=20
beginning, but then what is the benifit of "=3D default" to him/her if it i=
s=20
so limited and fragile?
With my proposed '__cookie__', that class author would just need to label=
=20
the members properly, and everything would just work fine.
On the language side, it's not just the new-to-add comparison operators=20
that would be affected. It's also the move/copy-ctors, assignment etc. that=
=20
have been affected. And in case we were to add even more defaulted=20
operations by any chance, those will also be affected. You can't just=20
simply add those not-so-scalable "=3D delete/default" at the present time t=
o=20
utilize/prevent future language additions. Worse, being afraid of silently=
=20
breaking existing code would greatly reduce usefulness of such new features=
=20
(have to be more explicit, more" =3D default/delete", more expert techs) or=
=20
even prevent from their additions.
But with clear constrains such as the '__cookie__' rules proposed here,=20
future language additions can find a firmer ground to stand and move on=20
with less fear.
*Why should we put labels ('__cookie__' etc.) on the members?*
Because whether such a member should be copied/compared etc. *is the=20
attribute of itself* (AKA in the member's own encapsulation), and the=20
encapsulating class shall respect that.
The '__cookie__' mechanism can encapsulate such attributes with the member,=
=20
no matter if it is a primitive pointer or a feature-rich type. This would=
=20
be a small enhancement to the type system.
Moreover, when proper usage of '__cookie__' has been put in practice=20
(enforced by coding standard or something else), coders and maybe also=20
compilers may know more about what the members are meant to be by looking=
=20
at such carried type info, and utilize them *anywher*e, which is one of the=
=20
pros listed in my OP.
The benefits above wouldn't be there with explicit operation definitions=20
(or "=3D default/delete") instead.
*What about mutable members?*
Whether mutable members should participate in operator=3D=3D was not the ma=
in=20
concern. In most use case mutable means "external to the logical state",=20
but in rare case it might be (mis-)used in the sense of "non-const" (and in=
=20
some case maybe a mix of the two). Yeah the word "mutable" fails to match=
=20
its primary usage (or the other way around). My proposal would keep the=20
ability to continue supporting the hackish usage ("bad designs").
*Any breakage with '__coockie__', especially silent behaviour change?*
No existing correct code should be broken (especially in the sense of=20
"silent behaviour change"). Only new code that invokes the newly defaulted=
=20
operations on old code base where '__cookie__' hasn't been properly applied=
=20
can be broken, which I listed as one of the cons in my OP. If it's=20
determined that the "bad designs with mutables" shouldn't be supported, the=
=20
rule can be changed to make all mutable members implicitly '__cookie__'.=20
However the problem with finding out all raw owning pointers/handles in old=
=20
code base might only be helped with diagnostic warnings/tools.
On Thursday, April 30, 2015 at 1:18:10 AM UTC, David Krauss wrote:
>
>
> On 2015=E2=80=9304=E2=80=9329, at 5:56 PM, lie4pan1 <lie4...@gmail.com <j=
avascript:>>=20
> wrote:
>
> After some thoughts I think any '__cookie__' non-mutable members should=
=20
> suppress generating such said defaulted operators
>
>
> What=E2=80=99s the point of declaring a __cookie__ when you can just decl=
are the=20
> operator as deleted? If we treat all pointers as implicitly __cookie__,=
=20
> your position maps to the status quo, except that mutable members can be=
=20
> included, which is a very niche case.
>
> N4475 already notes the ambiguity around mutable members. Oddly it=20
> overlooks the alternative of letting them suppress the implicit=20
> declaration, but leaving the implicit definition available by =3D default=
..=20
> That=E2=80=99s what I would favor.
>
> Letting a mutable member participate in operator =3D=3D sounds like bad=
=20
> design. If you really want that, and there are lots of members, you can=
=20
> factor the mutable and non-mutable members into two base classes, and the=
n=20
> a derived class can compose its operator from from the base class implici=
t=20
> definitions.
>
--=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_260_383281483.1430393434519
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What are you referring to as 'status quo'? It can't be the=
current C++ standard (C++2014) which doesn't treat pointer/mutable members=
differenty from others.<br> <br>Anyways, I throw (some of) my rationales o=
ut here, in a somewhat FAQs way:<br><br><b>Isn't the "=3D default/delete" a=
pproach sufficient?</b><br>No. The "=3D default/delete" approach can only c=
ontrol "whether to have the operations", but cannot control "what to be inc=
luded in such operations".<br>It's just like a boolean, which can have only=
true and false value and cannot express "what" at the same time, which we =
should be able to express.<br><br><b>Could we treat </b><b>all pointers as =
implicitly <span style=3D"font-family:Courier">'__cookie__</span>' to get a=
round </b><b><b>"=3D default/delete"'s boolean limitation</b>?</b><br>The i=
ssues to simply treat (only and) all pointers as implicitly <span style=3D"=
font-family:Courier">'__cookie__'</span> (this would be virtually the same =
as what to do with pointers as N4475 proposed) are:<br>* Some pointers shou=
ldn't be <span style=3D"font-family:Courier">'__cookie__</span>'. Example: =
non-owning observer pointers.<br>* Some non-pointers should be <span style=
=3D"font-family:Courier">'__cookie__'</span>. Example: owning resource hand=
les.<br><br>It would result in both "false positives" and "false negatives"=
.. Therefore, to implicitly treat pointer members as '__cookie__' is not the=
exact solution to the problem. This is like how garbage collection is not =
the exact solution to the resource management problem.<br><br><b>Why not ju=
st take the "=3D default/delete" approach and then explicitly define what t=
o be included in the operations?</b><br>A list of "ReturnType operator Op(P=
arameters) =3D default/delete"s is=20
already a bit verbose to write, not to mention to implement them by hand.<b=
r><br>Moreover, the explicit approach can be susceptible to future changes.=
<br><br>On the coders side, there're operations that the they don't intend =
to be used, and they might simply ignore those, until some imlementation de=
tails got changed in a way that the coders will be forced to care about the=
m. (You may call that "bad practice", but it happens.)<br><br> Assuming you=
r suggested approach (N4475 + "=3D default") come true:<br>When the class h=
ad no mutable or pointer members, the class author could rely on the implic=
itly generated operations. But when something like an intrusive list node p=
ointer got added to the class, the class author would have to "=3D default"=
some of the used operations like operator=3D=3D (where the node pointer wo=
uld be excluded in the "=3D default" versions) and define the others like o=
perator=3D (where the node pointer would be included in the "=3D default" v=
ersions). Then if a observer pointer member got added, the class author wou=
ld have to explicitly implement all of them (because all of the "=3D defaul=
t" versions would be wrong).<br><br>Of course, the class author could have =
defined all of the operations in the beginning, but then what is the benifi=
t of "=3D default" to him/her if it is so limited and fragile?<br><br>With=
my proposed '__cookie__', that class author would just need to label the m=
embers properly, and everything would just work fine.<br><br>On the languag=
e side, it's not just the new-to-add comparison operators that would be aff=
ected. It's also the move/copy-ctors, assignment etc. that have been affect=
ed. And in case we were to add even more defaulted operations by any chance=
, those will also be affected. You can't just simply add those not-so-scala=
ble "=3D delete/default" at the present time to utilize/prevent future lang=
uage additions. Worse, being afraid of silently breaking existing code woul=
d greatly reduce usefulness of such new features (have to be more explicit,=
more" =3D default/delete", more expert techs) or even prevent from their a=
dditions.<br><br>But with clear constrains such as the '__cookie__' rules p=
roposed here, future language additions can find a firmer ground to stand a=
nd move on with less fear.<br><br><b>Why should we put labels ('__cookie__'=
etc.) on the members?</b><br>Because
whether such a member should be copied/compared etc. <i>is the attribute o=
f=20
itself</i> (AKA in the member's own encapsulation), and the encapsulating c=
lass
shall respect that.<br><br>The '__cookie__' mechanism can encapsulate=20
such attributes with the member, no matter if it is a primitive pointer=20
or a feature-rich type. This would be a small enhancement to the type syste=
m.<br><br>Moreover, when proper usage of '__cookie__' has been put in pract=
ice (enforced
by coding standard or something else), coders and maybe also compilers=20
may know more about what the members are meant to be by looking at such=20
carried type info, and utilize them <i>anywher</i>e, which is one of the=20
pros listed in my OP.<br><br>The benefits above wouldn't be there with expl=
icit operation definitions (or "=3D default/delete") instead.<br><br><b>Wha=
t about mutable members?</b><br>Whether mutable members should participate =
in <font face=3D"Courier">operator=3D=3D</font> was not the main concern. I=
n most use case mutable means "external to the logical state", but in rare =
case it might be (mis-)used in the sense of "non-const" (and in some case m=
aybe a mix of the two). Yeah the word "mutable" fails to match its primary =
usage (or the other way around). My proposal would keep the ability to cont=
inue supporting the hackish usage ("bad designs").<br><br><b>Any breakage =
with '__coockie__', especially silent behaviour change?</b><br>No existing =
correct code should be broken (especially in the sense of "silent behaviour=
change"). Only new code that invokes the newly defaulted operations on old=
code base where '__cookie__' hasn't been properly applied can be broken, w=
hich I listed as one of the cons in my OP. If it's determined that the "bad=
designs with mutables" shouldn't be supported, the rule can be changed to =
make all mutable members implicitly '__cookie__'. However the problem with =
finding out all raw owning pointers/handles in old code base might only be =
helped with diagnostic warnings/tools.<br><br>On Thursday, April 30, 2015 a=
t 1:18:10 AM UTC, David Krauss wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"cit=
e"><div>On 2015=E2=80=9304=E2=80=9329, at 5:56 PM, lie4pan1 <<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"5SGC3owTF0IJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">lie4...@gmail.com</a>> wrot=
e:</div><br><div><span style=3D"font-family:Helvetica;font-size:12px;font-s=
tyle:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;li=
ne-height:normal;text-align:start;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px;float:none;display:inline!important">After s=
ome thoughts I think any '__cookie__' non-mutable members should suppress g=
enerating such said defaulted operators</span></div></blockquote></div><br>=
<div>What=E2=80=99s the point of declaring a <font face=3D"Courier">__cooki=
e__</font> when you can just declare the operator as deleted? If we tr=
eat all pointers as implicitly <span style=3D"font-family:Courier">__c=
ookie__</span>, your position maps to the status quo, except that mutable m=
embers can be included, which is a very niche case.</div><div><br></div><di=
v>N4475 already notes the ambiguity around mutable members. Oddly it overlo=
oks the alternative of letting them suppress the implicit declaration, but =
leaving the implicit definition available by <font face=3D"Courier">=3D def=
ault</font>. That=E2=80=99s what I would favor.</div><div><br></div><div>Le=
tting a mutable member participate in <font face=3D"Courier">operator =3D=
=3D</font> sounds like bad design. If you really want that, and there are l=
ots of members, you can factor the mutable and non-mutable members into two=
base classes, and then a derived class can compose its operator from from =
the base class implicit definitions.</div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_260_383281483.1430393434519--
------=_Part_259_778544722.1430393434519--
.