------=_Part_537_1450581493.1519254010730
Content-Type: multipart/alternative;
 boundary="----=_Part_538_854799008.1519254010730"

------=_Part_538_854799008.1519254010730
Content-Type: text/plain; charset="UTF-8"

One of my post on stackoverflow.com was said to have its place here.

https://stackoverflow.com/questions/48915277/what-about-pseudoconst-qualifier

What do you think about my new pseudoconst qualifier ?
Expecting for your answer, (and/or possibly a job: long unemployed at the
moment)

Jerome Saint-Martin,
Montrouge, France



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%40isocpp.org.

------=_Part_538_854799008.1519254010730
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One of my post on stackoverflow.com was said to have its p=
lace here.<br><br>https://stackoverflow.com/questions/48915277/what-about-p=
seudoconst-qualifier<br><br>What do you think about my new pseudoconst qual=
ifier ? <br>Expecting for your answer, (and/or possibly a job: long unemplo=
yed at the moment)<br><br>Jerome Saint-Martin, <br>Montrouge, France<br><br=
>
       =20




           =20
           =20
<table><tbody><tr><td class=3D"votecell"><br></td><td class=3D"postcell"><b=
r></td></tr></tbody></table></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee=
%40isocpp.org</a>.<br />

------=_Part_538_854799008.1519254010730--

------=_Part_537_1450581493.1519254010730--

.

--94eb2c124da2d20f860565c1356e
Content-Type: text/plain; charset="UTF-8"

Welcome!

Perhaps you can explain the consequences further, namely give an example of
something useful that it would allow.

One of the benefits of having something const is not just that the data is
unchanged at the END, but that it doesn't change AT ALL during execution.
This is often useful in a threaded situation (when you want to make sure
you don't introduce race conditions), and its primary purpose is to stop
you from making mistakes rather than to optimise.

On top of this, the compiler is able to easily determine whether or not you
are obeying the const declaration in the definition of a method, in that
only const operations are used inside of it - how is the compiler supposed
to verify if the second method *actually* reverses the first? Trust the
developer? Because that's the situation we have without const already.

On 21 Feb 2018 23:00, <jsaintmartin356@gmail.com> wrote:

> One of my post on stackoverflow.com was said to have its place here.
>
> https://stackoverflow.com/questions/48915277/what-about-
> pseudoconst-qualifier
>
> What do you think about my new pseudoconst qualifier ?
> Expecting for your answer, (and/or possibly a job: long unemployed at the
> moment)
>
> Jerome Saint-Martin,
> Montrouge, France
>
>
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-
> ab6a-18bf6ac873ee%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPGJ2J%3Dy3x-2voHCffyXTqsPVwWyyjR99v6R-XgyU1V4w%40mail.gmail.com.

--94eb2c124da2d20f860565c1356e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Welcome!<div dir=3D"auto"><br></div><div dir=3D"auto">Per=
haps you can explain the consequences further, namely give an example of so=
mething useful that it would allow.<div dir=3D"auto"><br></div><div dir=3D"=
auto">One of the benefits of having something const is not just that the da=
ta is unchanged at the END, but that it doesn&#39;t change AT ALL during ex=
ecution. This is often useful in a threaded situation (when you want to mak=
e sure you don&#39;t introduce race conditions), and its primary purpose is=
 to stop you from making mistakes rather than to optimise.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">On top of this, the compiler is able to =
easily determine whether or not you are obeying the const declaration in th=
e definition of a method, in that only const operations are used inside of =
it - how is the compiler supposed to verify if the second method <i>actuall=
y</i> reverses the first? Trust the developer? Because that&#39;s the situa=
tion we have without const already.</div></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On 21 Feb 2018 23:00,  &lt;<a href=3D"m=
ailto:jsaintmartin356@gmail.com">jsaintmartin356@gmail.com</a>&gt; wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">One =
of my post on <a href=3D"http://stackoverflow.com" target=3D"_blank">stacko=
verflow.com</a> was said to have its place here.<br><br><a href=3D"https://=
stackoverflow.com/questions/48915277/what-about-pseudoconst-qualifier" targ=
et=3D"_blank">https://stackoverflow.com/<wbr>questions/48915277/what-about-=
<wbr>pseudoconst-qualifier</a><br><br>What do you think about my new pseudo=
const qualifier ? <br>Expecting for your answer, (and/or possibly a job: lo=
ng unemployed at the moment)<br><br>Jerome Saint-Martin, <br>Montrouge, Fra=
nce<br><br>
       =20




           =20
           =20
<table><tbody><tr><td class=3D"m_8366955350456529130votecell"><br></td><td =
class=3D"m_8366955350456529130postcell"><br></td></tr></tbody></table></div=
>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f202=
be10-efb5-4f1a-<wbr>ab6a-18bf6ac873ee%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPGJ2J%3Dy3x-2voHCffyXTqsPVwW=
yyjR99v6R-XgyU1V4w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPGJ2=
J%3Dy3x-2voHCffyXTqsPVwWyyjR99v6R-XgyU1V4w%40mail.gmail.com</a>.<br />

--94eb2c124da2d20f860565c1356e--

.

--001a1140fbea5c91550565c13a1f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 22 Feb 2018 at 00:00, <jsaintmartin356@gmail.com> wrote:

> One of my post on stackoverflow.com was said to have its place here.
>
>
> https://stackoverflow.com/questions/48915277/what-about-pseudoconst-quali=
fier
>


When I examined your example on stack overflow, I wondered whether the. Or
react solution would be to make the vector mutable, which is in a way,
making the class =E2=80=9Cpseudo const=E2=80=9D, no?

>
> What do you think about my new pseudoconst qualifier ?
> Expecting for your answer, (and/or possibly a job: long unemployed at the
> moment)
>
> Jerome Saint-Martin,
> Montrouge, France
>
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f202be10-efb=
5-4f1a-ab6a-18bf6ac873ee%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f202be10-ef=
b5-4f1a-ab6a-18bf6ac873ee%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3hZHCzuAMWdqmbSB75im_SB92h8pFe3Z2WiFqh2n1Ca=
zDw%40mail.gmail.com.

--001a1140fbea5c91550565c13a1f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><br><div class=3D"gmail_quote"><div dir=3D"auto">On Thu, 22 Feb 2018 a=
t 00:00, &lt;<a href=3D"mailto:jsaintmartin356@gmail.com">jsaintmartin356@g=
mail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>One of=
 my post on <a href=3D"http://stackoverflow.com" target=3D"_blank">stackove=
rflow.com</a> was said to have its place here.<br><br><a href=3D"https://st=
ackoverflow.com/questions/48915277/what-about-pseudoconst-qualifier" target=
=3D"_blank">https://stackoverflow.com/questions/48915277/what-about-pseudoc=
onst-qualifier</a><br></div></blockquote><div dir=3D"auto"><br></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">When I examined your example on sta=
ck overflow, I wondered whether the. Or react solution would be to make the=
 vector mutable, which is in a way, making the class =E2=80=9Cpseudo const=
=E2=80=9D, no?</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>What do you thi=
nk about my new pseudoconst qualifier ? <br>Expecting for your answer, (and=
/or possibly a job: long unemployed at the moment)<br><br>Jerome Saint-Mart=
in, <br>Montrouge, France<br><br>
       =20




           =20
           =20
<table><tbody><tr><td class=3D"m_682075862105583414votecell"><br></td><td c=
lass=3D"m_682075862105583414postcell"><br></td></tr></tbody></table></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-=
4f1a-ab6a-18bf6ac873ee%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZHCzuAMWdqmbSB75im_SB92h8pFe3Z=
2WiFqh2n1CazDw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZHCzuAMWdq=
mbSB75im_SB92h8pFe3Z2WiFqh2n1CazDw%40mail.gmail.com</a>.<br />

--001a1140fbea5c91550565c13a1f--

.

--001a114df622a373010565c16146
Content-Type: text/plain; charset="UTF-8"

Also note that you're including the allocation of 1000 size_ts in that
first timer. I'm not at my PC right now to test, but does moving the
initialization of V to before the clock start significantly reduce the
discrepancy?

On 21 Feb 2018 23:23, "Jake Arkinstall" <jake.arkinstall@gmail.com> wrote:

> Welcome!
>
> Perhaps you can explain the consequences further, namely give an example
> of something useful that it would allow.
>
> One of the benefits of having something const is not just that the data is
> unchanged at the END, but that it doesn't change AT ALL during execution.
> This is often useful in a threaded situation (when you want to make sure
> you don't introduce race conditions), and its primary purpose is to stop
> you from making mistakes rather than to optimise.
>
> On top of this, the compiler is able to easily determine whether or not
> you are obeying the const declaration in the definition of a method, in
> that only const operations are used inside of it - how is the compiler
> supposed to verify if the second method *actually* reverses the first?
> Trust the developer? Because that's the situation we have without const
> already.
>
> On 21 Feb 2018 23:00, <jsaintmartin356@gmail.com> wrote:
>
>> One of my post on stackoverflow.com was said to have its place here.
>>
>> https://stackoverflow.com/questions/48915277/what-about-pseu
>> doconst-qualifier
>>
>> What do you think about my new pseudoconst qualifier ?
>> Expecting for your answer, (and/or possibly a job: long unemployed at the
>> moment)
>>
>> Jerome Saint-Martin,
>> Montrouge, France
>>
>>
>>
>> --
>> 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.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-
>> 18bf6ac873ee%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPu0dEAb9B%3DKmpiT8NwYd4xgSBuUWYcTRrui_Xj5K%2BWFA%40mail.gmail.com.

--001a114df622a373010565c16146
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Also note that you&#39;re including the allocation of 100=
0 size_ts in that first timer. I&#39;m not at my PC right now to test, but =
does moving the initialization of V to before the clock start significantly=
 reduce the discrepancy?</div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On 21 Feb 2018 23:23, &quot;Jake Arkinstall&quot; &lt;<a href=
=3D"mailto:jake.arkinstall@gmail.com">jake.arkinstall@gmail.com</a>&gt; wro=
te:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto=
">Welcome!<div dir=3D"auto"><br></div><div dir=3D"auto">Perhaps you can exp=
lain the consequences further, namely give an example of something useful t=
hat it would allow.<div dir=3D"auto"><br></div><div dir=3D"auto">One of the=
 benefits of having something const is not just that the data is unchanged =
at the END, but that it doesn&#39;t change AT ALL during execution. This is=
 often useful in a threaded situation (when you want to make sure you don&#=
39;t introduce race conditions), and its primary purpose is to stop you fro=
m making mistakes rather than to optimise.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">On top of this, the compiler is able to easily determine=
 whether or not you are obeying the const declaration in the definition of =
a method, in that only const operations are used inside of it - how is the =
compiler supposed to verify if the second method <i>actually</i> reverses t=
he first? Trust the developer? Because that&#39;s the situation we have wit=
hout const already.</div></div></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On 21 Feb 2018 23:00,  &lt;<a href=3D"mailto:jsaintmart=
in356@gmail.com" target=3D"_blank">jsaintmartin356@gmail.com</a>&gt; wrote:=
<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On=
e of my post on <a href=3D"http://stackoverflow.com" target=3D"_blank">stac=
koverflow.com</a> was said to have its place here.<br><br><a href=3D"https:=
//stackoverflow.com/questions/48915277/what-about-pseudoconst-qualifier" ta=
rget=3D"_blank">https://stackoverflow.com/ques<wbr>tions/48915277/what-abou=
t-pseu<wbr>doconst-qualifier</a><br><br>What do you think about my new pseu=
doconst qualifier ? <br>Expecting for your answer, (and/or possibly a job: =
long unemployed at the moment)<br><br>Jerome Saint-Martin, <br>Montrouge, F=
rance<br><br>
       =20




           =20
           =20
<table><tbody><tr><td class=3D"m_-4099535375917004503m_8366955350456529130v=
otecell"><br></td><td class=3D"m_-4099535375917004503m_8366955350456529130p=
ostcell"><br></td></tr></tbody></table></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/f202=
be10-efb5-4f1a-ab6a-<wbr>18bf6ac873ee%40isocpp.org</a>.<br>
</blockquote></div></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPu0dEAb9B%3DKmpiT8NwYd4xgSBu=
UWYcTRrui_Xj5K%2BWFA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPu=
0dEAb9B%3DKmpiT8NwYd4xgSBuUWYcTRrui_Xj5K%2BWFA%40mail.gmail.com</a>.<br />

--001a114df622a373010565c16146--

.

--001a114960fc6b55cd0565c2c17d
Content-Type: text/plain; charset="UTF-8"

Further to my previous reply, I have written a rough version which should
be a bit more reliable (it isn't perfect, but should suffice for the
purpose of demonstration).

Inserting to std::cout (especially with a flush, i.e. as std::endl) can
play hell during the benchmark stage, so I have removed that. I have also
ensured that each benchmark minimally interferes with the others (by
scoping each out), extracted the time for the copying operation (as it
isn't valid to compare Vec::Vec() and Vec::Vec(const Vec&) - the two do
different things). Most importantly, the methods are run many times to
minimise statistical error and to try and iron out the impact of e.g.
dynamic frequency scaling.

#include <vector>
>
> #include <iostream>#include <algorithm>#include <functional>
>
> class Vec {public :
>     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
>     Vec (const Vec& v) : val_ (v.val_) {}
>     //couple of const opposite methods
>     void inc () {
>         std::for_each (val_.begin (), val_.end (), [] (size_t&s) {++s;});
>     }
>     void dec () {
>         std::for_each (val_.begin (), val_.end (), [] (size_t&s) {--s;});
>     }
>     void next2const () const {
>         Vec v (*this);
>         v.inc();
>         v.dec();
>     }
>     void next2pseudoconst() { //pseudo const method
>         inc ();
>         dec ();
>     }private :
>     std::vector<size_t> val_;
> };
> template<typename T>void crude_bench(T func, const size_t& count){
>     clock_t t = clock();
>     for(size_t i = 0; i < count; ++i){
>         func();
>     }
>     double duration{(clock() - t) / (double)count};
>     std::cout << duration << " ticks per run\n";
> }
> int main (int argc, char* argv []) {
>     auto count = 100000ul;
>     {
>         Vec v;
>         std::cout << "Copying: " << std::flush;
>         crude_bench(
>             std::bind([](Vec& v){ Vec other(v); }, v),
>             count
>         );
>     }
>     {
>         Vec v;
>         std::cout << "next2const: " << std::flush;
>         crude_bench(
>             std::bind(&Vec::next2const, v),
>             count
>         );
>     }
>     {
>         Vec v;
>         std::cout << "next2pseudoconst: " << std::flush;
>         crude_bench(
>             std::bind(&Vec::next2pseudoconst, v),
>             count
>         );
>     }
>     return 0;
> }
>
>
Without any optimisation on GCC, what I get is:

Copying: 0.31656 ticks per run
> next2const: 18.2984 ticks per run
> next2pseudoconst: 18.0145 ticks per run
>

Note that the *next2const *duration minus the *Copying* duration (which is
necessary to compare the two) is less than the *next2pseudoconst* duration
- but not by any meaningful amount. *There's a good reason for that* -
const doesn't perform any kind of magic here. It wouldn't make sense if it
did, *although* the Vec method is const, *it still creates another Vec and
performs a non-const operation upon THAT*.

Just as a sidenote as to the importance of running benchmarks over many
iterations. I have run the above benchmark over iterations increasing in
powers of 2, and charted the ticks per iteration for GCC7.3.1 unoptimised
and GCC7.3.1 with -O3. I'm not sure if I can attach the charts to the group
via email attachment, so I have uploaded them here:
https://imgur.com/a/Mj2P6 - the two lines correspond with
ticks(next2pseudoconst) and ticks(next2const)-ticks(copying) - You can see
the negative tick count of (next2const - copying) in the first iteration,
which should go some way to tell you how unreliable a single run benchmark
is.

Regards,
Jake Arkinstall

On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall <jake.arkinstall@gmail.com
> wrote:

> Also note that you're including the allocation of 1000 size_ts in that
> first timer. I'm not at my PC right now to test, but does moving the
> initialization of V to before the clock start significantly reduce the
> discrepancy?
>
> On 21 Feb 2018 23:23, "Jake Arkinstall" <jake.arkinstall@gmail.com> wrote:
>
>> Welcome!
>>
>> Perhaps you can explain the consequences further, namely give an example
>> of something useful that it would allow.
>>
>> One of the benefits of having something const is not just that the data
>> is unchanged at the END, but that it doesn't change AT ALL during
>> execution. This is often useful in a threaded situation (when you want to
>> make sure you don't introduce race conditions), and its primary purpose is
>> to stop you from making mistakes rather than to optimise.
>>
>> On top of this, the compiler is able to easily determine whether or not
>> you are obeying the const declaration in the definition of a method, in
>> that only const operations are used inside of it - how is the compiler
>> supposed to verify if the second method *actually* reverses the first?
>> Trust the developer? Because that's the situation we have without const
>> already.
>>
>> On 21 Feb 2018 23:00, <jsaintmartin356@gmail.com> wrote:
>>
>>> One of my post on stackoverflow.com was said to have its place here.
>>>
>>> https://stackoverflow.com/questions/48915277/what-about-pseu
>>> doconst-qualifier
>>>
>>> What do you think about my new pseudoconst qualifier ?
>>> Expecting for your answer, (and/or possibly a job: long unemployed at
>>> the moment)
>>>
>>> Jerome Saint-Martin,
>>> Montrouge, France
>>>
>>>
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6
>>> ac873ee%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNyfhb7L2dk4N0pyu3d%3DT7q1L5m%2BnOU2yG05XXj4dH_vg%40mail.gmail.com.

--001a114960fc6b55cd0565c2c17d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Further to my previous reply, I have written a rough =
version which should be a bit more reliable (it isn&#39;t perfect, but shou=
ld suffice for the purpose of demonstration).<br><br>Inserting to std::cout=
 (especially with a flush, i.e. as std::endl) can play hell during the benc=
hmark stage, so I have removed that. I have also ensured that each benchmar=
k minimally interferes with the others (by scoping each out), extracted the=
 time for the copying operation (as it isn&#39;t valid to compare Vec::Vec(=
) and Vec::Vec(const Vec&amp;) - the two do different things). Most importa=
ntly, the methods are run many times to minimise statistical error and to t=
ry and iron out the impact of e.g. dynamic frequency scaling.<br></div><div=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><span style=3D"color=
:rgb(76,131,23)">#include &lt;vector&gt;</span>
<pre style=3D"margin:0px;line-height:125%"><span style=3D"color:rgb(76,131,=
23)">#include &lt;iostream&gt;</span>
<span style=3D"color:rgb(76,131,23)">#include &lt;algorithm&gt;</span>
<span style=3D"color:rgb(76,131,23)">#include &lt;functional&gt;</span>


<span style=3D"color:rgb(0,0,170)">class</span> <span style=3D"color:rgb(0,=
170,0);text-decoration:underline">Vec</span> {
<span style=3D"color:rgb(0,0,170)">public</span> :=20
    Vec () : val_ (std::vector&lt;<span style=3D"color:rgb(0,170,170)">size=
_t</span>&gt; (<span style=3D"color:rgb(0,153,153)">1000</span>, <span styl=
e=3D"color:rgb(0,153,153)">0</span>)) {}
    Vec (<span style=3D"color:rgb(0,0,170)">const</span> Vec&amp; v) : val_=
 (v.val_) {}
    <span style=3D"color:rgb(170,170,170);font-style:italic">//couple of co=
nst opposite methods</span>
    <span style=3D"color:rgb(0,170,170)">void</span> inc () {
        std::for_each (val_.begin (), val_.end (), [] (<span style=3D"color=
:rgb(0,170,170)">size_t</span>&amp;s) {++s;});
    }
    <span style=3D"color:rgb(0,170,170)">void</span> dec () {
        std::for_each (val_.begin (), val_.end (), [] (<span style=3D"color=
:rgb(0,170,170)">size_t</span>&amp;s) {--s;});
    }   =20
    <span style=3D"color:rgb(0,170,170)">void</span> next2const () <span st=
yle=3D"color:rgb(0,0,170)">const</span> {
        Vec v (*<span style=3D"color:rgb(0,0,170)">this</span>);
        v.inc();
        v.dec();
    }
    <span style=3D"color:rgb(0,170,170)">void</span> next2pseudoconst() { <=
span style=3D"color:rgb(170,170,170);font-style:italic">//pseudo const meth=
od</span>
        inc ();
        dec ();
    }
<span style=3D"color:rgb(0,0,170)">private</span> :
    std::vector&lt;<span style=3D"color:rgb(0,170,170)">size_t</span>&gt; v=
al_;
};

<span style=3D"color:rgb(0,0,170)">template</span>&lt;<span style=3D"color:=
rgb(0,0,170)">typename</span> T&gt;
<span style=3D"color:rgb(0,170,170)">void</span> crude_bench(T func, <span =
style=3D"color:rgb(0,0,170)">const</span> <span style=3D"color:rgb(0,170,17=
0)">size_t</span>&amp; count){
    <span style=3D"color:rgb(0,170,170)">clock_t</span> t =3D clock();
    <span style=3D"color:rgb(0,0,170)">for</span>(<span style=3D"color:rgb(=
0,170,170)">size_t</span> i =3D <span style=3D"color:rgb(0,153,153)">0</spa=
n>; i &lt; count; ++i){
        func();
    }
    <span style=3D"color:rgb(0,170,170)">double</span> duration{(clock() - =
t) / (<span style=3D"color:rgb(0,170,170)">double</span>)count};
    std::cout &lt;&lt; duration &lt;&lt; <span style=3D"color:rgb(170,85,0)=
">&quot; ticks per run\n&quot;</span>;
}

<span style=3D"color:rgb(0,170,170)">int</span> main (<span style=3D"color:=
rgb(0,170,170)">int</span> argc, <span style=3D"color:rgb(0,170,170)">char<=
/span>* argv []) {
    <span style=3D"color:rgb(0,0,170)">auto</span> count =3D <span style=3D=
"color:rgb(0,153,153)">100000ul</span>;
    {
        Vec v;
        std::cout &lt;&lt; <span style=3D"color:rgb(170,85,0)">&quot;Copyin=
g: &quot;</span> &lt;&lt; std::flush;
        crude_bench(
            std::bind([](Vec&amp; v){ Vec other(v); }, v),
            count
        );
    }
    {
        Vec v;
        std::cout &lt;&lt; <span style=3D"color:rgb(170,85,0)">&quot;next2c=
onst: &quot;</span> &lt;&lt; std::flush;
        crude_bench(
            std::bind(&amp;Vec::next2const, v),
            count               =20
        );
    }
    {
        Vec v;
        std::cout &lt;&lt; <span style=3D"color:rgb(170,85,0)">&quot;next2p=
seudoconst: &quot;</span> &lt;&lt; std::flush;
        crude_bench(
            std::bind(&amp;Vec::next2pseudoconst, v),
            count
        );
    }
    <span style=3D"color:rgb(0,0,170)">return</span> <span style=3D"color:r=
gb(0,153,153)">0</span>;
}</pre></blockquote><br></div>Without any optimisation on GCC, what I get i=
s:<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Copying: 0.3165=
6 ticks per run<br>next2const: 18.2984 ticks per run<br>next2pseudoconst: 1=
8.0145 ticks per run<br></blockquote><div><br></div><div>Note that the <i>n=
ext2const </i>duration minus the <i>Copying</i> duration (which is necessar=
y to compare the two) is less than the <i>next2pseudoconst</i> duration - b=
ut not by any meaningful amount. <u>There&#39;s a good reason for that</u> =
- const doesn&#39;t perform any kind of magic here. It wouldn&#39;t make se=
nse if it did, <i>although</i> the Vec method is const, <u>it still creates=
 another Vec and performs a non-const operation upon <b>THAT</b></u>.<br><b=
r></div><div>Just as a sidenote as to the importance of running benchmarks =
over many iterations. I have run the above benchmark over iterations increa=
sing in powers of 2, and charted the ticks per iteration for GCC7.3.1 unopt=
imised and GCC7.3.1 with -O3. I&#39;m not sure if I can attach the charts t=
o the group via email attachment, so I have uploaded them here: <a href=3D"=
https://imgur.com/a/Mj2P6">https://imgur.com/a/Mj2P6</a> - the two lines co=
rrespond with ticks(next2pseudoconst) and ticks(next2const)-ticks(copying) =
- You can see the negative tick count of (next2const - copying) in the firs=
t iteration, which should go some way to tell you how unreliable a single r=
un benchmark is.<br></div><div><br></div><div>Regards,<br></div><div>Jake A=
rkinstall<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.ar=
kinstall@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"auto">Also note that you&#39;re including the allocation of 100=
0 size_ts in that first timer. I&#39;m not at my PC right now to test, but =
does moving the initialization of V to before the clock start significantly=
 reduce the discrepancy?</div><div class=3D"HOEnZb"><div class=3D"h5"><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 21 Feb 2018 23:23, =
&quot;Jake Arkinstall&quot; &lt;<a href=3D"mailto:jake.arkinstall@gmail.com=
" target=3D"_blank">jake.arkinstall@gmail.com</a>&gt; wrote:<br type=3D"att=
ribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Welcome!<div dir=
=3D"auto"><br></div><div dir=3D"auto">Perhaps you can explain the consequen=
ces further, namely give an example of something useful that it would allow=
..<div dir=3D"auto"><br></div><div dir=3D"auto">One of the benefits of havin=
g something const is not just that the data is unchanged at the END, but th=
at it doesn&#39;t change AT ALL during execution. This is often useful in a=
 threaded situation (when you want to make sure you don&#39;t introduce rac=
e conditions), and its primary purpose is to stop you from making mistakes =
rather than to optimise.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>On top of this, the compiler is able to easily determine whether or not yo=
u are obeying the const declaration in the definition of a method, in that =
only const operations are used inside of it - how is the compiler supposed =
to verify if the second method <i>actually</i> reverses the first? Trust th=
e developer? Because that&#39;s the situation we have without const already=
..</div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On 21 Feb 2018 23:00,  &lt;<a href=3D"mailto:jsaintmartin356@gmail.com" t=
arget=3D"_blank">jsaintmartin356@gmail.com</a>&gt; wrote:<br type=3D"attrib=
ution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">One of my post on <a=
 href=3D"http://stackoverflow.com" target=3D"_blank">stackoverflow.com</a> =
was said to have its place here.<br><br><a href=3D"https://stackoverflow.co=
m/questions/48915277/what-about-pseudoconst-qualifier" target=3D"_blank">ht=
tps://stackoverflow.com/ques<wbr>tions/48915277/what-about-pseu<wbr>doconst=
-qualifier</a><br><br>What do you think about my new pseudoconst qualifier =
? <br>Expecting for your answer, (and/or possibly a job: long unemployed at=
 the moment)<br><br>Jerome Saint-Martin, <br>Montrouge, France<br><br>
       =20




           =20
           =20
<table><tbody><tr><td class=3D"m_-8771373518475847453m_-4099535375917004503=
m_8366955350456529130votecell"><br></td><td class=3D"m_-8771373518475847453=
m_-4099535375917004503m_8366955350456529130postcell"><br></td></tr></tbody>=
</table></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f202be10-efb5-4f1a-ab6a-18bf6ac873ee%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/f202=
be10-efb5-4f1a-ab6a-18bf6<wbr>ac873ee%40isocpp.org</a>.<br>
</blockquote></div></div>
</blockquote></div></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNyfhb7L2dk4N0pyu3d%3DT7q1L5m=
%2BnOU2yG05XXj4dH_vg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNy=
fhb7L2dk4N0pyu3d%3DT7q1L5m%2BnOU2yG05XXj4dH_vg%40mail.gmail.com</a>.<br />

--001a114960fc6b55cd0565c2c17d--

.

--=-dBJgX8hIM8CGNW7t37Lw
Content-Type: text/plain; charset="UTF-8"

On Thu, 2018-02-22 at 01:13 +0000, Jake Arkinstall wrote:
> Further to my previous reply, I have written a rough version which
> should be a bit more reliable (it isn't perfect, but should suffice
> for the purpose of demonstration).


C++ already provides the mutable keyword. The Vec class in question can
be written in terms of it:

class Vec {
public :
    Vec () : val_ (std::vector<size_t> (1000, 0)) {}

    // copy constructor is un-necessary. The compiler builds a correct
    // one.

    //actual const method
    void next2() const {
        inc ();
        dec ();
    }

    // these are now const
    void inc () const {
        std::for_each (val_.begin (), val_.end (),
                       [] (size_t&s) {++s;});
    }

    void dec () const {
        std::for_each (val_.begin (), val_.end (),
                       [] (size_t&s) {--s;});
    }

private :
    // mutable members can be modified when the object is accessed
    // through a const reference
    mutable std::vector<size_t> val_;
};




>
> Inserting to std::cout (especially with a flush, i.e. as std::endl)
> can play hell during the benchmark stage, so I have removed that. I
> have also ensured that each benchmark minimally interferes with the
> others (by scoping each out), extracted the time for the copying
> operation (as it isn't valid to compare Vec::Vec() and Vec::Vec(const
> Vec&) - the two do different things). Most importantly, the methods
> are run many times to minimise statistical error and to try and iron
> out the impact of e.g. dynamic frequency scaling.
>
> > #include <vector>
> > #include <iostream>
> > #include <algorithm>
> > #include <functional>
> >
> >
> > class Vec {
> > public :
> >     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
> >     Vec (const Vec& v) : val_ (v.val_) {}
> >     //couple of const opposite methods
> >     void inc () {
> >         std::for_each (val_.begin (), val_.end (), [] (size_t&s)
> > {++s;});
> >     }
> >     void dec () {
> >         std::for_each (val_.begin (), val_.end (), [] (size_t&s) {-
> > -s;});
> >     }
> >     void next2const () const {
> >         Vec v (*this);
> >         v.inc();
> >         v.dec();
> >     }
> >     void next2pseudoconst() { //pseudo const method
> >         inc ();
> >         dec ();
> >     }
> > private :
> >     std::vector<size_t> val_;
> > };
> >
> > template<typename T>
> > void crude_bench(T func, const size_t& count){
> >     clock_t t = clock();
> >     for(size_t i = 0; i < count; ++i){
> >         func();
> >     }
> >     double duration{(clock() - t) / (double)count};
> >     std::cout << duration << " ticks per run\n";
> > }
> >
> > int main (int argc, char* argv []) {
> >     auto count = 100000ul;
> >     {
> >         Vec v;
> >         std::cout << "Copying: " << std::flush;
> >         crude_bench(
> >             std::bind([](Vec& v){ Vec other(v); }, v),
> >             count
> >         );
> >     }
> >     {
> >         Vec v;
> >         std::cout << "next2const: " << std::flush;
> >         crude_bench(
> >             std::bind(&Vec::next2const, v),
> >             count
> >         );
> >     }
> >     {
> >         Vec v;
> >         std::cout << "next2pseudoconst: " << std::flush;
> >         crude_bench(
> >             std::bind(&Vec::next2pseudoconst, v),
> >             count
> >         );
> >     }
> >     return 0;
> > }
> >
>
> Without any optimisation on GCC, what I get is:
>
> > Copying: 0.31656 ticks per run
> > next2const: 18.2984 ticks per run
> > next2pseudoconst: 18.0145 ticks per run
>
> Note that the next2const duration minus the Copying duration (which
> is necessary to compare the two) is less than the next2pseudoconst
> duration - but not by any meaningful amount. There's a good reason
> for that - const doesn't perform any kind of magic here. It wouldn't
> make sense if it did, although the Vec method is const, it still
> creates another Vec and performs a non-const operation upon THAT.
>
> Just as a sidenote as to the importance of running benchmarks over
> many iterations. I have run the above benchmark over iterations
> increasing in powers of 2, and charted the ticks per iteration for
> GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I'm not sure if I can
> attach the charts to the group via email attachment, so I have
> uploaded them here: https://imgur.com/a/Mj2P6 - the two lines
> correspond with ticks(next2pseudoconst) and ticks(next2const)-
> ticks(copying) - You can see the negative tick count of (next2const -
> copying) in the first iteration, which should go some way to tell you
> how unreliable a single run benchmark is.
>
> Regards,
> Jake Arkinstall
>
> On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall <jake.arkinstall@gm
> ail.com> wrote:
> > Also note that you're including the allocation of 1000 size_ts in
> > that first timer. I'm not at my PC right now to test, but does
> > moving the initialization of V to before the clock start
> > significantly reduce the discrepancy?
> >
> > On 21 Feb 2018 23:23, "Jake Arkinstall" <jake.arkinstall@gmail.com>
> > wrote:
> > > Welcome!
> > >
> > > Perhaps you can explain the consequences further, namely give an
> > > example of something useful that it would allow.
> > >
> > > One of the benefits of having something const is not just that
> > > the data is unchanged at the END, but that it doesn't change AT
> > > ALL during execution. This is often useful in a threaded
> > > situation (when you want to make sure you don't introduce race
> > > conditions), and its primary purpose is to stop you from making
> > > mistakes rather than to optimise.
> > >
> > > On top of this, the compiler is able to easily determine whether
> > > or not you are obeying the const declaration in the definition of
> > > a method, in that only const operations are used inside of it -
> > > how is the compiler supposed to verify if the second method
> > > actually reverses the first? Trust the developer? Because that's
> > > the situation we have without const already.
> > >
> > > On 21 Feb 2018 23:00, <jsaintmartin356@gmail.com> wrote:
> > > > One of my post on stackoverflow.com was said to have its place
> > > > here.
> > > >
> > > > https://stackoverflow.com/questions/48915277/what-about-pseudoc
> > > > onst-qualifier
> > > >
> > > > What do you think about my new pseudoconst qualifier ?
> > > > Expecting for your answer, (and/or possibly a job: long
> > > > unemployed at the moment)
> > > >
> > > > Jerome Saint-Martin,
> > > > Montrouge, France
> > > >
> > > >
> > > >

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gmail.com.

--=-dBJgX8hIM8CGNW7t37Lw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE3RJb20ryY2ALx0Tw6HZ1IvK3CgsFAlqObHMACgkQ6HZ1IvK3
CgvghA//dbNmm5Gkh7Ttmu8npI84RxHICcuBBXGcUDIxgBS7z3oupFjA8jqiBQnu
TS0sQEyb+Po7Q0xlbzCWlw8UicrxFAAvwPfdCobi/5yM4DRKql2+qdzwJqhpCxCy
GfqQP/FFGnZ5qo0IpomXKSOjwXBunYNC4cpI5ZEfeBh5h9jqc3D8aiTIdan7oTQy
ei3AZuw2uSLh22TPzVv+Jjy9LdphVrT3IggV0q4F6f1oNa7w6yAb/ah4Du2JyN0V
WdUJxTj6C53CdSmXc3wUB4Xv/ILeCNuVZKGIftemEuckROjW4tjLyHdCACaXiP+D
uVYOa9MNzhbH/hUDXfO75xHZipqvE+u2qnMKdW/ZN8yTwqoUOj/H8cSw4NTtaSFA
zwtzBbpBbi/UqGD4CcImGESmNlLAoMDW/oFxzUpQ+UHtwfMb2rltmZVOyZ1svspE
dD9IELRWSTCpZgh6KaLbL9JxzlEiyFvBP+ROeZgSJrnDwc0lK9FFtRf3iX9epOy1
m9BgnwsVDQefGbzb91eRSU/AhJmSEdJ2p+zUG/QfiiYvKaHBhlXikvEVc1aEPzKi
WRjwLuHpSm2IrI58bl5BJ+YKc7lcrCqQ1Oa8O+mbuKoOGpPpbtoJ5Kfg5YBDmc67
xBVRb/8EAqUrIiZFUfq/7MSF0+lZZ/+etKkMaxGbPGftGagsVsI=
=X2X9
-----END PGP SIGNATURE-----

--=-dBJgX8hIM8CGNW7t37Lw--


.

------=_Part_1755_809804488.1519291156596
Content-Type: multipart/alternative;
 boundary="----=_Part_1756_722067670.1519291156596"

------=_Part_1756_722067670.1519291156596
Content-Type: text/plain; charset="UTF-8"

On Thursday, 22 February 2018 14:13:50 UTC+13, Jake Arkinstall wrote:
>
> Further to my previous reply, I have written a rough version which should
> be a bit more reliable (it isn't perfect, but should suffice for the
> purpose of demonstration).
>

Here's a version on
quick-bench.com: http://quick-bench.com/3CuEaO513mfIZmS6Ca1rrC_DnII

In the const version you don't need to do the decrement operation so I
commented it out. The const version is a lot faster than the pseudo-const
version with that change.

Cheers,
Toby.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/682b6197-db8a-41c1-9713-8a8492541e74%40isocpp.org.

------=_Part_1756_722067670.1519291156596
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, 22 February 2018 14:13:50 UTC+13, Jake Arkins=
tall  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>Further to my previous reply, I have written a rough version which shou=
ld be a bit more reliable (it isn&#39;t perfect, but should suffice for the=
 purpose of demonstration).<br></div></div></blockquote><div><br></div><div=
>Here&#39;s a version on quick-bench.com:=C2=A0http://quick-bench.com/3CuEa=
O513mfIZmS6Ca1rrC_DnII<br></div><div><br></div><div>In the const version yo=
u don&#39;t need to do the decrement operation so I commented it out. The c=
onst version is a lot faster than the pseudo-const version with that change=
..</div><div><br></div><div>Cheers,</div><div>Toby.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/682b6197-db8a-41c1-9713-8a8492541e74%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/682b6197-db8a-41c1-9713-8a8492541e74=
%40isocpp.org</a>.<br />

------=_Part_1756_722067670.1519291156596--

------=_Part_1755_809804488.1519291156596--

.

--f403045d9a50d085e90565ca2399
Content-Type: text/plain; charset="UTF-8"

Dec was not in const version.

On Thu, Feb 22, 2018 at 10:19 AM, Toby Allsopp <toby@mi6.gen.nz> wrote:

> On Thursday, 22 February 2018 14:13:50 UTC+13, Jake Arkinstall wrote:
>>
>> Further to my previous reply, I have written a rough version which should
>> be a bit more reliable (it isn't perfect, but should suffice for the
>> purpose of demonstration).
>>
>
> Here's a version on quick-bench.com: http://quick-bench.com/
> 3CuEaO513mfIZmS6Ca1rrC_DnII
>
> In the const version you don't need to do the decrement operation so I
> commented it out. The const version is a lot faster than the pseudo-const
> version with that change.
>
> Cheers,
> Toby.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/682b6197-db8a-41c1-
> 9713-8a8492541e74%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/682b6197-db8a-41c1-9713-8a8492541e74%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEYmV5sAiBFW6N%3DffOreRbehZ2mByfwfZQK57A_-Xh9hPw%40mail.gmail.com.

--f403045d9a50d085e90565ca2399
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dec was not in const version.<br></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Thu, Feb 22, 2018 at 10:19 AM, To=
by Allsopp <span dir=3D"ltr">&lt;<a href=3D"mailto:toby@mi6.gen.nz" target=
=3D"_blank">toby@mi6.gen.nz</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><span class=3D"">On Thursday, 22 February 2018 14=
:13:50 UTC+13, Jake Arkinstall  wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>Further to my previous reply, I have written a rou=
gh version which should be a bit more reliable (it isn&#39;t perfect, but s=
hould suffice for the purpose of demonstration).<br></div></div></blockquot=
e><div><br></div></span><div>Here&#39;s a version on <a href=3D"http://quic=
k-bench.com" target=3D"_blank">quick-bench.com</a>:=C2=A0<a href=3D"http://=
quick-bench.com/3CuEaO513mfIZmS6Ca1rrC_DnII" target=3D"_blank">http://quick=
-<wbr>bench.com/<wbr>3CuEaO513mfIZmS6Ca1rrC_DnII</a><br></div><div><br></di=
v><div>In the const version you don&#39;t need to do the decrement operatio=
n so I commented it out. The const version is a lot faster than the pseudo-=
const version with that change.</div><div><br></div><div>Cheers,</div><div>=
Toby.</div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/682b6197-db8a-41c1-9713-8a8492541e74%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/682b=
6197-db8a-41c1-<wbr>9713-8a8492541e74%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC4OUEYmV5sAiBFW6N%3DffOreRbehZ2mByf=
wfZQK57A_-Xh9hPw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEYmV5sAiB=
FW6N%3DffOreRbehZ2mByfwfZQK57A_-Xh9hPw%40mail.gmail.com</a>.<br />

--f403045d9a50d085e90565ca2399--

.

--001a114df622831f590565cd0bc6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Of course. But you cannot make claims about speed benefits if you dont make
the two do the same thing - at that point the difference is arbitrary; it
depends on the exact case you're dealing with. This is why the reversal is
in there, because you had claims about speed benefits of pseudoconst that
don't hold up.

My point was too break it down and show you that they're doing exactly the
same thing except that one copies first. Of course, if the const version
only needs to do half of the processing then it's just down to being
efficiently copyable.

On 22 Feb 2018 10:02, "J=C3=A9r=C3=B4me Saint-Martin" <jsaintmartin356@gmai=
l.com>
wrote:

> Dec was not in const version.
>
> On Thu, Feb 22, 2018 at 10:19 AM, Toby Allsopp <toby@mi6.gen.nz> wrote:
>
>> On Thursday, 22 February 2018 14:13:50 UTC+13, Jake Arkinstall wrote:
>>>
>>> Further to my previous reply, I have written a rough version which
>>> should be a bit more reliable (it isn't perfect, but should suffice for=
 the
>>> purpose of demonstration).
>>>
>>
>> Here's a version on quick-bench.com: http://quick-
>> bench.com/3CuEaO513mfIZmS6Ca1rrC_DnII
>>
>> In the const version you don't need to do the decrement operation so I
>> commented it out. The const version is a lot faster than the pseudo-cons=
t
>> version with that change.
>>
>> Cheers,
>> Toby.
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/682b6197-db8a-41c1-9713-
>> 8a8492541e74%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/682b6197-d=
b8a-41c1-9713-8a8492541e74%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC4OUEYmV5sAiBFW6N%
> 3DffOreRbehZ2mByfwfZQK57A_-Xh9hPw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEYmV5=
sAiBFW6N%3DffOreRbehZ2mByfwfZQK57A_-Xh9hPw%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAC%2B0CCO0gYiAoj9eJkx0i8G-vUaCQLO5QM6Ti9mdDEHmM=
h6fBA%40mail.gmail.com.

--001a114df622831f590565cd0bc6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Of course. But you cannot make claims about speed benefit=
s if you dont make the two do the same thing - at that point the difference=
 is arbitrary; it depends on the exact case you&#39;re dealing with. This i=
s why the reversal is in there, because you had claims about speed benefits=
 of pseudoconst that don&#39;t hold up.<div dir=3D"auto"><div dir=3D"auto">=
<br></div><div dir=3D"auto">My point was too break it down and show you tha=
t they&#39;re doing exactly the same thing except that one copies first. Of=
 course, if the const version only needs to do half of the processing then =
it&#39;s just down to being efficiently copyable.</div></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On 22 Feb 2018 10:02, &qu=
ot;J=C3=A9r=C3=B4me Saint-Martin&quot; &lt;<a href=3D"mailto:jsaintmartin35=
6@gmail.com">jsaintmartin356@gmail.com</a>&gt; wrote:<br type=3D"attributio=
n"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Dec was not in const ver=
sion.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
 Thu, Feb 22, 2018 at 10:19 AM, Toby Allsopp <span dir=3D"ltr">&lt;<a href=
=3D"mailto:toby@mi6.gen.nz" target=3D"_blank">toby@mi6.gen.nz</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Thursd=
ay, 22 February 2018 14:13:50 UTC+13, Jake Arkinstall  wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div>Further to my previous repl=
y, I have written a rough version which should be a bit more reliable (it i=
sn&#39;t perfect, but should suffice for the purpose of demonstration).<br>=
</div></div></blockquote><div><br></div></span><div>Here&#39;s a version on=
 <a href=3D"http://quick-bench.com" target=3D"_blank">quick-bench.com</a>:=
=C2=A0<a href=3D"http://quick-bench.com/3CuEaO513mfIZmS6Ca1rrC_DnII" target=
=3D"_blank">http://quick-<wbr>bench.com/3CuEaO513mfIZmS6Ca1r<wbr>rC_DnII</a=
><br></div><div><br></div><div>In the const version you don&#39;t need to d=
o the decrement operation so I commented it out. The const version is a lot=
 faster than the pseudo-const version with that change.</div><div><br></div=
><div>Cheers,</div><div>Toby.</div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/682b6197-db8a-41c1-9713-8a8492541e74%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/682b=
6197-db8a-41c1-9713-<wbr>8a8492541e74%40isocpp.org</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC4OUEYmV5sAiBFW6N%3DffOreRbehZ2mByf=
wfZQK57A_-Xh9hPw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAC4OUEYmV5sAiBFW6N%<wbr>3DffOreRbehZ2mByfwfZQK57A_-<wbr>X=
h9hPw%40mail.gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO0gYiAoj9eJkx0i8G-vUaCQLO5QM=
6Ti9mdDEHmMh6fBA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO0gYiA=
oj9eJkx0i8G-vUaCQLO5QM6Ti9mdDEHmMh6fBA%40mail.gmail.com</a>.<br />

--001a114df622831f590565cd0bc6--

.

------=_Part_2063_1433163278.1519306795112
Content-Type: multipart/alternative;
 boundary="----=_Part_2064_100241982.1519306795112"

------=_Part_2064_100241982.1519306795112
Content-Type: text/plain; charset="UTF-8"

what if a pseudoconst method isnt noexcept? allowing them would introduce
tons of undefined behaviors

>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8f932ee4-d7fb-44e4-81c1-587f9e5f4a03%40isocpp.org.

------=_Part_2064_100241982.1519306795112
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">what if a pseudoconst method isnt noexcept? allowing them =
would introduce tons of undefined behaviors<br><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><table><tbody><tr><td></td><td><br></td><=
/tr></tbody></table></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8f932ee4-d7fb-44e4-81c1-587f9e5f4a03%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8f932ee4-d7fb-44e4-81c1-587f9e5f4a03=
%40isocpp.org</a>.<br />

------=_Part_2064_100241982.1519306795112--

------=_Part_2063_1433163278.1519306795112--

.

------=_Part_2270_703562112.1519306881188
Content-Type: multipart/alternative;
 boundary="----=_Part_2271_1192827049.1519306881188"

------=_Part_2271_1192827049.1519306881188
Content-Type: text/plain; charset="UTF-8"

what if a pseudoconst method isnt noexcept? allowing them would introduce
tons of undefined behaviors
>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e087e1b8-3451-4b08-8674-7ed6f97a6803%40isocpp.org.

------=_Part_2271_1192827049.1519306881188
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">what if a pseudoconst method isnt noexcept? allowing them =
would introduce tons of undefined behaviors<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><table><tbody><tr><td><br></td><td></td></tr>=
</tbody></table></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e087e1b8-3451-4b08-8674-7ed6f97a6803%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e087e1b8-3451-4b08-8674-7ed6f97a6803=
%40isocpp.org</a>.<br />

------=_Part_2271_1192827049.1519306881188--

------=_Part_2270_703562112.1519306881188--

.

--001a11453a726217b60565cd3f1c
Content-Type: text/plain; charset="UTF-8"

It's better to have the method as non-const and deal with the consequences,
if possible, than to make a vital class data member mutable. The former
does not trick the user into creating unwanted side-effects, but the latter
can. The former is honest, the latter is a trickster.

There's certainly a place for mutable, but not here IMO.


On 22 Feb 2018 07:08, "Richard Hodges" <hodges.r@gmail.com> wrote:

On Thu, 2018-02-22 at 01:13 +0000, Jake Arkinstall wrote:
> Further to my previous reply, I have written a rough version which
> should be a bit more reliable (it isn't perfect, but should suffice
> for the purpose of demonstration).


C++ already provides the mutable keyword. The Vec class in question can
be written in terms of it:

class Vec {
public :
    Vec () : val_ (std::vector<size_t> (1000, 0)) {}

    // copy constructor is un-necessary. The compiler builds a correct
    // one.

    //actual const method
    void next2() const {
        inc ();
        dec ();
    }

    // these are now const
    void inc () const {
        std::for_each (val_.begin (), val_.end (),
                       [] (size_t&s) {++s;});
    }

    void dec () const {
        std::for_each (val_.begin (), val_.end (),
                       [] (size_t&s) {--s;});
    }

private :
    // mutable members can be modified when the object is accessed
    // through a const reference
    mutable std::vector<size_t> val_;
};




>
> Inserting to std::cout (especially with a flush, i.e. as std::endl)
> can play hell during the benchmark stage, so I have removed that. I
> have also ensured that each benchmark minimally interferes with the
> others (by scoping each out), extracted the time for the copying
> operation (as it isn't valid to compare Vec::Vec() and Vec::Vec(const
> Vec&) - the two do different things). Most importantly, the methods
> are run many times to minimise statistical error and to try and iron
> out the impact of e.g. dynamic frequency scaling.
>
> > #include <vector>
> > #include <iostream>
> > #include <algorithm>
> > #include <functional>
> >
> >
> > class Vec {
> > public :
> >     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
> >     Vec (const Vec& v) : val_ (v.val_) {}
> >     //couple of const opposite methods
> >     void inc () {
> >         std::for_each (val_.begin (), val_.end (), [] (size_t&s)
> > {++s;});
> >     }
> >     void dec () {
> >         std::for_each (val_.begin (), val_.end (), [] (size_t&s) {-
> > -s;});
> >     }
> >     void next2const () const {
> >         Vec v (*this);
> >         v.inc();
> >         v.dec();
> >     }
> >     void next2pseudoconst() { //pseudo const method
> >         inc ();
> >         dec ();
> >     }
> > private :
> >     std::vector<size_t> val_;
> > };
> >
> > template<typename T>
> > void crude_bench(T func, const size_t& count){
> >     clock_t t = clock();
> >     for(size_t i = 0; i < count; ++i){
> >         func();
> >     }
> >     double duration{(clock() - t) / (double)count};
> >     std::cout << duration << " ticks per run\n";
> > }
> >
> > int main (int argc, char* argv []) {
> >     auto count = 100000ul;
> >     {
> >         Vec v;
> >         std::cout << "Copying: " << std::flush;
> >         crude_bench(
> >             std::bind([](Vec& v){ Vec other(v); }, v),
> >             count
> >         );
> >     }
> >     {
> >         Vec v;
> >         std::cout << "next2const: " << std::flush;
> >         crude_bench(
> >             std::bind(&Vec::next2const, v),
> >             count
> >         );
> >     }
> >     {
> >         Vec v;
> >         std::cout << "next2pseudoconst: " << std::flush;
> >         crude_bench(
> >             std::bind(&Vec::next2pseudoconst, v),
> >             count
> >         );
> >     }
> >     return 0;
> > }
> >
>
> Without any optimisation on GCC, what I get is:
>
> > Copying: 0.31656 ticks per run
> > next2const: 18.2984 ticks per run
> > next2pseudoconst: 18.0145 ticks per run
>
> Note that the next2const duration minus the Copying duration (which
> is necessary to compare the two) is less than the next2pseudoconst
> duration - but not by any meaningful amount. There's a good reason
> for that - const doesn't perform any kind of magic here. It wouldn't
> make sense if it did, although the Vec method is const, it still
> creates another Vec and performs a non-const operation upon THAT.
>
> Just as a sidenote as to the importance of running benchmarks over
> many iterations. I have run the above benchmark over iterations
> increasing in powers of 2, and charted the ticks per iteration for
> GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I'm not sure if I can
> attach the charts to the group via email attachment, so I have
> uploaded them here: https://imgur.com/a/Mj2P6 - the two lines
> correspond with ticks(next2pseudoconst) and ticks(next2const)-
> ticks(copying) - You can see the negative tick count of (next2const -
> copying) in the first iteration, which should go some way to tell you
> how unreliable a single run benchmark is.
>
> Regards,
> Jake Arkinstall
>
> On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall <jake.arkinstall@gm
> ail.com> wrote:
> > Also note that you're including the allocation of 1000 size_ts in
> > that first timer. I'm not at my PC right now to test, but does
> > moving the initialization of V to before the clock start
> > significantly reduce the discrepancy?
> >
> > On 21 Feb 2018 23:23, "Jake Arkinstall" <jake.arkinstall@gmail.com>
> > wrote:
> > > Welcome!
> > >
> > > Perhaps you can explain the consequences further, namely give an
> > > example of something useful that it would allow.
> > >
> > > One of the benefits of having something const is not just that
> > > the data is unchanged at the END, but that it doesn't change AT
> > > ALL during execution. This is often useful in a threaded
> > > situation (when you want to make sure you don't introduce race
> > > conditions), and its primary purpose is to stop you from making
> > > mistakes rather than to optimise.
> > >
> > > On top of this, the compiler is able to easily determine whether
> > > or not you are obeying the const declaration in the definition of
> > > a method, in that only const operations are used inside of it -
> > > how is the compiler supposed to verify if the second method
> > > actually reverses the first? Trust the developer? Because that's
> > > the situation we have without const already.
> > >
> > > On 21 Feb 2018 23:00, <jsaintmartin356@gmail.com> wrote:
> > > > One of my post on stackoverflow.com was said to have its place
> > > > here.
> > > >
> > > > https://stackoverflow.com/questions/48915277/what-about-pseudoc
> > > > onst-qualifier
> > > >
> > > > What do you think about my new pseudoconst qualifier ?
> > > > Expecting for your answer, (and/or possibly a job: long
> > > > unemployed at the moment)
> > > >
> > > > Jerome Saint-Martin,
> > > > Montrouge, France
> > > >
> > > >
> > > >

--
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.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gmail.com.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEwi%2BsJAn2O_DF9cP7ZfjBSjHVg%40mail.gmail.com.

--001a11453a726217b60565cd3f1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>It&#39;s better to have the method as non-const and =
deal with the consequences, if possible, than to make a vital class data me=
mber mutable. The former does not trick the user into creating unwanted sid=
e-effects, but the latter can. The former is honest, the latter is a tricks=
ter.<div dir=3D"auto"><br></div><div dir=3D"auto">There&#39;s certainly a p=
lace for mutable, but not here IMO.</div><br><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On 22 Feb 2018 07:08, &quot;Richard Hodges&quot=
; &lt;<a href=3D"mailto:hodges.r@gmail.com">hodges.r@gmail.com</a>&gt; wrot=
e:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-te=
xt">On Thu, 2018-02-22 at 01:13 +0000, Jake Arkinstall wrote:<br>
&gt; Further to my previous reply, I have written a rough version which<br>
&gt; should be a bit more reliable (it isn&#39;t perfect, but should suffic=
e<br>
&gt; for the purpose of demonstration).<br>
<br>
<br>
</div>C++ already provides the mutable keyword. The Vec class in question c=
an<br>
be written in terms of it:<br>
<div class=3D"quoted-text"><br>
class Vec {<br>
public :<br>
=C2=A0 =C2=A0 Vec () : val_ (std::vector&lt;size_t&gt; (1000, 0)) {}<br>
<br>
</div>=C2=A0 =C2=A0 // copy constructor is un-necessary. The compiler build=
s a correct<br>
=C2=A0 =C2=A0 // one.<br>
<br>
=C2=A0 =C2=A0 //actual const method<br>
=C2=A0 =C2=A0 void next2() const {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inc ();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dec ();<br>
=C2=A0 =C2=A0 }<br>
<br>
=C2=A0 =C2=A0 // these are now const<br>
=C2=A0 =C2=A0 void inc () const {<br>
<div class=3D"quoted-text">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::for_each (val_.=
begin (), val_.end (),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0[] (size_t&amp;s) {++s;});<br>
=C2=A0 =C2=A0 }<br>
<br>
</div>=C2=A0 =C2=A0 void dec () const {<br>
<div class=3D"quoted-text">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::for_each (val_.=
begin (), val_.end (),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0[] (size_t&amp;s) {--s;});<br>
=C2=A0 =C2=A0 }<br>
<br>
</div>private :<br>
=C2=A0 =C2=A0 // mutable members can be modified when the object is accesse=
d<br>
=C2=A0 =C2=A0 // through a const reference<br>
=C2=A0 =C2=A0 mutable std::vector&lt;size_t&gt; val_;<br>
};<br>
<div class=3D"elided-text"><br>
<br>
<br>
<br>
&gt;<br>
&gt; Inserting to std::cout (especially with a flush, i.e. as std::endl)<br=
>
&gt; can play hell during the benchmark stage, so I have removed that. I<br=
>
&gt; have also ensured that each benchmark minimally interferes with the<br=
>
&gt; others (by scoping each out), extracted the time for the copying<br>
&gt; operation (as it isn&#39;t valid to compare Vec::Vec() and Vec::Vec(co=
nst<br>
&gt; Vec&amp;) - the two do different things). Most importantly, the method=
s<br>
&gt; are run many times to minimise statistical error and to try and iron<b=
r>
&gt; out the impact of e.g. dynamic frequency scaling.<br>
&gt;<br>
&gt; &gt; #include &lt;vector&gt;<br>
&gt; &gt; #include &lt;iostream&gt;<br>
&gt; &gt; #include &lt;algorithm&gt;<br>
&gt; &gt; #include &lt;functional&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; class Vec {<br>
&gt; &gt; public :<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Vec () : val_ (std::vector&lt;size_t&gt; (1000=
, 0)) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Vec (const Vec&amp; v) : val_ (v.val_) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0//couple of const opposite methods<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void inc () {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::for_each (val_.begin (), va=
l_.end (), [] (size_t&amp;s)<br>
&gt; &gt; {++s;});<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void dec () {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::for_each (val_.begin (), va=
l_.end (), [] (size_t&amp;s) {-<br>
&gt; &gt; -s;});<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void next2const () const {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v (*this);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v.inc();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v.dec();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void next2pseudoconst() { //pseudo const metho=
d<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inc ();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dec ();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt; private :<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0std::vector&lt;size_t&gt; val_;<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; template&lt;typename T&gt;<br>
&gt; &gt; void crude_bench(T func, const size_t&amp; count){<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0clock_t t =3D clock();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0for(size_t i =3D 0; i &lt; count; ++i){<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0func();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0double duration{(clock() - t) / (double)count}=
;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; duration &lt;&lt; &quot; ti=
cks per run\n&quot;;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; int main (int argc, char* argv []) {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0auto count =3D 100000ul;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;Copying=
: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind([](Vec&a=
mp; v){ Vec other(v); }, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;next2co=
nst: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind(&amp;Vec=
::next2const, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;next2ps=
eudoconst: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind(&amp;Vec=
::<wbr>next2pseudoconst, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0return 0;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt;<br>
&gt; Without any optimisation on GCC, what I get is:<br>
&gt;<br>
&gt; &gt; Copying: 0.31656 ticks per run<br>
&gt; &gt; next2const: 18.2984 ticks per run<br>
&gt; &gt; next2pseudoconst: 18.0145 ticks per run<br>
&gt;<br>
&gt; Note that the next2const duration minus the Copying duration (which<br=
>
&gt; is necessary to compare the two) is less than the next2pseudoconst<br>
&gt; duration - but not by any meaningful amount. There&#39;s a good reason=
<br>
&gt; for that - const doesn&#39;t perform any kind of magic here. It wouldn=
&#39;t<br>
&gt; make sense if it did, although the Vec method is const, it still<br>
&gt; creates another Vec and performs a non-const operation upon THAT.<br>
&gt;<br>
&gt; Just as a sidenote as to the importance of running benchmarks over<br>
&gt; many iterations. I have run the above benchmark over iterations<br>
&gt; increasing in powers of 2, and charted the ticks per iteration for<br>
&gt; GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I&#39;m not sure if I can<=
br>
&gt; attach the charts to the group via email attachment, so I have<br>
&gt; uploaded them here: <a href=3D"https://imgur.com/a/Mj2P6" rel=3D"noref=
errer" target=3D"_blank">https://imgur.com/a/Mj2P6</a> - the two lines<br>
&gt; correspond with ticks(next2pseudoconst) and ticks(next2const)-<br>
&gt; ticks(copying) - You can see the negative tick count of (next2const -<=
br>
&gt; copying) in the first iteration, which should go some way to tell you<=
br>
&gt; how unreliable a single run benchmark is.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Jake Arkinstall<br>
&gt;<br>
&gt; On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall &lt;jake.arkinstall@=
gm<br>
&gt; <a href=3D"http://ail.com" rel=3D"noreferrer" target=3D"_blank">ail.co=
m</a>&gt; wrote:<br>
&gt; &gt; Also note that you&#39;re including the allocation of 1000 size_t=
s in<br>
&gt; &gt; that first timer. I&#39;m not at my PC right now to test, but doe=
s<br>
&gt; &gt; moving the initialization of V to before the clock start<br>
&gt; &gt; significantly reduce the discrepancy?<br>
&gt; &gt;<br>
&gt; &gt; On 21 Feb 2018 23:23, &quot;Jake Arkinstall&quot; &lt;<a href=3D"=
mailto:jake.arkinstall@gmail.com">jake.arkinstall@gmail.com</a>&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt; &gt; Welcome!<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Perhaps you can explain the consequences further, namely giv=
e an<br>
&gt; &gt; &gt; example of something useful that it would allow.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; One of the benefits of having something const is not just th=
at<br>
&gt; &gt; &gt; the data is unchanged at the END, but that it doesn&#39;t ch=
ange AT<br>
&gt; &gt; &gt; ALL during execution. This is often useful in a threaded<br>
&gt; &gt; &gt; situation (when you want to make sure you don&#39;t introduc=
e race<br>
&gt; &gt; &gt; conditions), and its primary purpose is to stop you from mak=
ing<br>
&gt; &gt; &gt; mistakes rather than to optimise.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On top of this, the compiler is able to easily determine whe=
ther<br>
&gt; &gt; &gt; or not you are obeying the const declaration in the definiti=
on of<br>
&gt; &gt; &gt; a method, in that only const operations are used inside of i=
t -<br>
&gt; &gt; &gt; how is the compiler supposed to verify if the second method<=
br>
&gt; &gt; &gt; actually reverses the first? Trust the developer? Because th=
at&#39;s<br>
&gt; &gt; &gt; the situation we have without const already.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On 21 Feb 2018 23:00, &lt;<a href=3D"mailto:jsaintmartin356@=
gmail.com">jsaintmartin356@gmail.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; One of my post on <a href=3D"http://stackoverflow.com" =
rel=3D"noreferrer" target=3D"_blank">stackoverflow.com</a> was said to have=
 its place<br>
&gt; &gt; &gt; &gt; here.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; <a href=3D"https://stackoverflow.com/questions/48915277=
/what-about-pseudoc" rel=3D"noreferrer" target=3D"_blank">https://stackover=
flow.com/<wbr>questions/48915277/what-about-<wbr>pseudoc</a><br>
&gt; &gt; &gt; &gt; onst-qualifier<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; What do you think about my new pseudoconst qualifier ?<=
br>
&gt; &gt; &gt; &gt; Expecting for your answer, (and/or possibly a job: long=
<br>
&gt; &gt; &gt; &gt; unemployed at the moment)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Jerome Saint-Martin,<br>
&gt; &gt; &gt; &gt; Montrouge, France<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gma=
il.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<w=
br>isocpp.org/d/msgid/std-<wbr>proposals/1519283315.58210.23.<wbr>camel%40g=
mail.com</a>.<br>
</blockquote></div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEwi%2BsJAn=
2O_DF9cP7ZfjBSjHVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk3=
7F3bivpoKcLLUvEwi%2BsJAn2O_DF9cP7ZfjBSjHVg%40mail.gmail.com</a>.<br />

--001a11453a726217b60565cd3f1c--

.

--001a11c012485487850565d2e952
Content-Type: text/plain; charset="UTF-8"

A pseudo const method is a method who calls a method A at its beginning,
few const methods, and then the reverse method A

On Thu, Feb 22, 2018 at 2:44 PM, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

> It's better to have the method as non-const and deal with the
> consequences, if possible, than to make a vital class data member mutable.
> The former does not trick the user into creating unwanted side-effects, but
> the latter can. The former is honest, the latter is a trickster.
>
> There's certainly a place for mutable, but not here IMO.
>
>
> On 22 Feb 2018 07:08, "Richard Hodges" <hodges.r@gmail.com> wrote:
>
> On Thu, 2018-02-22 at 01:13 +0000, Jake Arkinstall wrote:
> > Further to my previous reply, I have written a rough version which
> > should be a bit more reliable (it isn't perfect, but should suffice
> > for the purpose of demonstration).
>
>
> C++ already provides the mutable keyword. The Vec class in question can
> be written in terms of it:
>
> class Vec {
> public :
>     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
>
>     // copy constructor is un-necessary. The compiler builds a correct
>     // one.
>
>     //actual const method
>     void next2() const {
>         inc ();
>         dec ();
>     }
>
>     // these are now const
>     void inc () const {
>         std::for_each (val_.begin (), val_.end (),
>                        [] (size_t&s) {++s;});
>     }
>
>     void dec () const {
>         std::for_each (val_.begin (), val_.end (),
>                        [] (size_t&s) {--s;});
>     }
>
> private :
>     // mutable members can be modified when the object is accessed
>     // through a const reference
>     mutable std::vector<size_t> val_;
> };
>
>
>
>
> >
> > Inserting to std::cout (especially with a flush, i.e. as std::endl)
> > can play hell during the benchmark stage, so I have removed that. I
> > have also ensured that each benchmark minimally interferes with the
> > others (by scoping each out), extracted the time for the copying
> > operation (as it isn't valid to compare Vec::Vec() and Vec::Vec(const
> > Vec&) - the two do different things). Most importantly, the methods
> > are run many times to minimise statistical error and to try and iron
> > out the impact of e.g. dynamic frequency scaling.
> >
> > > #include <vector>
> > > #include <iostream>
> > > #include <algorithm>
> > > #include <functional>
> > >
> > >
> > > class Vec {
> > > public :
> > >     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
> > >     Vec (const Vec& v) : val_ (v.val_) {}
> > >     //couple of const opposite methods
> > >     void inc () {
> > >         std::for_each (val_.begin (), val_.end (), [] (size_t&s)
> > > {++s;});
> > >     }
> > >     void dec () {
> > >         std::for_each (val_.begin (), val_.end (), [] (size_t&s) {-
> > > -s;});
> > >     }
> > >     void next2const () const {
> > >         Vec v (*this);
> > >         v.inc();
> > >         v.dec();
> > >     }
> > >     void next2pseudoconst() { //pseudo const method
> > >         inc ();
> > >         dec ();
> > >     }
> > > private :
> > >     std::vector<size_t> val_;
> > > };
> > >
> > > template<typename T>
> > > void crude_bench(T func, const size_t& count){
> > >     clock_t t = clock();
> > >     for(size_t i = 0; i < count; ++i){
> > >         func();
> > >     }
> > >     double duration{(clock() - t) / (double)count};
> > >     std::cout << duration << " ticks per run\n";
> > > }
> > >
> > > int main (int argc, char* argv []) {
> > >     auto count = 100000ul;
> > >     {
> > >         Vec v;
> > >         std::cout << "Copying: " << std::flush;
> > >         crude_bench(
> > >             std::bind([](Vec& v){ Vec other(v); }, v),
> > >             count
> > >         );
> > >     }
> > >     {
> > >         Vec v;
> > >         std::cout << "next2const: " << std::flush;
> > >         crude_bench(
> > >             std::bind(&Vec::next2const, v),
> > >             count
> > >         );
> > >     }
> > >     {
> > >         Vec v;
> > >         std::cout << "next2pseudoconst: " << std::flush;
> > >         crude_bench(
> > >             std::bind(&Vec::next2pseudoconst, v),
> > >             count
> > >         );
> > >     }
> > >     return 0;
> > > }
> > >
> >
> > Without any optimisation on GCC, what I get is:
> >
> > > Copying: 0.31656 ticks per run
> > > next2const: 18.2984 ticks per run
> > > next2pseudoconst: 18.0145 ticks per run
> >
> > Note that the next2const duration minus the Copying duration (which
> > is necessary to compare the two) is less than the next2pseudoconst
> > duration - but not by any meaningful amount. There's a good reason
> > for that - const doesn't perform any kind of magic here. It wouldn't
> > make sense if it did, although the Vec method is const, it still
> > creates another Vec and performs a non-const operation upon THAT.
> >
> > Just as a sidenote as to the importance of running benchmarks over
> > many iterations. I have run the above benchmark over iterations
> > increasing in powers of 2, and charted the ticks per iteration for
> > GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I'm not sure if I can
> > attach the charts to the group via email attachment, so I have
> > uploaded them here: https://imgur.com/a/Mj2P6 - the two lines
> > correspond with ticks(next2pseudoconst) and ticks(next2const)-
> > ticks(copying) - You can see the negative tick count of (next2const -
> > copying) in the first iteration, which should go some way to tell you
> > how unreliable a single run benchmark is.
> >
> > Regards,
> > Jake Arkinstall
> >
> > On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall <jake.arkinstall@gm
> > ail.com> wrote:
> > > Also note that you're including the allocation of 1000 size_ts in
> > > that first timer. I'm not at my PC right now to test, but does
> > > moving the initialization of V to before the clock start
> > > significantly reduce the discrepancy?
> > >
> > > On 21 Feb 2018 23:23, "Jake Arkinstall" <jake.arkinstall@gmail.com>
> > > wrote:
> > > > Welcome!
> > > >
> > > > Perhaps you can explain the consequences further, namely give an
> > > > example of something useful that it would allow.
> > > >
> > > > One of the benefits of having something const is not just that
> > > > the data is unchanged at the END, but that it doesn't change AT
> > > > ALL during execution. This is often useful in a threaded
> > > > situation (when you want to make sure you don't introduce race
> > > > conditions), and its primary purpose is to stop you from making
> > > > mistakes rather than to optimise.
> > > >
> > > > On top of this, the compiler is able to easily determine whether
> > > > or not you are obeying the const declaration in the definition of
> > > > a method, in that only const operations are used inside of it -
> > > > how is the compiler supposed to verify if the second method
> > > > actually reverses the first? Trust the developer? Because that's
> > > > the situation we have without const already.
> > > >
> > > > On 21 Feb 2018 23:00, <jsaintmartin356@gmail.com> wrote:
> > > > > One of my post on stackoverflow.com was said to have its place
> > > > > here.
> > > > >
> > > > > https://stackoverflow.com/questions/48915277/what-about-pseudoc
> > > > > onst-qualifier
> > > > >
> > > > > What do you think about my new pseudoconst qualifier ?
> > > > > Expecting for your answer, (and/or possibly a job: long
> > > > > unemployed at the moment)
> > > > >
> > > > > Jerome Saint-Martin,
> > > > > Montrouge, France
> > > > >
> > > > >
> > > > >
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gmail.com.
>
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEwi%
> 2BsJAn2O_DF9cP7ZfjBSjHVg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEwi%2BsJAn2O_DF9cP7ZfjBSjHVg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEa2Zk9Wv4YtqbT0w-sUhMqF2mZu36QhQW7e%3Dr-X2%2BasjQ%40mail.gmail.com.

--001a11c012485487850565d2e952
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A pseudo const method is a method who calls a method A at =
its beginning, few const methods, and then the reverse method A<br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Feb 22, 201=
8 at 2:44 PM, Jake Arkinstall <span dir=3D"ltr">&lt;<a href=3D"mailto:jake.=
arkinstall@gmail.com" target=3D"_blank">jake.arkinstall@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>It&#3=
9;s better to have the method as non-const and deal with the consequences, =
if possible, than to make a vital class data member mutable. The former doe=
s not trick the user into creating unwanted side-effects, but the latter ca=
n. The former is honest, the latter is a trickster.<div dir=3D"auto"><br></=
div><div dir=3D"auto">There&#39;s certainly a place for mutable, but not he=
re IMO.</div><div><div class=3D"h5"><br><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On 22 Feb 2018 07:08, &quot;Richard Hodges&quot; &lt=
;<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com=
</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"m_-61168966301=
51128286quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div class=3D"m_-6116896630151128286quoted-text">On Thu, 2018-0=
2-22 at 01:13 +0000, Jake Arkinstall wrote:<br>
&gt; Further to my previous reply, I have written a rough version which<br>
&gt; should be a bit more reliable (it isn&#39;t perfect, but should suffic=
e<br>
&gt; for the purpose of demonstration).<br>
<br>
<br>
</div>C++ already provides the mutable keyword. The Vec class in question c=
an<br>
be written in terms of it:<br>
<div class=3D"m_-6116896630151128286quoted-text"><br>
class Vec {<br>
public :<br>
=C2=A0 =C2=A0 Vec () : val_ (std::vector&lt;size_t&gt; (1000, 0)) {}<br>
<br>
</div>=C2=A0 =C2=A0 // copy constructor is un-necessary. The compiler build=
s a correct<br>
=C2=A0 =C2=A0 // one.<br>
<br>
=C2=A0 =C2=A0 //actual const method<br>
=C2=A0 =C2=A0 void next2() const {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inc ();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dec ();<br>
=C2=A0 =C2=A0 }<br>
<br>
=C2=A0 =C2=A0 // these are now const<br>
=C2=A0 =C2=A0 void inc () const {<br>
<div class=3D"m_-6116896630151128286quoted-text">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 std::for_each (val_.begin (), val_.end (),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0[] (size_t&amp;s) {++s;});<br>
=C2=A0 =C2=A0 }<br>
<br>
</div>=C2=A0 =C2=A0 void dec () const {<br>
<div class=3D"m_-6116896630151128286quoted-text">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 std::for_each (val_.begin (), val_.end (),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0[] (size_t&amp;s) {--s;});<br>
=C2=A0 =C2=A0 }<br>
<br>
</div>private :<br>
=C2=A0 =C2=A0 // mutable members can be modified when the object is accesse=
d<br>
=C2=A0 =C2=A0 // through a const reference<br>
=C2=A0 =C2=A0 mutable std::vector&lt;size_t&gt; val_;<br>
};<br>
<div class=3D"m_-6116896630151128286elided-text"><br>
<br>
<br>
<br>
&gt;<br>
&gt; Inserting to std::cout (especially with a flush, i.e. as std::endl)<br=
>
&gt; can play hell during the benchmark stage, so I have removed that. I<br=
>
&gt; have also ensured that each benchmark minimally interferes with the<br=
>
&gt; others (by scoping each out), extracted the time for the copying<br>
&gt; operation (as it isn&#39;t valid to compare Vec::Vec() and Vec::Vec(co=
nst<br>
&gt; Vec&amp;) - the two do different things). Most importantly, the method=
s<br>
&gt; are run many times to minimise statistical error and to try and iron<b=
r>
&gt; out the impact of e.g. dynamic frequency scaling.<br>
&gt;<br>
&gt; &gt; #include &lt;vector&gt;<br>
&gt; &gt; #include &lt;iostream&gt;<br>
&gt; &gt; #include &lt;algorithm&gt;<br>
&gt; &gt; #include &lt;functional&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; class Vec {<br>
&gt; &gt; public :<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Vec () : val_ (std::vector&lt;size_t&gt; (1000=
, 0)) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Vec (const Vec&amp; v) : val_ (v.val_) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0//couple of const opposite methods<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void inc () {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::for_each (val_.begin (), va=
l_.end (), [] (size_t&amp;s)<br>
&gt; &gt; {++s;});<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void dec () {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::for_each (val_.begin (), va=
l_.end (), [] (size_t&amp;s) {-<br>
&gt; &gt; -s;});<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void next2const () const {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v (*this);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v.inc();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v.dec();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void next2pseudoconst() { //pseudo const metho=
d<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inc ();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dec ();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt; private :<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0std::vector&lt;size_t&gt; val_;<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; template&lt;typename T&gt;<br>
&gt; &gt; void crude_bench(T func, const size_t&amp; count){<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0clock_t t =3D clock();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0for(size_t i =3D 0; i &lt; count; ++i){<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0func();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0double duration{(clock() - t) / (double)count}=
;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; duration &lt;&lt; &quot; ti=
cks per run\n&quot;;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; int main (int argc, char* argv []) {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0auto count =3D 100000ul;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;Copying=
: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind([](Vec&a=
mp; v){ Vec other(v); }, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;next2co=
nst: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind(&amp;Vec=
::next2const, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;next2ps=
eudoconst: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind(&amp;Vec=
::next2pseudoco<wbr>nst, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0return 0;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt;<br>
&gt; Without any optimisation on GCC, what I get is:<br>
&gt;<br>
&gt; &gt; Copying: 0.31656 ticks per run<br>
&gt; &gt; next2const: 18.2984 ticks per run<br>
&gt; &gt; next2pseudoconst: 18.0145 ticks per run<br>
&gt;<br>
&gt; Note that the next2const duration minus the Copying duration (which<br=
>
&gt; is necessary to compare the two) is less than the next2pseudoconst<br>
&gt; duration - but not by any meaningful amount. There&#39;s a good reason=
<br>
&gt; for that - const doesn&#39;t perform any kind of magic here. It wouldn=
&#39;t<br>
&gt; make sense if it did, although the Vec method is const, it still<br>
&gt; creates another Vec and performs a non-const operation upon THAT.<br>
&gt;<br>
&gt; Just as a sidenote as to the importance of running benchmarks over<br>
&gt; many iterations. I have run the above benchmark over iterations<br>
&gt; increasing in powers of 2, and charted the ticks per iteration for<br>
&gt; GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I&#39;m not sure if I can<=
br>
&gt; attach the charts to the group via email attachment, so I have<br>
&gt; uploaded them here: <a href=3D"https://imgur.com/a/Mj2P6" rel=3D"noref=
errer" target=3D"_blank">https://imgur.com/a/Mj2P6</a> - the two lines<br>
&gt; correspond with ticks(next2pseudoconst) and ticks(next2const)-<br>
&gt; ticks(copying) - You can see the negative tick count of (next2const -<=
br>
&gt; copying) in the first iteration, which should go some way to tell you<=
br>
&gt; how unreliable a single run benchmark is.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Jake Arkinstall<br>
&gt;<br>
&gt; On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall &lt;jake.arkinstall@=
gm<br>
&gt; <a href=3D"http://ail.com" rel=3D"noreferrer" target=3D"_blank">ail.co=
m</a>&gt; wrote:<br>
&gt; &gt; Also note that you&#39;re including the allocation of 1000 size_t=
s in<br>
&gt; &gt; that first timer. I&#39;m not at my PC right now to test, but doe=
s<br>
&gt; &gt; moving the initialization of V to before the clock start<br>
&gt; &gt; significantly reduce the discrepancy?<br>
&gt; &gt;<br>
&gt; &gt; On 21 Feb 2018 23:23, &quot;Jake Arkinstall&quot; &lt;<a href=3D"=
mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkinstall@gmail.c=
om</a>&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt; &gt; Welcome!<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Perhaps you can explain the consequences further, namely giv=
e an<br>
&gt; &gt; &gt; example of something useful that it would allow.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; One of the benefits of having something const is not just th=
at<br>
&gt; &gt; &gt; the data is unchanged at the END, but that it doesn&#39;t ch=
ange AT<br>
&gt; &gt; &gt; ALL during execution. This is often useful in a threaded<br>
&gt; &gt; &gt; situation (when you want to make sure you don&#39;t introduc=
e race<br>
&gt; &gt; &gt; conditions), and its primary purpose is to stop you from mak=
ing<br>
&gt; &gt; &gt; mistakes rather than to optimise.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On top of this, the compiler is able to easily determine whe=
ther<br>
&gt; &gt; &gt; or not you are obeying the const declaration in the definiti=
on of<br>
&gt; &gt; &gt; a method, in that only const operations are used inside of i=
t -<br>
&gt; &gt; &gt; how is the compiler supposed to verify if the second method<=
br>
&gt; &gt; &gt; actually reverses the first? Trust the developer? Because th=
at&#39;s<br>
&gt; &gt; &gt; the situation we have without const already.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On 21 Feb 2018 23:00, &lt;<a href=3D"mailto:jsaintmartin356@=
gmail.com" target=3D"_blank">jsaintmartin356@gmail.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; One of my post on <a href=3D"http://stackoverflow.com" =
rel=3D"noreferrer" target=3D"_blank">stackoverflow.com</a> was said to have=
 its place<br>
&gt; &gt; &gt; &gt; here.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; <a href=3D"https://stackoverflow.com/questions/48915277=
/what-about-pseudoc" rel=3D"noreferrer" target=3D"_blank">https://stackover=
flow.com/ques<wbr>tions/48915277/what-about-pseu<wbr>doc</a><br>
&gt; &gt; &gt; &gt; onst-qualifier<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; What do you think about my new pseudoconst qualifier ?<=
br>
&gt; &gt; &gt; &gt; Expecting for your answer, (and/or possibly a job: long=
<br>
&gt; &gt; &gt; &gt; unemployed at the moment)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Jerome Saint-Martin,<br>
&gt; &gt; &gt; &gt; Montrouge, France<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gma=
il.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is=
<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1519283315.58210.23.camel%<wbr>40g=
mail.com</a>.<br>
</blockquote></div><br></div></div></div></div></div><div><div class=3D"h5"=
>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEwi%2BsJAn=
2O_DF9cP7ZfjBSjHVg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAC%<wbr>2B0CCNYk37F3bivpoKcLLUvEwi%<wbr>2BsJAn2O_DF9cP7=
ZfjBSjHVg%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC4OUEa2Zk9Wv4YtqbT0w-sUhMqF2mZu36Qh=
QW7e%3Dr-X2%2BasjQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEa2Zk9W=
v4YtqbT0w-sUhMqF2mZu36QhQW7e%3Dr-X2%2BasjQ%40mail.gmail.com</a>.<br />

--001a11c012485487850565d2e952--

.

--001a11c012485046f80565d300e3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

constance is exists comparing end object to begin object, but not every
calls are const.

On Thu, Feb 22, 2018 at 9:30 PM, J=C3=A9r=C3=B4me Saint-Martin <
jsaintmartin356@gmail.com> wrote:

> A pseudo const method is a method who calls a method A at its beginning,
> few const methods, and then the reverse method A
>
> On Thu, Feb 22, 2018 at 2:44 PM, Jake Arkinstall <
> jake.arkinstall@gmail.com> wrote:
>
>> It's better to have the method as non-const and deal with the
>> consequences, if possible, than to make a vital class data member mutabl=
e.
>> The former does not trick the user into creating unwanted side-effects, =
but
>> the latter can. The former is honest, the latter is a trickster.
>>
>> There's certainly a place for mutable, but not here IMO.
>>
>>
>> On 22 Feb 2018 07:08, "Richard Hodges" <hodges.r@gmail.com> wrote:
>>
>> On Thu, 2018-02-22 at 01:13 +0000, Jake Arkinstall wrote:
>> > Further to my previous reply, I have written a rough version which
>> > should be a bit more reliable (it isn't perfect, but should suffice
>> > for the purpose of demonstration).
>>
>>
>> C++ already provides the mutable keyword. The Vec class in question can
>> be written in terms of it:
>>
>> class Vec {
>> public :
>>     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
>>
>>     // copy constructor is un-necessary. The compiler builds a correct
>>     // one.
>>
>>     //actual const method
>>     void next2() const {
>>         inc ();
>>         dec ();
>>     }
>>
>>     // these are now const
>>     void inc () const {
>>         std::for_each (val_.begin (), val_.end (),
>>                        [] (size_t&s) {++s;});
>>     }
>>
>>     void dec () const {
>>         std::for_each (val_.begin (), val_.end (),
>>                        [] (size_t&s) {--s;});
>>     }
>>
>> private :
>>     // mutable members can be modified when the object is accessed
>>     // through a const reference
>>     mutable std::vector<size_t> val_;
>> };
>>
>>
>>
>>
>> >
>> > Inserting to std::cout (especially with a flush, i.e. as std::endl)
>> > can play hell during the benchmark stage, so I have removed that. I
>> > have also ensured that each benchmark minimally interferes with the
>> > others (by scoping each out), extracted the time for the copying
>> > operation (as it isn't valid to compare Vec::Vec() and Vec::Vec(const
>> > Vec&) - the two do different things). Most importantly, the methods
>> > are run many times to minimise statistical error and to try and iron
>> > out the impact of e.g. dynamic frequency scaling.
>> >
>> > > #include <vector>
>> > > #include <iostream>
>> > > #include <algorithm>
>> > > #include <functional>
>> > >
>> > >
>> > > class Vec {
>> > > public :
>> > >     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
>> > >     Vec (const Vec& v) : val_ (v.val_) {}
>> > >     //couple of const opposite methods
>> > >     void inc () {
>> > >         std::for_each (val_.begin (), val_.end (), [] (size_t&s)
>> > > {++s;});
>> > >     }
>> > >     void dec () {
>> > >         std::for_each (val_.begin (), val_.end (), [] (size_t&s) {-
>> > > -s;});
>> > >     }
>> > >     void next2const () const {
>> > >         Vec v (*this);
>> > >         v.inc();
>> > >         v.dec();
>> > >     }
>> > >     void next2pseudoconst() { //pseudo const method
>> > >         inc ();
>> > >         dec ();
>> > >     }
>> > > private :
>> > >     std::vector<size_t> val_;
>> > > };
>> > >
>> > > template<typename T>
>> > > void crude_bench(T func, const size_t& count){
>> > >     clock_t t =3D clock();
>> > >     for(size_t i =3D 0; i < count; ++i){
>> > >         func();
>> > >     }
>> > >     double duration{(clock() - t) / (double)count};
>> > >     std::cout << duration << " ticks per run\n";
>> > > }
>> > >
>> > > int main (int argc, char* argv []) {
>> > >     auto count =3D 100000ul;
>> > >     {
>> > >         Vec v;
>> > >         std::cout << "Copying: " << std::flush;
>> > >         crude_bench(
>> > >             std::bind([](Vec& v){ Vec other(v); }, v),
>> > >             count
>> > >         );
>> > >     }
>> > >     {
>> > >         Vec v;
>> > >         std::cout << "next2const: " << std::flush;
>> > >         crude_bench(
>> > >             std::bind(&Vec::next2const, v),
>> > >             count
>> > >         );
>> > >     }
>> > >     {
>> > >         Vec v;
>> > >         std::cout << "next2pseudoconst: " << std::flush;
>> > >         crude_bench(
>> > >             std::bind(&Vec::next2pseudoconst, v),
>> > >             count
>> > >         );
>> > >     }
>> > >     return 0;
>> > > }
>> > >
>> >
>> > Without any optimisation on GCC, what I get is:
>> >
>> > > Copying: 0.31656 ticks per run
>> > > next2const: 18.2984 ticks per run
>> > > next2pseudoconst: 18.0145 ticks per run
>> >
>> > Note that the next2const duration minus the Copying duration (which
>> > is necessary to compare the two) is less than the next2pseudoconst
>> > duration - but not by any meaningful amount. There's a good reason
>> > for that - const doesn't perform any kind of magic here. It wouldn't
>> > make sense if it did, although the Vec method is const, it still
>> > creates another Vec and performs a non-const operation upon THAT.
>> >
>> > Just as a sidenote as to the importance of running benchmarks over
>> > many iterations. I have run the above benchmark over iterations
>> > increasing in powers of 2, and charted the ticks per iteration for
>> > GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I'm not sure if I can
>> > attach the charts to the group via email attachment, so I have
>> > uploaded them here: https://imgur.com/a/Mj2P6 - the two lines
>> > correspond with ticks(next2pseudoconst) and ticks(next2const)-
>> > ticks(copying) - You can see the negative tick count of (next2const -
>> > copying) in the first iteration, which should go some way to tell you
>> > how unreliable a single run benchmark is.
>> >
>> > Regards,
>> > Jake Arkinstall
>> >
>> > On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall <jake.arkinstall@gm
>> > ail.com> wrote:
>> > > Also note that you're including the allocation of 1000 size_ts in
>> > > that first timer. I'm not at my PC right now to test, but does
>> > > moving the initialization of V to before the clock start
>> > > significantly reduce the discrepancy?
>> > >
>> > > On 21 Feb 2018 23:23, "Jake Arkinstall" <jake.arkinstall@gmail.com>
>> > > wrote:
>> > > > Welcome!
>> > > >
>> > > > Perhaps you can explain the consequences further, namely give an
>> > > > example of something useful that it would allow.
>> > > >
>> > > > One of the benefits of having something const is not just that
>> > > > the data is unchanged at the END, but that it doesn't change AT
>> > > > ALL during execution. This is often useful in a threaded
>> > > > situation (when you want to make sure you don't introduce race
>> > > > conditions), and its primary purpose is to stop you from making
>> > > > mistakes rather than to optimise.
>> > > >
>> > > > On top of this, the compiler is able to easily determine whether
>> > > > or not you are obeying the const declaration in the definition of
>> > > > a method, in that only const operations are used inside of it -
>> > > > how is the compiler supposed to verify if the second method
>> > > > actually reverses the first? Trust the developer? Because that's
>> > > > the situation we have without const already.
>> > > >
>> > > > On 21 Feb 2018 23:00, <jsaintmartin356@gmail.com> wrote:
>> > > > > One of my post on stackoverflow.com was said to have its place
>> > > > > here.
>> > > > >
>> > > > > https://stackoverflow.com/questions/48915277/what-about-pseudoc
>> > > > > onst-qualifier
>> > > > >
>> > > > > What do you think about my new pseudoconst qualifier ?
>> > > > > Expecting for your answer, (and/or possibly a job: long
>> > > > > unemployed at the moment)
>> > > > >
>> > > > > Jerome Saint-Martin,
>> > > > > Montrouge, France
>> > > > >
>> > > > >
>> > > > >
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gmail.com.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEw
>> i%2BsJAn2O_DF9cP7ZfjBSjHVg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN=
Yk37F3bivpoKcLLUvEwi%2BsJAn2O_DF9cP7ZfjBSjHVg%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAC4OUEb8xt110uE%3Dy4W8yScutUUQaJtk4mfNStA5hR4Cd=
pRrmw%40mail.gmail.com.

--001a11c012485046f80565d300e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">constance is exists comparing end object to begin object, =
but not every calls are const.<br></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Thu, Feb 22, 2018 at 9:30 PM, J=C3=A9r=C3=B4me Sa=
int-Martin <span dir=3D"ltr">&lt;<a href=3D"mailto:jsaintmartin356@gmail.co=
m" target=3D"_blank">jsaintmartin356@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">A pseudo const method is a met=
hod who calls a method A at its beginning, few const methods, and then the =
reverse method A<br></div><div class=3D"HOEnZb"><div class=3D"h5"><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Feb 22, 2018 at 2:=
44 PM, Jake Arkinstall <span dir=3D"ltr">&lt;<a href=3D"mailto:jake.arkinst=
all@gmail.com" target=3D"_blank">jake.arkinstall@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>It&#39;s bet=
ter to have the method as non-const and deal with the consequences, if poss=
ible, than to make a vital class data member mutable. The former does not t=
rick the user into creating unwanted side-effects, but the latter can. The =
former is honest, the latter is a trickster.<div dir=3D"auto"><br></div><di=
v dir=3D"auto">There&#39;s certainly a place for mutable, but not here IMO.=
</div><div><div class=3D"m_3673943974962220257h5"><br><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On 22 Feb 2018 07:08, &quot;Richard Ho=
dges&quot; &lt;<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodg=
es.r@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"=
m_3673943974962220257m_-6116896630151128286quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"m_367394397496=
2220257m_-6116896630151128286quoted-text">On Thu, 2018-02-22 at 01:13 +0000=
, Jake Arkinstall wrote:<br>
&gt; Further to my previous reply, I have written a rough version which<br>
&gt; should be a bit more reliable (it isn&#39;t perfect, but should suffic=
e<br>
&gt; for the purpose of demonstration).<br>
<br>
<br>
</div>C++ already provides the mutable keyword. The Vec class in question c=
an<br>
be written in terms of it:<br>
<div class=3D"m_3673943974962220257m_-6116896630151128286quoted-text"><br>
class Vec {<br>
public :<br>
=C2=A0 =C2=A0 Vec () : val_ (std::vector&lt;size_t&gt; (1000, 0)) {}<br>
<br>
</div>=C2=A0 =C2=A0 // copy constructor is un-necessary. The compiler build=
s a correct<br>
=C2=A0 =C2=A0 // one.<br>
<br>
=C2=A0 =C2=A0 //actual const method<br>
=C2=A0 =C2=A0 void next2() const {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inc ();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dec ();<br>
=C2=A0 =C2=A0 }<br>
<br>
=C2=A0 =C2=A0 // these are now const<br>
=C2=A0 =C2=A0 void inc () const {<br>
<div class=3D"m_3673943974962220257m_-6116896630151128286quoted-text">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 std::for_each (val_.begin (), val_.end (),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0[] (size_t&amp;s) {++s;});<br>
=C2=A0 =C2=A0 }<br>
<br>
</div>=C2=A0 =C2=A0 void dec () const {<br>
<div class=3D"m_3673943974962220257m_-6116896630151128286quoted-text">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 std::for_each (val_.begin (), val_.end (),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0[] (size_t&amp;s) {--s;});<br>
=C2=A0 =C2=A0 }<br>
<br>
</div>private :<br>
=C2=A0 =C2=A0 // mutable members can be modified when the object is accesse=
d<br>
=C2=A0 =C2=A0 // through a const reference<br>
=C2=A0 =C2=A0 mutable std::vector&lt;size_t&gt; val_;<br>
};<br>
<div class=3D"m_3673943974962220257m_-6116896630151128286elided-text"><br>
<br>
<br>
<br>
&gt;<br>
&gt; Inserting to std::cout (especially with a flush, i.e. as std::endl)<br=
>
&gt; can play hell during the benchmark stage, so I have removed that. I<br=
>
&gt; have also ensured that each benchmark minimally interferes with the<br=
>
&gt; others (by scoping each out), extracted the time for the copying<br>
&gt; operation (as it isn&#39;t valid to compare Vec::Vec() and Vec::Vec(co=
nst<br>
&gt; Vec&amp;) - the two do different things). Most importantly, the method=
s<br>
&gt; are run many times to minimise statistical error and to try and iron<b=
r>
&gt; out the impact of e.g. dynamic frequency scaling.<br>
&gt;<br>
&gt; &gt; #include &lt;vector&gt;<br>
&gt; &gt; #include &lt;iostream&gt;<br>
&gt; &gt; #include &lt;algorithm&gt;<br>
&gt; &gt; #include &lt;functional&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; class Vec {<br>
&gt; &gt; public :<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Vec () : val_ (std::vector&lt;size_t&gt; (1000=
, 0)) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Vec (const Vec&amp; v) : val_ (v.val_) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0//couple of const opposite methods<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void inc () {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::for_each (val_.begin (), va=
l_.end (), [] (size_t&amp;s)<br>
&gt; &gt; {++s;});<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void dec () {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::for_each (val_.begin (), va=
l_.end (), [] (size_t&amp;s) {-<br>
&gt; &gt; -s;});<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void next2const () const {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v (*this);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v.inc();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v.dec();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void next2pseudoconst() { //pseudo const metho=
d<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inc ();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dec ();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt; private :<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0std::vector&lt;size_t&gt; val_;<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; template&lt;typename T&gt;<br>
&gt; &gt; void crude_bench(T func, const size_t&amp; count){<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0clock_t t =3D clock();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0for(size_t i =3D 0; i &lt; count; ++i){<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0func();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0double duration{(clock() - t) / (double)count}=
;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; duration &lt;&lt; &quot; ti=
cks per run\n&quot;;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; int main (int argc, char* argv []) {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0auto count =3D 100000ul;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;Copying=
: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind([](Vec&a=
mp; v){ Vec other(v); }, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;next2co=
nst: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind(&amp;Vec=
::next2const, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;next2ps=
eudoconst: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind(&amp;Vec=
::next2pseudoco<wbr>nst, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0return 0;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt;<br>
&gt; Without any optimisation on GCC, what I get is:<br>
&gt;<br>
&gt; &gt; Copying: 0.31656 ticks per run<br>
&gt; &gt; next2const: 18.2984 ticks per run<br>
&gt; &gt; next2pseudoconst: 18.0145 ticks per run<br>
&gt;<br>
&gt; Note that the next2const duration minus the Copying duration (which<br=
>
&gt; is necessary to compare the two) is less than the next2pseudoconst<br>
&gt; duration - but not by any meaningful amount. There&#39;s a good reason=
<br>
&gt; for that - const doesn&#39;t perform any kind of magic here. It wouldn=
&#39;t<br>
&gt; make sense if it did, although the Vec method is const, it still<br>
&gt; creates another Vec and performs a non-const operation upon THAT.<br>
&gt;<br>
&gt; Just as a sidenote as to the importance of running benchmarks over<br>
&gt; many iterations. I have run the above benchmark over iterations<br>
&gt; increasing in powers of 2, and charted the ticks per iteration for<br>
&gt; GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I&#39;m not sure if I can<=
br>
&gt; attach the charts to the group via email attachment, so I have<br>
&gt; uploaded them here: <a href=3D"https://imgur.com/a/Mj2P6" rel=3D"noref=
errer" target=3D"_blank">https://imgur.com/a/Mj2P6</a> - the two lines<br>
&gt; correspond with ticks(next2pseudoconst) and ticks(next2const)-<br>
&gt; ticks(copying) - You can see the negative tick count of (next2const -<=
br>
&gt; copying) in the first iteration, which should go some way to tell you<=
br>
&gt; how unreliable a single run benchmark is.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Jake Arkinstall<br>
&gt;<br>
&gt; On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall &lt;jake.arkinstall@=
gm<br>
&gt; <a href=3D"http://ail.com" rel=3D"noreferrer" target=3D"_blank">ail.co=
m</a>&gt; wrote:<br>
&gt; &gt; Also note that you&#39;re including the allocation of 1000 size_t=
s in<br>
&gt; &gt; that first timer. I&#39;m not at my PC right now to test, but doe=
s<br>
&gt; &gt; moving the initialization of V to before the clock start<br>
&gt; &gt; significantly reduce the discrepancy?<br>
&gt; &gt;<br>
&gt; &gt; On 21 Feb 2018 23:23, &quot;Jake Arkinstall&quot; &lt;<a href=3D"=
mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkinstall@gmail.c=
om</a>&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt; &gt; Welcome!<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Perhaps you can explain the consequences further, namely giv=
e an<br>
&gt; &gt; &gt; example of something useful that it would allow.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; One of the benefits of having something const is not just th=
at<br>
&gt; &gt; &gt; the data is unchanged at the END, but that it doesn&#39;t ch=
ange AT<br>
&gt; &gt; &gt; ALL during execution. This is often useful in a threaded<br>
&gt; &gt; &gt; situation (when you want to make sure you don&#39;t introduc=
e race<br>
&gt; &gt; &gt; conditions), and its primary purpose is to stop you from mak=
ing<br>
&gt; &gt; &gt; mistakes rather than to optimise.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On top of this, the compiler is able to easily determine whe=
ther<br>
&gt; &gt; &gt; or not you are obeying the const declaration in the definiti=
on of<br>
&gt; &gt; &gt; a method, in that only const operations are used inside of i=
t -<br>
&gt; &gt; &gt; how is the compiler supposed to verify if the second method<=
br>
&gt; &gt; &gt; actually reverses the first? Trust the developer? Because th=
at&#39;s<br>
&gt; &gt; &gt; the situation we have without const already.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On 21 Feb 2018 23:00, &lt;<a href=3D"mailto:jsaintmartin356@=
gmail.com" target=3D"_blank">jsaintmartin356@gmail.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; One of my post on <a href=3D"http://stackoverflow.com" =
rel=3D"noreferrer" target=3D"_blank">stackoverflow.com</a> was said to have=
 its place<br>
&gt; &gt; &gt; &gt; here.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; <a href=3D"https://stackoverflow.com/questions/48915277=
/what-about-pseudoc" rel=3D"noreferrer" target=3D"_blank">https://stackover=
flow.com/ques<wbr>tions/48915277/what-about-pseu<wbr>doc</a><br>
&gt; &gt; &gt; &gt; onst-qualifier<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; What do you think about my new pseudoconst qualifier ?<=
br>
&gt; &gt; &gt; &gt; Expecting for your answer, (and/or possibly a job: long=
<br>
&gt; &gt; &gt; &gt; unemployed at the moment)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Jerome Saint-Martin,<br>
&gt; &gt; &gt; &gt; Montrouge, France<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gma=
il.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is=
<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1519283315.58210.23.camel%40g<wbr>=
mail.com</a>.<br>
</blockquote></div><br></div></div></div></div></div><div><div class=3D"m_3=
673943974962220257h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEwi%2BsJAn=
2O_DF9cP7ZfjBSjHVg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CAC%2B0CCNYk37F3bivpoKcLLUvEw<wbr>i%2BsJAn2O_DF9cP7ZfjBS=
jHVg%40m<wbr>ail.gmail.com</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC4OUEb8xt110uE%3Dy4W8yScutUUQaJtk4m=
fNStA5hR4CdpRrmw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEb8xt110u=
E%3Dy4W8yScutUUQaJtk4mfNStA5hR4CdpRrmw%40mail.gmail.com</a>.<br />

--001a11c012485046f80565d300e3--

.

--001a114b171c38fb1f0565d332ef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

But again, the two main issues are that it is not const during the duration
of the method, and the compiler will not be able to determine if the final
call truly is the reverse of A.

Perhaps if there were a way of creating a reversible operation in a
self-contained manner, I'd be more confident. An example of this would be a
library that allows one to define an algorithm in such a manner as the
compiler is able to reverse it (with certain assumptions about various
undefined behaviours, maybe; remember that incrementing signed integer
types beyond their max, or decrementing them from zero, is undefined
behaviour and as such may not be valid on all systems).

I would take great interest, albeit academic, in this kind of approach. It
would likely need a list of reversible instructions, for which the reverse
can be determined (without necessarily relying on operator- being the
reverse of operator+, because that is user defined for custom classes and
they have every possibility of not being opposites). The list is iterated
forwards with the initial operations, then iterated backwards with the
reverse operations, to undo it.

Without such an approach, we lose all confidence in pseudo-constness from
the POV of the compiler. I still don't see what benefit pseudo-const would
provide, though. There is no optimisation benefit, and its use in a
threaded application is limited.

Note also that the same effect is possible by creating a view on the class,
allowing you to be const without copying anything.

On 22 Feb 2018 20:30, "J=C3=A9r=C3=B4me Saint-Martin" <jsaintmartin356@gmai=
l.com>
wrote:

> A pseudo const method is a method who calls a method A at its beginning,
> few const methods, and then the reverse method A
>
> On Thu, Feb 22, 2018 at 2:44 PM, Jake Arkinstall <
> jake.arkinstall@gmail.com> wrote:
>
>> It's better to have the method as non-const and deal with the
>> consequences, if possible, than to make a vital class data member mutabl=
e.
>> The former does not trick the user into creating unwanted side-effects, =
but
>> the latter can. The former is honest, the latter is a trickster.
>>
>> There's certainly a place for mutable, but not here IMO.
>>
>>
>> On 22 Feb 2018 07:08, "Richard Hodges" <hodges.r@gmail.com> wrote:
>>
>> On Thu, 2018-02-22 at 01:13 +0000, Jake Arkinstall wrote:
>> > Further to my previous reply, I have written a rough version which
>> > should be a bit more reliable (it isn't perfect, but should suffice
>> > for the purpose of demonstration).
>>
>>
>> C++ already provides the mutable keyword. The Vec class in question can
>> be written in terms of it:
>>
>> class Vec {
>> public :
>>     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
>>
>>     // copy constructor is un-necessary. The compiler builds a correct
>>     // one.
>>
>>     //actual const method
>>     void next2() const {
>>         inc ();
>>         dec ();
>>     }
>>
>>     // these are now const
>>     void inc () const {
>>         std::for_each (val_.begin (), val_.end (),
>>                        [] (size_t&s) {++s;});
>>     }
>>
>>     void dec () const {
>>         std::for_each (val_.begin (), val_.end (),
>>                        [] (size_t&s) {--s;});
>>     }
>>
>> private :
>>     // mutable members can be modified when the object is accessed
>>     // through a const reference
>>     mutable std::vector<size_t> val_;
>> };
>>
>>
>>
>>
>> >
>> > Inserting to std::cout (especially with a flush, i.e. as std::endl)
>> > can play hell during the benchmark stage, so I have removed that. I
>> > have also ensured that each benchmark minimally interferes with the
>> > others (by scoping each out), extracted the time for the copying
>> > operation (as it isn't valid to compare Vec::Vec() and Vec::Vec(const
>> > Vec&) - the two do different things). Most importantly, the methods
>> > are run many times to minimise statistical error and to try and iron
>> > out the impact of e.g. dynamic frequency scaling.
>> >
>> > > #include <vector>
>> > > #include <iostream>
>> > > #include <algorithm>
>> > > #include <functional>
>> > >
>> > >
>> > > class Vec {
>> > > public :
>> > >     Vec () : val_ (std::vector<size_t> (1000, 0)) {}
>> > >     Vec (const Vec& v) : val_ (v.val_) {}
>> > >     //couple of const opposite methods
>> > >     void inc () {
>> > >         std::for_each (val_.begin (), val_.end (), [] (size_t&s)
>> > > {++s;});
>> > >     }
>> > >     void dec () {
>> > >         std::for_each (val_.begin (), val_.end (), [] (size_t&s) {-
>> > > -s;});
>> > >     }
>> > >     void next2const () const {
>> > >         Vec v (*this);
>> > >         v.inc();
>> > >         v.dec();
>> > >     }
>> > >     void next2pseudoconst() { //pseudo const method
>> > >         inc ();
>> > >         dec ();
>> > >     }
>> > > private :
>> > >     std::vector<size_t> val_;
>> > > };
>> > >
>> > > template<typename T>
>> > > void crude_bench(T func, const size_t& count){
>> > >     clock_t t =3D clock();
>> > >     for(size_t i =3D 0; i < count; ++i){
>> > >         func();
>> > >     }
>> > >     double duration{(clock() - t) / (double)count};
>> > >     std::cout << duration << " ticks per run\n";
>> > > }
>> > >
>> > > int main (int argc, char* argv []) {
>> > >     auto count =3D 100000ul;
>> > >     {
>> > >         Vec v;
>> > >         std::cout << "Copying: " << std::flush;
>> > >         crude_bench(
>> > >             std::bind([](Vec& v){ Vec other(v); }, v),
>> > >             count
>> > >         );
>> > >     }
>> > >     {
>> > >         Vec v;
>> > >         std::cout << "next2const: " << std::flush;
>> > >         crude_bench(
>> > >             std::bind(&Vec::next2const, v),
>> > >             count
>> > >         );
>> > >     }
>> > >     {
>> > >         Vec v;
>> > >         std::cout << "next2pseudoconst: " << std::flush;
>> > >         crude_bench(
>> > >             std::bind(&Vec::next2pseudoconst, v),
>> > >             count
>> > >         );
>> > >     }
>> > >     return 0;
>> > > }
>> > >
>> >
>> > Without any optimisation on GCC, what I get is:
>> >
>> > > Copying: 0.31656 ticks per run
>> > > next2const: 18.2984 ticks per run
>> > > next2pseudoconst: 18.0145 ticks per run
>> >
>> > Note that the next2const duration minus the Copying duration (which
>> > is necessary to compare the two) is less than the next2pseudoconst
>> > duration - but not by any meaningful amount. There's a good reason
>> > for that - const doesn't perform any kind of magic here. It wouldn't
>> > make sense if it did, although the Vec method is const, it still
>> > creates another Vec and performs a non-const operation upon THAT.
>> >
>> > Just as a sidenote as to the importance of running benchmarks over
>> > many iterations. I have run the above benchmark over iterations
>> > increasing in powers of 2, and charted the ticks per iteration for
>> > GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I'm not sure if I can
>> > attach the charts to the group via email attachment, so I have
>> > uploaded them here: https://imgur.com/a/Mj2P6 - the two lines
>> > correspond with ticks(next2pseudoconst) and ticks(next2const)-
>> > ticks(copying) - You can see the negative tick count of (next2const -
>> > copying) in the first iteration, which should go some way to tell you
>> > how unreliable a single run benchmark is.
>> >
>> > Regards,
>> > Jake Arkinstall
>> >
>> > On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall <jake.arkinstall@gm
>> > ail.com> wrote:
>> > > Also note that you're including the allocation of 1000 size_ts in
>> > > that first timer. I'm not at my PC right now to test, but does
>> > > moving the initialization of V to before the clock start
>> > > significantly reduce the discrepancy?
>> > >
>> > > On 21 Feb 2018 23:23, "Jake Arkinstall" <jake.arkinstall@gmail.com>
>> > > wrote:
>> > > > Welcome!
>> > > >
>> > > > Perhaps you can explain the consequences further, namely give an
>> > > > example of something useful that it would allow.
>> > > >
>> > > > One of the benefits of having something const is not just that
>> > > > the data is unchanged at the END, but that it doesn't change AT
>> > > > ALL during execution. This is often useful in a threaded
>> > > > situation (when you want to make sure you don't introduce race
>> > > > conditions), and its primary purpose is to stop you from making
>> > > > mistakes rather than to optimise.
>> > > >
>> > > > On top of this, the compiler is able to easily determine whether
>> > > > or not you are obeying the const declaration in the definition of
>> > > > a method, in that only const operations are used inside of it -
>> > > > how is the compiler supposed to verify if the second method
>> > > > actually reverses the first? Trust the developer? Because that's
>> > > > the situation we have without const already.
>> > > >
>> > > > On 21 Feb 2018 23:00, <jsaintmartin356@gmail.com> wrote:
>> > > > > One of my post on stackoverflow.com was said to have its place
>> > > > > here.
>> > > > >
>> > > > > https://stackoverflow.com/questions/48915277/what-about-pseudoc
>> > > > > onst-qualifier
>> > > > >
>> > > > > What do you think about my new pseudoconst qualifier ?
>> > > > > Expecting for your answer, (and/or possibly a job: long
>> > > > > unemployed at the moment)
>> > > > >
>> > > > > Jerome Saint-Martin,
>> > > > > Montrouge, France
>> > > > >
>> > > > >
>> > > > >
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gmail.com.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEw
>> i%2BsJAn2O_DF9cP7ZfjBSjHVg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN=
Yk37F3bivpoKcLLUvEwi%2BsJAn2O_DF9cP7ZfjBSjHVg%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC4OUEa2Zk9Wv4YtqbT0w-
> sUhMqF2mZu36QhQW7e%3Dr-X2%2BasjQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEa2Zk=
9Wv4YtqbT0w-sUhMqF2mZu36QhQW7e%3Dr-X2%2BasjQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAC%2B0CCP2ns-7-kaAU8p6w1MkuZPL-7rXo7AudccEWf%3D=
oX--n1g%40mail.gmail.com.

--001a114b171c38fb1f0565d332ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">But again, the two main issues are that it is not const d=
uring the duration of the method, and the compiler will not be able to dete=
rmine if the final call truly is the reverse of A.<div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Perhaps if there were a way of creating a reversible o=
peration in a self-contained manner, I&#39;d be more confident. An example =
of this would be a library that allows one to define an algorithm in such a=
 manner as the compiler is able to reverse it (with certain assumptions abo=
ut various undefined behaviours, maybe; remember that incrementing signed i=
nteger types beyond their max, or decrementing them from zero, is undefined=
 behaviour and as such may not be valid on all systems).<div dir=3D"auto"><=
br></div><div dir=3D"auto">I would take great interest, albeit academic, in=
 this kind of approach. It would likely need a list of reversible instructi=
ons, for which the reverse can be determined (without necessarily relying o=
n operator- being the reverse of operator+, because that is user defined fo=
r custom classes and they have every possibility of not being opposites). T=
he list is iterated forwards with the initial operations, then iterated bac=
kwards with the reverse operations, to undo it.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Without such an approach, we lose all confidence in=
 pseudo-constness from the POV of the compiler. I still don&#39;t see what =
benefit pseudo-const would provide, though. There is no optimisation benefi=
t, and its use in a threaded application is limited.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">Note also that the same effect is possible by =
creating a view on the class, allowing you to be const without copying anyt=
hing.</div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On 22 Feb 2018 20:30, &quot;J=C3=A9r=C3=B4me Saint-Martin&quot; &lt;<=
a href=3D"mailto:jsaintmartin356@gmail.com">jsaintmartin356@gmail.com</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">A pseudo const method is a method who calls a method A at its begi=
nning, few const methods, and then the reverse method A<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Feb 22, 2018 at 2:4=
4 PM, Jake Arkinstall <span dir=3D"ltr">&lt;<a href=3D"mailto:jake.arkinsta=
ll@gmail.com" target=3D"_blank">jake.arkinstall@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>It&#39;s bett=
er to have the method as non-const and deal with the consequences, if possi=
ble, than to make a vital class data member mutable. The former does not tr=
ick the user into creating unwanted side-effects, but the latter can. The f=
ormer is honest, the latter is a trickster.<div dir=3D"auto"><br></div><div=
 dir=3D"auto">There&#39;s certainly a place for mutable, but not here IMO.<=
/div><div><div class=3D"m_-1486869905183559635h5"><br><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On 22 Feb 2018 07:08, &quot;Richard Ho=
dges&quot; &lt;<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodg=
es.r@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"=
m_-1486869905183559635m_-6116896630151128286quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"m_-1486869905=
183559635m_-6116896630151128286quoted-text">On Thu, 2018-02-22 at 01:13 +00=
00, Jake Arkinstall wrote:<br>
&gt; Further to my previous reply, I have written a rough version which<br>
&gt; should be a bit more reliable (it isn&#39;t perfect, but should suffic=
e<br>
&gt; for the purpose of demonstration).<br>
<br>
<br>
</div>C++ already provides the mutable keyword. The Vec class in question c=
an<br>
be written in terms of it:<br>
<div class=3D"m_-1486869905183559635m_-6116896630151128286quoted-text"><br>
class Vec {<br>
public :<br>
=C2=A0 =C2=A0 Vec () : val_ (std::vector&lt;size_t&gt; (1000, 0)) {}<br>
<br>
</div>=C2=A0 =C2=A0 // copy constructor is un-necessary. The compiler build=
s a correct<br>
=C2=A0 =C2=A0 // one.<br>
<br>
=C2=A0 =C2=A0 //actual const method<br>
=C2=A0 =C2=A0 void next2() const {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inc ();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dec ();<br>
=C2=A0 =C2=A0 }<br>
<br>
=C2=A0 =C2=A0 // these are now const<br>
=C2=A0 =C2=A0 void inc () const {<br>
<div class=3D"m_-1486869905183559635m_-6116896630151128286quoted-text">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 std::for_each (val_.begin (), val_.end (),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0[] (size_t&amp;s) {++s;});<br>
=C2=A0 =C2=A0 }<br>
<br>
</div>=C2=A0 =C2=A0 void dec () const {<br>
<div class=3D"m_-1486869905183559635m_-6116896630151128286quoted-text">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 std::for_each (val_.begin (), val_.end (),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0[] (size_t&amp;s) {--s;});<br>
=C2=A0 =C2=A0 }<br>
<br>
</div>private :<br>
=C2=A0 =C2=A0 // mutable members can be modified when the object is accesse=
d<br>
=C2=A0 =C2=A0 // through a const reference<br>
=C2=A0 =C2=A0 mutable std::vector&lt;size_t&gt; val_;<br>
};<br>
<div class=3D"m_-1486869905183559635m_-6116896630151128286elided-text"><br>
<br>
<br>
<br>
&gt;<br>
&gt; Inserting to std::cout (especially with a flush, i.e. as std::endl)<br=
>
&gt; can play hell during the benchmark stage, so I have removed that. I<br=
>
&gt; have also ensured that each benchmark minimally interferes with the<br=
>
&gt; others (by scoping each out), extracted the time for the copying<br>
&gt; operation (as it isn&#39;t valid to compare Vec::Vec() and Vec::Vec(co=
nst<br>
&gt; Vec&amp;) - the two do different things). Most importantly, the method=
s<br>
&gt; are run many times to minimise statistical error and to try and iron<b=
r>
&gt; out the impact of e.g. dynamic frequency scaling.<br>
&gt;<br>
&gt; &gt; #include &lt;vector&gt;<br>
&gt; &gt; #include &lt;iostream&gt;<br>
&gt; &gt; #include &lt;algorithm&gt;<br>
&gt; &gt; #include &lt;functional&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; class Vec {<br>
&gt; &gt; public :<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Vec () : val_ (std::vector&lt;size_t&gt; (1000=
, 0)) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Vec (const Vec&amp; v) : val_ (v.val_) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0//couple of const opposite methods<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void inc () {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::for_each (val_.begin (), va=
l_.end (), [] (size_t&amp;s)<br>
&gt; &gt; {++s;});<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void dec () {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::for_each (val_.begin (), va=
l_.end (), [] (size_t&amp;s) {-<br>
&gt; &gt; -s;});<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void next2const () const {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v (*this);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v.inc();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v.dec();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0void next2pseudoconst() { //pseudo const metho=
d<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inc ();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dec ();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt; private :<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0std::vector&lt;size_t&gt; val_;<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; template&lt;typename T&gt;<br>
&gt; &gt; void crude_bench(T func, const size_t&amp; count){<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0clock_t t =3D clock();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0for(size_t i =3D 0; i &lt; count; ++i){<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0func();<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0double duration{(clock() - t) / (double)count}=
;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; duration &lt;&lt; &quot; ti=
cks per run\n&quot;;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; int main (int argc, char* argv []) {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0auto count =3D 100000ul;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;Copying=
: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind([](Vec&a=
mp; v){ Vec other(v); }, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;next2co=
nst: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind(&amp;Vec=
::next2const, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vec v;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout &lt;&lt; &quot;next2ps=
eudoconst: &quot; &lt;&lt; std::flush;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crude_bench(<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::bind(&amp;Vec=
::next2pseudoco<wbr>nst, v),<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0return 0;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt;<br>
&gt; Without any optimisation on GCC, what I get is:<br>
&gt;<br>
&gt; &gt; Copying: 0.31656 ticks per run<br>
&gt; &gt; next2const: 18.2984 ticks per run<br>
&gt; &gt; next2pseudoconst: 18.0145 ticks per run<br>
&gt;<br>
&gt; Note that the next2const duration minus the Copying duration (which<br=
>
&gt; is necessary to compare the two) is less than the next2pseudoconst<br>
&gt; duration - but not by any meaningful amount. There&#39;s a good reason=
<br>
&gt; for that - const doesn&#39;t perform any kind of magic here. It wouldn=
&#39;t<br>
&gt; make sense if it did, although the Vec method is const, it still<br>
&gt; creates another Vec and performs a non-const operation upon THAT.<br>
&gt;<br>
&gt; Just as a sidenote as to the importance of running benchmarks over<br>
&gt; many iterations. I have run the above benchmark over iterations<br>
&gt; increasing in powers of 2, and charted the ticks per iteration for<br>
&gt; GCC7.3.1 unoptimised and GCC7.3.1 with -O3. I&#39;m not sure if I can<=
br>
&gt; attach the charts to the group via email attachment, so I have<br>
&gt; uploaded them here: <a href=3D"https://imgur.com/a/Mj2P6" rel=3D"noref=
errer" target=3D"_blank">https://imgur.com/a/Mj2P6</a> - the two lines<br>
&gt; correspond with ticks(next2pseudoconst) and ticks(next2const)-<br>
&gt; ticks(copying) - You can see the negative tick count of (next2const -<=
br>
&gt; copying) in the first iteration, which should go some way to tell you<=
br>
&gt; how unreliable a single run benchmark is.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Jake Arkinstall<br>
&gt;<br>
&gt; On Wed, Feb 21, 2018 at 11:35 PM, Jake Arkinstall &lt;jake.arkinstall@=
gm<br>
&gt; <a href=3D"http://ail.com" rel=3D"noreferrer" target=3D"_blank">ail.co=
m</a>&gt; wrote:<br>
&gt; &gt; Also note that you&#39;re including the allocation of 1000 size_t=
s in<br>
&gt; &gt; that first timer. I&#39;m not at my PC right now to test, but doe=
s<br>
&gt; &gt; moving the initialization of V to before the clock start<br>
&gt; &gt; significantly reduce the discrepancy?<br>
&gt; &gt;<br>
&gt; &gt; On 21 Feb 2018 23:23, &quot;Jake Arkinstall&quot; &lt;<a href=3D"=
mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkinstall@gmail.c=
om</a>&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt; &gt; Welcome!<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Perhaps you can explain the consequences further, namely giv=
e an<br>
&gt; &gt; &gt; example of something useful that it would allow.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; One of the benefits of having something const is not just th=
at<br>
&gt; &gt; &gt; the data is unchanged at the END, but that it doesn&#39;t ch=
ange AT<br>
&gt; &gt; &gt; ALL during execution. This is often useful in a threaded<br>
&gt; &gt; &gt; situation (when you want to make sure you don&#39;t introduc=
e race<br>
&gt; &gt; &gt; conditions), and its primary purpose is to stop you from mak=
ing<br>
&gt; &gt; &gt; mistakes rather than to optimise.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On top of this, the compiler is able to easily determine whe=
ther<br>
&gt; &gt; &gt; or not you are obeying the const declaration in the definiti=
on of<br>
&gt; &gt; &gt; a method, in that only const operations are used inside of i=
t -<br>
&gt; &gt; &gt; how is the compiler supposed to verify if the second method<=
br>
&gt; &gt; &gt; actually reverses the first? Trust the developer? Because th=
at&#39;s<br>
&gt; &gt; &gt; the situation we have without const already.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On 21 Feb 2018 23:00, &lt;<a href=3D"mailto:jsaintmartin356@=
gmail.com" target=3D"_blank">jsaintmartin356@gmail.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; One of my post on <a href=3D"http://stackoverflow.com" =
rel=3D"noreferrer" target=3D"_blank">stackoverflow.com</a> was said to have=
 its place<br>
&gt; &gt; &gt; &gt; here.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; <a href=3D"https://stackoverflow.com/questions/48915277=
/what-about-pseudoc" rel=3D"noreferrer" target=3D"_blank">https://stackover=
flow.com/ques<wbr>tions/48915277/what-about-pseu<wbr>doc</a><br>
&gt; &gt; &gt; &gt; onst-qualifier<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; What do you think about my new pseudoconst qualifier ?<=
br>
&gt; &gt; &gt; &gt; Expecting for your answer, (and/or possibly a job: long=
<br>
&gt; &gt; &gt; &gt; unemployed at the moment)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Jerome Saint-Martin,<br>
&gt; &gt; &gt; &gt; Montrouge, France<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/1519283315.58210.23.camel%40gma=
il.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is=
<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1519283315.58210.23.camel%40g<wbr>=
mail.com</a>.<br>
</blockquote></div><br></div></div></div></div></div><div><div class=3D"m_-=
1486869905183559635h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNYk37F3bivpoKcLLUvEwi%2BsJAn=
2O_DF9cP7ZfjBSjHVg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CAC%2B0CCNYk37F3bivpoKcLLUvEw<wbr>i%2BsJAn2O_DF9cP7ZfjBS=
jHVg%40m<wbr>ail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC4OUEa2Zk9Wv4YtqbT0w-sUhMqF2mZu36Qh=
QW7e%3Dr-X2%2BasjQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/<wbr>CAC4OUEa2Zk9Wv4YtqbT0w-<wbr>sUhMqF2mZu36QhQW7e%3Dr-=
X2%<wbr>2BasjQ%40mail.gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP2ns-7-kaAU8p6w1MkuZPL-7rXo7=
AudccEWf%3DoX--n1g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP2ns=
-7-kaAU8p6w1MkuZPL-7rXo7AudccEWf%3DoX--n1g%40mail.gmail.com</a>.<br />

--001a114b171c38fb1f0565d332ef--

.

------=_Part_3367_1662830570.1519333409848
Content-Type: multipart/alternative;
 boundary="----=_Part_3368_491445571.1519333409848"

------=_Part_3368_491445571.1519333409848
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thursday, February 22, 2018 at 3:30:18 PM UTC-5, J=C3=A9r=C3=B4me Saint-=
Martin=20
wrote:
>
> A pseudo const method is a method who calls a method A at its beginning,=
=20
> few const methods, and then the reverse method A
>

OK, but why does this concept need to be part of the type system? I can't=
=20
think of a lot of circumstances where this would be genuinely useful. And=
=20
certainly not useful enough to become part of the language.

And how would the compiler verify that A and ~A would be called? Consider=
=20
`const`. If you write a method that takes a parameter as `const`, then you=
=20
cannot do non-`const` things to it without an explicit cast. But with this=
=20
"pseudoconst" business, the compiler has no way to verify that you've=20
implemented your "pseudoconst" method correctly.

And if the compiler can't verify it, why is it part of the type system?

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0a7e7e42-aa28-4632-8e66-56b0633755ba%40isocpp.or=
g.

------=_Part_3368_491445571.1519333409848
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 22, 2018 at 3:30:18 PM UTC-5, J=C3=
=A9r=C3=B4me Saint-Martin wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr">A pseudo const method is a method who calls a method A a=
t its beginning, few const methods, and then the reverse method A<br></div>=
</blockquote><div><br>OK, but why does this concept need to be part of the =
type system? I can&#39;t think of a lot of circumstances where this would b=
e genuinely useful. And certainly not useful enough to become part of the l=
anguage.<br><br>And how would the compiler verify that A and ~A would be ca=
lled? Consider `const`. If you write a method that takes a parameter as `co=
nst`, then you cannot do non-`const` things to it without an explicit cast.=
 But with this &quot;pseudoconst&quot; business, the compiler has no way to=
 verify that you&#39;ve implemented your &quot;pseudoconst&quot; method cor=
rectly.<br><br>And if the compiler can&#39;t verify it, why is it part of t=
he type system?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0a7e7e42-aa28-4632-8e66-56b0633755ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a7e7e42-aa28-4632-8e66-56b0633755ba=
%40isocpp.org</a>.<br />

------=_Part_3368_491445571.1519333409848--

------=_Part_3367_1662830570.1519333409848--

.

On Thursday, 22 February 2018 12:30:15 PST J=C3=A9r=C3=B4me Saint-Martin wr=
ote:
> A pseudo const method is a method who calls a method A at its beginning,
> few const methods, and then the reverse method A

In other words, a method that is subject to the ABA problem. It's clearly n=
ot=20
thread-safe.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9684507.7AYeXOsgzc%40tjmaciei-mobl1.

.

------=_Part_4543_726637074.1519361680953
Content-Type: multipart/alternative;
 boundary="----=_Part_4544_1352910129.1519361680953"

------=_Part_4544_1352910129.1519361680953
Content-Type: text/plain; charset="UTF-8"



On Thursday, February 22, 2018 at 12:00:10 AM UTC+1, jsaintm...@gmail.com
wrote:

What do you think about a pseudoconst qualifier ? This qualifier would
allow a const method to use non const methods, but leaves the object equal
to what it was when the method was called.
The pseudoconst method can be checked by the compiler this way, the
structure of the pseudo const methods must be : calls to methods A, const
calls, reverse methods A.
Example :

    #include <vector>

    class Vec {
    public :
      Vec () : val_ (std::vector<size_t> (1000, 0)) {}
      Vec (const Vec& v) : val_ (v.val_) {}
      ~Vec () {}
      //couple of const opposite methods
      void inc () {
        std::for_each (val_.begin (), val_.end (), [] (size_t&s) {++s;});
      }
      void dec () {
        std::for_each (val_.begin (), val_.end (), [] (size_t&s) {--s;});
      }

      void write2 (std::ostream& os) const {
        os << "val_ [2] == " << val_ [2] << std::endl;
      }
      void write_next2const (std::ostream& os) const {
        Vec v (*this);
        v.inc ();
        v.write2 (os);
      }
      void write_next2pseudoconst (std::ostream& os) { //pseudo const method
        inc ();
        write2 (os);
        dec ();
      }
    //private :
      std::vector<size_t> val_;
    };

The test program :

    int main (int argc, char* argv []) {
      size_t duration (0);
      clock_t t (clock ());
      Vec v;
      v.write_next2const (std::cout);
      duration = (clock() - t);
      std::cout << "write_next2const took " << duration << " ticks" <<
std::endl;
      t = clock ();
      v.write_next2pseudoconst (std::cout);
      duration = (clock() - t);
      std::cout << "write_next2pseudoconst took " << duration << " ticks"
<< std::endl;
      return 0;
    }

shows that pseudoconst method is much faster :

    val_ [2] == 1
    write_next2const took 124 ticks
    val_ [2] == 1
    write_next2pseudoconst took 3 ticks

but the second could not be declared const though leaving the objects
unchanged.
What about "pseudoconst" qualifier in next compilers ?


Jerome Saint-Martin,
Montrouge, France



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/aede8413-b0f4-44d9-921e-9f706f51a1ba%40isocpp.org.

------=_Part_4544_1352910129.1519361680953
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, February 22, 2018 at 12:00:10 AM UTC+=
1, jsaintm...@gmail.com wrote:<br><div dir=3D"ltr"><br>What do you think ab=
out a pseudoconst qualifier ? This qualifier would allow a const method to =
use non const methods, but leaves the object equal to what it was when the =
method was called.<br>The pseudoconst method can be checked by the compiler=
 this way, the structure of the pseudo const methods must be : calls to met=
hods A, const calls, reverse methods A.<br>Example :<br><br>=C2=A0=C2=A0=C2=
=A0 #include &lt;vector&gt;<br><br>=C2=A0=C2=A0=C2=A0 class Vec {<br>=C2=A0=
=C2=A0=C2=A0 public : <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Vec () : val_ (std=
::vector&lt;size_t&gt; (1000, 0)) {}<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Vec =
(const Vec&amp; v) : val_ (v.val_) {}<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ~Ve=
c () {}<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //couple of const opposite method=
s<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void inc () {<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 std::for_each (val_.begin (), val_.end (), [] (size_t=
&amp;s) {++s;});<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 void dec () {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 st=
d::for_each (val_.begin (), val_.end (), [] (size_t&amp;s) {--s;});<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void wr=
ite2 (std::ostream&amp; os) const {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 os &lt;&lt; &quot;val_ [2] =3D=3D &quot; &lt;&lt; val_ [2] &lt;&lt; =
std::endl;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 void write_next2const (std::ostream&amp; os) const {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Vec v (*this);<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 v.inc ();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
v.write2 (os);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 void write_next2pseudoconst (std::ostream&amp; os) { //pseudo con=
st method<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inc ();<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 write2 (os);<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 dec ();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=
=C2=A0=C2=A0 //private :<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::vector&lt;s=
ize_t&gt; val_;<br>=C2=A0=C2=A0=C2=A0 };<br><br></div><div dir=3D"ltr">The =
test program :<br><br>=C2=A0=C2=A0=C2=A0 int main (int argc, char* argv [])=
 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 size_t duration (0);<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 clock_t t (clock ());<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Vec v;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v.write_next2const (std::cout);<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 duration =3D (clock() - t);<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;write_next2const took &quot; &l=
t;&lt; duration &lt;&lt; &quot; ticks&quot; &lt;&lt; std::endl;<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 t =3D clock ();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
v.write_next2pseudoconst (std::cout);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dur=
ation =3D (clock() - t);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout &lt;&l=
t; &quot;write_next2pseudoconst took &quot; &lt;&lt; duration &lt;&lt; &quo=
t; ticks&quot; &lt;&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return=
 0;<br>=C2=A0=C2=A0=C2=A0 }<br><br>shows that pseudoconst method is much fa=
ster :<br><br>=C2=A0=C2=A0=C2=A0 val_ [2] =3D=3D 1<br>=C2=A0=C2=A0=C2=A0 wr=
ite_next2const took 124 ticks<br>=C2=A0=C2=A0=C2=A0 val_ [2] =3D=3D 1<br>=
=C2=A0=C2=A0=C2=A0 write_next2pseudoconst took 3 ticks<br><br>but the secon=
d could not be declared const though leaving the objects unchanged. <br>Wha=
t about &quot;pseudoconst&quot; qualifier in next compilers ?<br><br><br>Je=
rome Saint-Martin, <br>Montrouge, France<br><br>
       =20




           =20
           =20
<table><tbody><tr><td><br></td><td><br></td></tr></tbody></table></div></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/aede8413-b0f4-44d9-921e-9f706f51a1ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aede8413-b0f4-44d9-921e-9f706f51a1ba=
%40isocpp.org</a>.<br />

------=_Part_4544_1352910129.1519361680953--

------=_Part_4543_726637074.1519361680953--

.

------=_Part_1697_1988276265.1519362275754
Content-Type: multipart/alternative;
 boundary="----=_Part_1698_1414202364.1519362275754"

------=_Part_1698_1414202364.1519362275754
Content-Type: text/plain; charset="UTF-8"

(this was the original message on stackoverflow.com, it was voted off topic
there, so I copied contents here)

>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/465bfacf-b29f-46ed-9b06-e04d8659ffff%40isocpp.org.

------=_Part_1698_1414202364.1519362275754
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">(this was the original message on stackoverflow.com, it wa=
s voted off topic there, so I copied contents here)<br><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><table><tbody><t=
r><td><br></td><td><br></td></tr></tbody></table></div></div></blockquote><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/465bfacf-b29f-46ed-9b06-e04d8659ffff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/465bfacf-b29f-46ed-9b06-e04d8659ffff=
%40isocpp.org</a>.<br />

------=_Part_1698_1414202364.1519362275754--

------=_Part_1697_1988276265.1519362275754--

.

------=_Part_3914_1592482751.1519363141292
Content-Type: multipart/alternative;
 boundary="----=_Part_3915_2066877310.1519363141293"

------=_Part_3915_2066877310.1519363141293
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The compiler may check the structure of a pseudo const is such :
-calls to methods A
-const or pseudo const calls
-calls to reverse methods A, in reverse
In the declaration of reverse methods, you may write the prototype of first=
=20
method, then the prototype of the reverse method, appended with "reverse" +=
=20
prototype of the original method

On Thursday, February 22, 2018 at 10:03:29 PM UTC+1, Nicol Bolas wrote:
>
> On Thursday, February 22, 2018 at 3:30:18 PM UTC-5, J=C3=A9r=C3=B4me Sain=
t-Martin=20
> wrote:
>>
>> A pseudo const method is a method who calls a method A at its beginning,=
=20
>> few const methods, and then the reverse method A
>>
>
> OK, but why does this concept need to be part of the type system? I can't=
=20
> think of a lot of circumstances where this would be genuinely useful. And=
=20
> certainly not useful enough to become part of the language.
>
> And how would the compiler verify that A and ~A would be called? Consider=
=20
> `const`. If you write a method that takes a parameter as `const`, then yo=
u=20
> cannot do non-`const` things to it without an explicit cast. But with thi=
s=20
> "pseudoconst" business, the compiler has no way to verify that you've=20
> implemented your "pseudoconst" method correctly.
>
> And if the compiler can't verify it, why is it part of the type system?
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ca3be727-ed85-4f73-b7f4-72c45c25c913%40isocpp.or=
g.

------=_Part_3915_2066877310.1519363141293
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The compiler may check the structure of a pseudo const is =
such :<br>-calls to methods A<br>-const or pseudo const calls<br>-calls to =
reverse methods A, in reverse<br>In the declaration of reverse methods, you=
 may write the prototype of first method, then the prototype of the reverse=
 method, appended with &quot;reverse&quot; + prototype of the original meth=
od<br><br>On Thursday, February 22, 2018 at 10:03:29 PM UTC+1, Nicol Bolas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Thur=
sday, February 22, 2018 at 3:30:18 PM UTC-5, J=C3=A9r=C3=B4me Saint-Martin =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">A pseudo con=
st method is a method who calls a method A at its beginning, few const meth=
ods, and then the reverse method A<br></div></blockquote><div><br>OK, but w=
hy does this concept need to be part of the type system? I can&#39;t think =
of a lot of circumstances where this would be genuinely useful. And certain=
ly not useful enough to become part of the language.<br><br>And how would t=
he compiler verify that A and ~A would be called? Consider `const`. If you =
write a method that takes a parameter as `const`, then you cannot do non-`c=
onst` things to it without an explicit cast. But with this &quot;pseudocons=
t&quot; business, the compiler has no way to verify that you&#39;ve impleme=
nted your &quot;pseudoconst&quot; method correctly.<br><br>And if the compi=
ler can&#39;t verify it, why is it part of the type system?<br></div></div>=
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ca3be727-ed85-4f73-b7f4-72c45c25c913%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ca3be727-ed85-4f73-b7f4-72c45c25c913=
%40isocpp.org</a>.<br />

------=_Part_3915_2066877310.1519363141293--

------=_Part_3914_1592482751.1519363141292--

.

------=_Part_4651_843108486.1519369533988
Content-Type: multipart/alternative;
 boundary="----=_Part_4652_877468176.1519369533988"

------=_Part_4652_877468176.1519369533988
Content-Type: text/plain; charset="UTF-8"

On Friday, February 23, 2018 at 12:19:01 AM UTC-5, jsaintm...@gmail.com
wrote:
>
> The compiler may check the structure of a pseudo const is such :
> -calls to methods A
> -const or pseudo const calls
> -calls to reverse methods A, in reverse
> In the declaration of reverse methods, you may write the prototype of
> first method, then the prototype of the reverse method, appended with
> "reverse" + prototype of the original method
>

That guarantees squat. Nothing guarantees that `A` and `reverse_A` are
actually proper inverse operations. Nothing guarantees that they can
operate recursively (that you can call a "pseudoconst" method that performs
its own `A` and `reverse_A`).

Again, compare that to `const`. Outside of `const_cast` or C-style casts,
you *cannot* violate the restrictions of `const`. There's no point where
the compiler goes, "well, I'll trust that the user isn't doing the wrong
thing," except for the parts that explicitly call that out with specific
syntax.

And what of control flow that is more complex than what you describe? Can
you put the `reverse_A` call into a lambda that gets called as part of some
forwarding operation before the termination of your "pseudo-const"
function? If not, why not?

And lastly, you've not provided a single example of where someone would
*need* to actually do this. And I don't mean the artificial example you
gave on SO; I mean something real that you would actually need to do.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b70bf443-bc3b-41ac-9325-bf2456e555ad%40isocpp.org.

------=_Part_4652_877468176.1519369533988
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, February 23, 2018 at 12:19:01 AM UTC-5, jsaintm=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">The compiler may check the structure of a pseudo const is such :<b=
r>-calls to methods A<br>-const or pseudo const calls<br>-calls to reverse =
methods A, in reverse<br>In the declaration of reverse methods, you may wri=
te the prototype of first method, then the prototype of the reverse method,=
 appended with &quot;reverse&quot; + prototype of the original method<br></=
div></blockquote><div><br>That guarantees squat. Nothing guarantees that `A=
` and `reverse_A` are actually proper inverse operations. Nothing guarantee=
s that they can operate recursively (that you can call a &quot;pseudoconst&=
quot; method that performs its own `A` and `reverse_A`).<br><br>Again, comp=
are that to `const`. Outside of `const_cast` or C-style casts, you <i>canno=
t</i> violate the restrictions of `const`. There&#39;s no point where the c=
ompiler goes, &quot;well, I&#39;ll trust that the user isn&#39;t doing the =
wrong thing,&quot; except for the parts that explicitly call that out with =
specific syntax.<br><br>And what of control flow that is more complex than =
what you describe? Can you put the `reverse_A` call into a lambda that gets=
 called as part of some forwarding operation before the termination of your=
 &quot;pseudo-const&quot; function? If not, why not?<br><br>And lastly, you=
&#39;ve not provided a single example of where someone would <i>need</i> to=
 actually do this. And I don&#39;t mean the artificial example you gave on =
SO; I mean something real that you would actually need to do.</div><br></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b70bf443-bc3b-41ac-9325-bf2456e555ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b70bf443-bc3b-41ac-9325-bf2456e555ad=
%40isocpp.org</a>.<br />

------=_Part_4652_877468176.1519369533988--

------=_Part_4651_843108486.1519369533988--

.

------=_Part_4636_1071459161.1519373828381
Content-Type: multipart/alternative;
 boundary="----=_Part_4637_2066792414.1519373828382"

------=_Part_4637_2066792414.1519373828382
Content-Type: text/plain; charset="UTF-8"


1) checking method A and reverse_A are actually reverse would be the work
of the developer and debogger
2) I don't know
3) example, no sources. But in the compression tool I am trying to create,
I am applying an elementary compression many times. To choose the best
elementary compression, I would like to try it without copying the whole
file, so be able to revert it, and my method of elementary compression
could be pseudo const

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d108c82b-b76b-4d04-adf8-665ea444a98e%40isocpp.org.

------=_Part_4637_2066792414.1519373828382
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>1) checking method A and reverse_A are actually revers=
e would be the work of the developer and debogger<br>2) I don&#39;t know<br=
>3) example, no sources. But in the compression tool I am trying to create,=
 I am applying an elementary compression many times. To choose the best ele=
mentary compression, I would like to try it without copying the whole file,=
 so be able to revert it, and my method of elementary compression could be =
pseudo const<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d108c82b-b76b-4d04-adf8-665ea444a98e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d108c82b-b76b-4d04-adf8-665ea444a98e=
%40isocpp.org</a>.<br />

------=_Part_4637_2066792414.1519373828382--

------=_Part_4636_1071459161.1519373828381--

.

------=_Part_4855_1838329708.1519374141229
Content-Type: multipart/alternative;
 boundary="----=_Part_4856_475910366.1519374141229"

------=_Part_4856_475910366.1519374141229
Content-Type: text/plain; charset="UTF-8"

rectification : the method trying the different elementary compressions
could be pseudo const

On Friday, February 23, 2018 at 9:17:08 AM UTC+1, jsaintm...@gmail.com
wrote:
>
>
> 1) checking method A and reverse_A are actually reverse would be the work
> of the developer and debogger
> 2) I don't know
> 3) example, no sources. But in the compression tool I am trying to create,
> I am applying an elementary compression many times. To choose the best
> elementary compression, I would like to try it without copying the whole
> file, so be able to revert it, and my method of elementary compression
> could be pseudo const
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b8c5769-e0c0-4c16-86cb-13c8308157d8%40isocpp.org.

------=_Part_4856_475910366.1519374141229
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">rectification : the method trying the different elementary=
 compressions could be pseudo const<br><br>On Friday, February 23, 2018 at =
9:17:08 AM UTC+1, jsaintm...@gmail.com wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><br>1) checking method A and reverse_A are =
actually reverse would be the work of the developer and debogger<br>2) I do=
n&#39;t know<br>3) example, no sources. But in the compression tool I am tr=
ying to create, I am applying an elementary compression many times. To choo=
se the best elementary compression, I would like to try it without copying =
the whole file, so be able to revert it, and my method of elementary compre=
ssion could be pseudo const<br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b8c5769-e0c0-4c16-86cb-13c8308157d8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b8c5769-e0c0-4c16-86cb-13c8308157d8=
%40isocpp.org</a>.<br />

------=_Part_4856_475910366.1519374141229--

------=_Part_4855_1838329708.1519374141229--

.

------=_Part_4837_1078473934.1519374432335
Content-Type: multipart/alternative;
 boundary="----=_Part_4838_1535854275.1519374432335"

------=_Part_4838_1535854275.1519374432335
Content-Type: text/plain; charset="UTF-8"

On Friday, February 23, 2018 at 3:17:08 AM UTC-5, jsaintm...@gmail.com
wrote:
>
>
> 1) checking method A and reverse_A are actually reverse would be the work
> of the developer and debogger
>

So why is it part of the type system? If the compiler can't actually
promise anything, why is it there?

2) I don't know
>
3) example, no sources. But in the compression tool I am trying to create,
> I am applying an elementary compression many times. To choose the best
> elementary compression, I would like to try it without copying the whole
> file, so be able to revert it, and my method of elementary compression
> could be pseudo const
>

`const` serves needs. It allows you to specify that an interface will not
modify the object, so that users can choose to use that interface if they
wish to leave the object unmodified. It allows the compiler to *ensure*
that interfaces that are specified to leave the object unmodified will
actually do so, This allows users to trust that `const` means `const`.

`const` as a type qualifier also permits the possibility of constant
forwarding, the way that a `const vector<int>`'s begin/end functions return
`const_iterator`s, due to overload resolution. And so forth.

You say that such a function can be declared "pseudo-const". OK sure. But
what would that *gain* users? What would you as the caller of such a
function be able to do which you could not before? And why is it important
to be able to do so?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27b5c95c-5b44-4089-bb14-b2d1b806093b%40isocpp.org.

------=_Part_4838_1535854275.1519374432335
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, February 23, 2018 at 3:17:08 AM UTC-5, jsaintm.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br>1) checking method A and reverse_A are actually reverse would be =
the work of the developer and debogger<br></div></blockquote><div><br>So wh=
y is it part of the type system? If the compiler can&#39;t actually promise=
 anything, why is it there?<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">2) I don&#39;t know<br></div></blockquote><div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">3) exam=
ple, no sources. But in the compression tool I am trying to create, I am ap=
plying an elementary compression many times. To choose the best elementary =
compression, I would like to try it without copying the whole file, so be a=
ble to revert it, and my method of elementary compression could be pseudo c=
onst<br></div></blockquote><div><br>`const` serves needs. It allows you to =
specify that an interface will not modify the object, so that users can cho=
ose to use that interface if they wish to leave the object unmodified. It a=
llows the compiler to <i>ensure</i> that interfaces that are specified to l=
eave the object unmodified will actually do so, This allows users to trust =
that `const` means `const`.<br><br>`const` as a type qualifier also permits=
 the possibility of constant forwarding, the way that a `const vector&lt;in=
t&gt;`&#39;s begin/end functions return `const_iterator`s, due to overload =
resolution. And so forth.<br><br>You say that such a function can be declar=
ed &quot;pseudo-const&quot;. OK sure. But what would that <i>gain</i> users=
? What would you as the caller of such a function be able to do which you c=
ould not before? And why is it important to be able to do so?<br></div></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/27b5c95c-5b44-4089-bb14-b2d1b806093b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/27b5c95c-5b44-4089-bb14-b2d1b806093b=
%40isocpp.org</a>.<br />

------=_Part_4838_1535854275.1519374432335--

------=_Part_4837_1078473934.1519374432335--

.

--001a11c012488fe3e60565dd5d38
Content-Type: text/plain; charset="UTF-8"

pseudo const Is an indication to users : "the method should not change the
object".

On Fri, Feb 23, 2018 at 9:27 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Friday, February 23, 2018 at 3:17:08 AM UTC-5, jsaintm...@gmail.com
> wrote:
>>
>>
>> 1) checking method A and reverse_A are actually reverse would be the work
>> of the developer and debogger
>>
>
> So why is it part of the type system? If the compiler can't actually
> promise anything, why is it there?
>
> 2) I don't know
>>
> 3) example, no sources. But in the compression tool I am trying to create,
>> I am applying an elementary compression many times. To choose the best
>> elementary compression, I would like to try it without copying the whole
>> file, so be able to revert it, and my method of elementary compression
>> could be pseudo const
>>
>
> `const` serves needs. It allows you to specify that an interface will not
> modify the object, so that users can choose to use that interface if they
> wish to leave the object unmodified. It allows the compiler to *ensure*
> that interfaces that are specified to leave the object unmodified will
> actually do so, This allows users to trust that `const` means `const`.
>
> `const` as a type qualifier also permits the possibility of constant
> forwarding, the way that a `const vector<int>`'s begin/end functions return
> `const_iterator`s, due to overload resolution. And so forth.
>
> You say that such a function can be declared "pseudo-const". OK sure. But
> what would that *gain* users? What would you as the caller of such a
> function be able to do which you could not before? And why is it important
> to be able to do so?
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/27b5c95c-5b44-4089-
> bb14-b2d1b806093b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27b5c95c-5b44-4089-bb14-b2d1b806093b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEY%2BwHXvW-WaiOiV09t3%3DhoPCdruR-VPGULNixvuvJdF7A%40mail.gmail.com.

--001a11c012488fe3e60565dd5d38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">pseudo const Is an indication to users : &quot;the method =
should not change the object&quot;. <br></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Fri, Feb 23, 2018 at 9:27 AM, Nicol Bolas <=
span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blan=
k">jmckesson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><span class=3D"">On Friday, February 23, 2018 at 3:17:=
08 AM UTC-5, <a href=3D"mailto:jsaintm...@gmail.com" target=3D"_blank">jsai=
ntm...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><br>1) checking method A and reverse_A are actually reverse would =
be the work of the developer and debogger<br></div></blockquote></span><div=
><br>So why is it part of the type system? If the compiler can&#39;t actual=
ly promise anything, why is it there?<br><br></div><span class=3D""><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">2) I don&#39;t know<br></=
div></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">3) example, no sources. But in the compression tool I am trying t=
o create, I am applying an elementary compression many times. To choose the=
 best elementary compression, I would like to try it without copying the wh=
ole file, so be able to revert it, and my method of elementary compression =
could be pseudo const<br></div></blockquote></span><div><br>`const` serves =
needs. It allows you to specify that an interface will not modify the objec=
t, so that users can choose to use that interface if they wish to leave the=
 object unmodified. It allows the compiler to <i>ensure</i> that interfaces=
 that are specified to leave the object unmodified will actually do so, Thi=
s allows users to trust that `const` means `const`.<br><br>`const` as a typ=
e qualifier also permits the possibility of constant forwarding, the way th=
at a `const vector&lt;int&gt;`&#39;s begin/end functions return `const_iter=
ator`s, due to overload resolution. And so forth.<br><br>You say that such =
a function can be declared &quot;pseudo-const&quot;. OK sure. But what woul=
d that <i>gain</i> users? What would you as the caller of such a function b=
e able to do which you could not before? And why is it important to be able=
 to do so?<br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/27b5c95c-5b44-4089-bb14-b2d1b806093b%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/27b5=
c95c-5b44-4089-<wbr>bb14-b2d1b806093b%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC4OUEY%2BwHXvW-WaiOiV09t3%3DhoPCdru=
R-VPGULNixvuvJdF7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC4OUEY%2BwH=
XvW-WaiOiV09t3%3DhoPCdruR-VPGULNixvuvJdF7A%40mail.gmail.com</a>.<br />

--001a11c012488fe3e60565dd5d38--

.

------=_Part_5100_55630326.1519378400026
Content-Type: multipart/alternative;
 boundary="----=_Part_5101_1148802290.1519378400026"

------=_Part_5101_1148802290.1519378400026
Content-Type: text/plain; charset="UTF-8"

"...but thats not guaranteed by compiler"

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7aee40ab-50fe-426a-8e12-4c7089ebe085%40isocpp.org.

------=_Part_5101_1148802290.1519378400026
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&quot;...but thats not guaranteed by compiler&quot;<br><br=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7aee40ab-50fe-426a-8e12-4c7089ebe085%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7aee40ab-50fe-426a-8e12-4c7089ebe085=
%40isocpp.org</a>.<br />

------=_Part_5101_1148802290.1519378400026--

------=_Part_5100_55630326.1519378400026--

.

------=_Part_5000_172781176.1519380482243
Content-Type: multipart/alternative;
 boundary="----=_Part_5001_946160963.1519380482243"

------=_Part_5001_946160963.1519380482243
Content-Type: text/plain; charset="UTF-8"


Or  the exact indication to the user could be "this method should leave the
object unchanged, but that was not completedly checked by compiler"
On Friday, February 23, 2018 at 10:33:20 AM UTC+1, jsaintm...@gmail.com
wrote:
>
> "...but thats not guaranteed by compiler"
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/39c51ced-6415-444b-8332-fa90d75cef72%40isocpp.org.

------=_Part_5001_946160963.1519380482243
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Or=C2=A0 the exact indication to the user could be &qu=
ot;this method should leave the object unchanged, but that was not complete=
dly checked by compiler&quot;<br>On Friday, February 23, 2018 at 10:33:20 A=
M UTC+1, jsaintm...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">&quot;...but thats not guaranteed by compiler&quot;<=
br><br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/39c51ced-6415-444b-8332-fa90d75cef72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/39c51ced-6415-444b-8332-fa90d75cef72=
%40isocpp.org</a>.<br />

------=_Part_5001_946160963.1519380482243--

------=_Part_5000_172781176.1519380482243--

.

------=_Part_5306_2129041524.1519382199642
Content-Type: multipart/alternative;
 boundary="----=_Part_5307_524512243.1519382199642"

------=_Part_5307_524512243.1519382199642
Content-Type: text/plain; charset="UTF-8"

Then, how is it different to have it written in the documentation of the
interface?

If it's only to tell the user without any of checking or enforcing it is
used right, then there is no point to have a language feature for that.

BTW, when (if ever) we have contract based programming, you will be able to
do exactly that (and much more) directly.
I don't remember any syntax, but this would be a post-condition similar to:
*previous_this == *this

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f798c76d-828a-41ae-afa8-da478a93b781%40isocpp.org.

------=_Part_5307_524512243.1519382199642
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Then, how is it different to have it written in the docume=
ntation of the interface?<br><br>If it&#39;s only to tell the user without =
any of checking or enforcing it is used right, then there is no point to ha=
ve a language feature for that.<br><br>BTW, when (if ever) we have contract=
 based programming, you will be able to do exactly that (and much more) dir=
ectly.<br>I don&#39;t remember any syntax, but this would be a post-conditi=
on similar to: *previous_this =3D=3D *this<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f798c76d-828a-41ae-afa8-da478a93b781%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f798c76d-828a-41ae-afa8-da478a93b781=
%40isocpp.org</a>.<br />

------=_Part_5307_524512243.1519382199642--

------=_Part_5306_2129041524.1519382199642--

.

--=-DLqhO74+gx8q/nVksC1/
Content-Type: multipart/alternative; boundary="=-e8wceeKzzq6NROxgUDrA"


--=-e8wceeKzzq6NROxgUDrA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2018-02-23 at 09:58 +0100, J=C3=A9r=C3=B4me Saint-Martin wrote:
> pseudo const Is an indication to users : "the method should not
> change the object".=20

This is the indication/guarantee that const already provides. The
pseudoness of the guarantee is an implementation detail, achieved
through the mutable keyword which exists for this very purpose.
I am unconvinced of the merits of this proposal.
My reasoning is as follows:
1. The concept of psudo-constness already exists and is already
trivially expressible in the language.=20
2. Advertising a method as "pseudo const" merely leaks implementation
information to the caller, which is an anti-pattern.
R

> On Fri, Feb 23, 2018 at 9:27 AM, Nicol Bolas <jmckesson@gmail.com>
> wrote:
> > On Friday, February 23, 2018 at 3:17:08 AM UTC-5, jsaintm...@gmail.
> > com wrote:
> > > 1) checking method A and reverse_A are actually reverse would be
> > > the work of the developer and debogger
> >=20
> > So why is it part of the type system? If the compiler can't
> > actually promise anything, why is it there?
> >=20
> > > 2) I don't know
> > >=20
> > > 3) example, no sources. But in the compression tool I am trying
> > > to create, I am applying an elementary compression many times. To
> > > choose the best elementary compression, I would like to try it
> > > without copying the whole file, so be able to revert it, and my
> > > method of elementary compression could be pseudo const
> >=20
> > `const` serves needs. It allows you to specify that an interface
> > will not modify the object, so that users can choose to use that
> > interface if they wish to leave the object unmodified. It allows
> > the compiler to ensure that interfaces that are specified to leave
> > the object unmodified will actually do so, This allows users to
> > trust that `const` means `const`.
> >=20
> > `const` as a type qualifier also permits the possibility of
> > constant forwarding, the way that a `const vector<int>`'s begin/end
> > functions return `const_iterator`s, due to overload resolution. And
> > so forth.
> >=20
> > You say that such a function can be declared "pseudo-const". OK
> > sure. But what would that gain users? What would you as the caller
> > of such a function be able to do which you could not before? And
> > why is it important to be able to do so?
> >=20
> >=20
> >=20
> >=20
> >=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1519382293.58210.28.camel%40gmail.com.

--=-e8wceeKzzq6NROxgUDrA
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div>On Fri, 2018-02-23 at 09:58 +0100, J=C3=A9r=
=C3=B4me Saint-Martin wrote:</div><blockquote type=3D"cite" style=3D"margin=
:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir=3D"lt=
r">pseudo const Is an indication to users : "the method should not change t=
he object". <br></div></blockquote><div><br></div><div>This is the indicati=
on/guarantee that const already provides. The pseudoness of the guarantee i=
s an implementation detail, achieved through the mutable keyword which exis=
ts for this very purpose.</div><div><br></div><div>I am unconvinced of the =
merits of this proposal.</div><div><br></div><div>My reasoning is as follow=
s:</div><div><br></div><div>1. The concept of psudo-constness already exist=
s and is already trivially expressible in the language.&nbsp;</div><div><br=
></div><div>2. Advertising a method as "pseudo const" merely leaks implemen=
tation information to the caller, which is an anti-pattern.</div><div><br><=
/div><div>R</div><div><br></div><div><br></div><blockquote type=3D"cite" st=
yle=3D"margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Feb 23, 20=
18 at 9:27 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesso=
n@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br=
><blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-left:2px #729=
fcf solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Friday, Fe=
bruary 23, 2018 at 3:17:08 AM UTC-5, <a href=3D"mailto:jsaintm...@gmail.com=
" target=3D"_blank">jsaintm...@gmail.com</a> wrote:<blockquote type=3D"cite=
" style=3D"margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1e=
x"><div dir=3D"ltr"><br>1) checking method A and reverse_A are actually rev=
erse would be the work of the developer and debogger<br></div></blockquote>=
</span><div><br>So why is it part of the type system? If the compiler can't=
 actually promise anything, why is it there?<br><br></div><span class=3D"">=
<blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-left:2px #729f=
cf solid;padding-left:1ex"><div dir=3D"ltr">2) I don't know<br></div><br></=
blockquote><div></div><blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex;=
 border-left:2px #729fcf solid;padding-left:1ex"><div dir=3D"ltr">3) exampl=
e, no sources. But in the compression tool I am trying to create, I am appl=
ying an elementary compression many times. To choose the best elementary co=
mpression, I would like to try it without copying the whole file, so be abl=
e to revert it, and my method of elementary compression could be pseudo con=
st<br></div></blockquote></span><div><br>`const` serves needs. It allows yo=
u to specify that an interface will not modify the object, so that users ca=
n choose to use that interface if they wish to leave the object unmodified.=
 It allows the compiler to <i>ensure</i> that interfaces that are specified=
 to leave the object unmodified will actually do so, This allows users to t=
rust that `const` means `const`.<br><br>`const` as a type qualifier also pe=
rmits the possibility of constant forwarding, the way that a `const vector&=
lt;int&gt;`'s begin/end functions return `const_iterator`s, due to overload=
 resolution. And so forth.<br><br>You say that such a function can be decla=
red "pseudo-const". OK sure. But what would that <i>gain</i> users? What wo=
uld you as the caller of such a function be able to do which you could not =
before? And why is it important to be able to do so?<br></div></div><span c=
lass=3D"">

<p></p>

</span></blockquote></div></div></blockquote></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1519382293.58210.28.camel%40gmail.com=
?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1519382293.58210.28.camel%40gmail.com</a>.<br />

--=-e8wceeKzzq6NROxgUDrA--

--=-DLqhO74+gx8q/nVksC1/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE3RJb20ryY2ALx0Tw6HZ1IvK3CgsFAlqP7xUACgkQ6HZ1IvK3
CgszChAAsU8TYRQaKomrG/Ua09CM0Yl7nEAZYi9JAauVf0kNLSuS12hihXEgZukJ
KLokBxlqgfGxRtVQ1S00RnjpjpuCFXY51w7ut2B9ULo6A5REAushFBMSrhKnoEuV
MkK2YvNILBou8aK1kP5SEhXZjGYOsSjm5vBX8xT+r7dMQZ4aWzrQMtyz6oTbolKb
5c5uSPkeA4tRZGXU0ZBEqjebWetjDcJm6UAvVvnB7ilHqs6y2HIK6rWHI9/fAsRH
7KflgYYkkeOkkbKDzW7VSQNkCYw5tbgFPJrKlcwS599R3XdlUDfX8tzpFKjA/2Y5
7SGvNn01EkOGJTPMmJKhQgyQVuZ7ACSf6lTXU7v34tvf488jqPHiVLezSf2Ja1p5
kmaXsAeqYNY6JmE/bdMp8snTd2+DFEadPsI9f5NiPbcdLkqWyh3ebVz1zsqyAiVn
8v0TmxYMeSRfGUHSmdcu/s7LXlnR+TEYjl4hRV2NJi7R/z4uoeY7EiHcaNkB96xe
6UCl2+qbIw3/vsBhAv5Xjw9CU+FDsyspCup4/SJHidlfdPntxE1Wkpatz1jcAW5Z
2Flsc/gDXLy0nxWXie+s0lOMce7Dzc5QkscHvBEuyYFXHUNm5KYUFnmhaG1r2c8A
7WZ0jV03VhNU2OcmhezE5XEcbLxjpSTo5o260RSVTpXqjHocx5s=
=XQpZ
-----END PGP SIGNATURE-----

--=-DLqhO74+gx8q/nVksC1/--


.

------=_Part_5182_268944916.1519383573477
Content-Type: multipart/alternative;
 boundary="----=_Part_5183_478836873.1519383573477"

------=_Part_5183_478836873.1519383573477
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The interest of a pseudo const method is to comfort the user and still have=
=20
good performance : "this method should normally be const, but for reasons=
=20
of performance, it's just pseudo const. Use at your peril"

On Friday, February 23, 2018 at 11:38:23 AM UTC+1, Richard Hodges wrote:
>
> On Fri, 2018-02-23 at 09:58 +0100, J=C3=A9r=C3=B4me Saint-Martin wrote:
>
> pseudo const Is an indication to users : "the method should not change th=
e=20
> object".=20
>
>
> This is the indication/guarantee that const already provides. The=20
> pseudoness of the guarantee is an implementation detail, achieved through=
=20
> the mutable keyword which exists for this very purpose.
>
> I am unconvinced of the merits of this proposal.
>
> My reasoning is as follows:
>
> 1. The concept of psudo-constness already exists and is already trivially=
=20
> expressible in the language.=20
>
> 2. Advertising a method as "pseudo const" merely leaks implementation=20
> information to the caller, which is an anti-pattern.
>
> R
>
>
>
> On Fri, Feb 23, 2018 at 9:27 AM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
> On Friday, February 23, 2018 at 3:17:08 AM UTC-5, jsaintm...@gmail.com=20
> wrote:
>
>
> 1) checking method A and reverse_A are actually reverse would be the work=
=20
> of the developer and debogger
>
>
> So why is it part of the type system? If the compiler can't actually=20
> promise anything, why is it there?
>
> 2) I don't know
>
> 3) example, no sources. But in the compression tool I am trying to create=
,=20
> I am applying an elementary compression many times. To choose the best=20
> elementary compression, I would like to try it without copying the whole=
=20
> file, so be able to revert it, and my method of elementary compression=20
> could be pseudo const
>
>
> `const` serves needs. It allows you to specify that an interface will not=
=20
> modify the object, so that users can choose to use that interface if they=
=20
> wish to leave the object unmodified. It allows the compiler to *ensure*=
=20
> that interfaces that are specified to leave the object unmodified will=20
> actually do so, This allows users to trust that `const` means `const`.
>
> `const` as a type qualifier also permits the possibility of constant=20
> forwarding, the way that a `const vector<int>`'s begin/end functions retu=
rn=20
> `const_iterator`s, due to overload resolution. And so forth.
>
> You say that such a function can be declared "pseudo-const". OK sure. But=
=20
> what would that *gain* users? What would you as the caller of such a=20
> function be able to do which you could not before? And why is it importan=
t=20
> to be able to do so?
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/371a1db1-656d-44c5-a6fc-2e2e83a55cf1%40isocpp.or=
g.

------=_Part_5183_478836873.1519383573477
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The interest of a pseudo const method is to comfort the us=
er and still have good performance : &quot;this method should normally be c=
onst, but for reasons of performance, it&#39;s just pseudo const. Use at yo=
ur peril&quot;<br><br>On Friday, February 23, 2018 at 11:38:23 AM UTC+1, Ri=
chard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div>O=
n Fri, 2018-02-23 at 09:58 +0100, J=C3=A9r=C3=B4me Saint-Martin wrote:</div=
><blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex;border-left:2px #729f=
cf solid;padding-left:1ex"><div dir=3D"ltr">pseudo const Is an indication t=
o users : &quot;the method should not change the object&quot;. <br></div></=
blockquote><div><br></div><div>This is the indication/guarantee that const =
already provides. The pseudoness of the guarantee is an implementation deta=
il, achieved through the mutable keyword which exists for this very purpose=
..</div><div><br></div><div>I am unconvinced of the merits of this proposal.=
</div><div><br></div><div>My reasoning is as follows:</div><div><br></div><=
div>1. The concept of psudo-constness already exists and is already trivial=
ly expressible in the language.=C2=A0</div><div><br></div><div>2. Advertisi=
ng a method as &quot;pseudo const&quot; merely leaks implementation informa=
tion to the caller, which is an anti-pattern.</div><div><br></div><div>R</d=
iv><div><br></div><div><br></div><blockquote type=3D"cite" style=3D"margin:=
0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div><br><div cl=
ass=3D"gmail_quote">On Fri, Feb 23, 2018 at 9:27 AM, Nicol Bolas <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"3zUEv7U8AAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote type=3D"cite=
" style=3D"margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex=
"><div dir=3D"ltr"><span>On Friday, February 23, 2018 at 3:17:08 AM UTC-5, =
<a>jsaintm...@gmail.com</a> wrote:<blockquote type=3D"cite" style=3D"margin=
:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir=3D"ltr=
"><br>1) checking method A and reverse_A are actually reverse would be the =
work of the developer and debogger<br></div></blockquote></span><div><br>So=
 why is it part of the type system? If the compiler can&#39;t actually prom=
ise anything, why is it there?<br><br></div><span><blockquote type=3D"cite"=
 style=3D"margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"=
><div dir=3D"ltr">2) I don&#39;t know<br></div><br></blockquote><div></div>=
<blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex;border-left:2px #729fc=
f solid;padding-left:1ex"><div dir=3D"ltr">3) example, no sources. But in t=
he compression tool I am trying to create, I am applying an elementary comp=
ression many times. To choose the best elementary compression, I would like=
 to try it without copying the whole file, so be able to revert it, and my =
method of elementary compression could be pseudo const<br></div></blockquot=
e></span><div><br>`const` serves needs. It allows you to specify that an in=
terface will not modify the object, so that users can choose to use that in=
terface if they wish to leave the object unmodified. It allows the compiler=
 to <i>ensure</i> that interfaces that are specified to leave the object un=
modified will actually do so, This allows users to trust that `const` means=
 `const`.<br><br>`const` as a type qualifier also permits the possibility o=
f constant forwarding, the way that a `const vector&lt;int&gt;`&#39;s begin=
/end functions return `const_iterator`s, due to overload resolution. And so=
 forth.<br><br>You say that such a function can be declared &quot;pseudo-co=
nst&quot;. OK sure. But what would that <i>gain</i> users? What would you a=
s the caller of such a function be able to do which you could not before? A=
nd why is it important to be able to do so?<br></div></div><span>

<p></p>

</span></blockquote></div></div></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/371a1db1-656d-44c5-a6fc-2e2e83a55cf1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/371a1db1-656d-44c5-a6fc-2e2e83a55cf1=
%40isocpp.org</a>.<br />

------=_Part_5183_478836873.1519383573477--

------=_Part_5182_268944916.1519383573477--

.

--f403043ebce0c48ed80565df75be
Content-Type: text/plain; charset="UTF-8"

On 23 Feb 2018 10:59, <jsaintmartin356@gmail.com> wrote:

for reasons of performance, it's just pseudo const


[*Citation Needed*]

You're going to have to give an example where this is actually the case.
Because for the example you provided (but benchmarked properly, not a
worthless single iteration run) the pseudo const method provides no gains.
In fact, the const alternative when you don't have to run undo-A is faster.

And again, it could be even faster if you made a view class because you
wouldn't need to copy the entire object - in your example you could create
a "size_t op(const size_t&)" and pass that to the view, only executing op
when a value is actually needed, and this would be executed only once.
There are situations where this isn't as efficient as constructing a new
object, but that still ends up as more efficient than modifying the
original data twice in any situation where it actually matters.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN%2B%3D8VgAzpjDrqjn-_CgkEz_mMokmQQJF92ZuHxSx4Psg%40mail.gmail.com.

--f403043ebce0c48ed80565df75be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 23 Feb 2018 10:59,  &lt;<a href=3D"mailto:jsaintmartin356@gmail.com" t=
arget=3D"_blank">jsaintmartin356@gmail.com</a>&gt; wrote:<br type=3D"attrib=
ution"><blockquote class=3D"m_815624303670679148quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">for re=
asons of performance, it&#39;s just pseudo const</div></blockquote></div></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">[<i>Citation Needed=
</i>]</div><div dir=3D"auto"></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">You&#39;re going to have to give an example where this is actually th=
e case. Because for the example you provided (but benchmarked properly, not=
 a worthless single iteration run) the pseudo const method provides no gain=
s. In fact, the const alternative when you don&#39;t have to run undo-A is =
faster.</div><div dir=3D"auto"><br></div><div dir=3D"auto">And again, it co=
uld be even faster if you made a view class because you wouldn&#39;t need t=
o copy the entire object - in your example you could create a &quot;size_t =
op(const size_t&amp;)&quot; and pass that to the view, only executing op wh=
en a value is actually needed, and this would be executed only once. There =
are situations where this isn&#39;t as efficient as constructing a new obje=
ct, but that still ends up as more efficient than modifying the original da=
ta twice in any situation where it actually matters.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN%2B%3D8VgAzpjDrqjn-_CgkEz_m=
MokmQQJF92ZuHxSx4Psg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN%=
2B%3D8VgAzpjDrqjn-_CgkEz_mMokmQQJF92ZuHxSx4Psg%40mail.gmail.com</a>.<br />

--f403043ebce0c48ed80565df75be--

.

--001a114df622ea07410565e04676
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On 23 Feb 2018 08:58, "J=C3=A9r=C3=B4me Saint-Martin" <jsaintmartin356@gmai=
l.com>
wrote:

pseudo const Is an indication to users : "the method should not change the
object".


*Const* is an *guarantee* to users: the method *does* not change the
object. A pseudoconst method would also have to guarantee this or the
proposal wouldn't be useful at all. So, once again, come up with a way of
guranteeing that a modification is reversed. A "reversible" or similar
keyword would be more interesting. All it needs to do is only permit a
series of commands and functions that are themselves reversible (ones that
lose no information, so type limitations must be considered - see, for
example, http://cpp.sh/9fet5 and http://cpp.sh/9redh ), in the same way
that const only permits use of operations that are also const. Then you
need something built into the language that does the reversing.

This could be useful in a variety of situations. One of which would be an
enforceable pseudoconst.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAC%2B0CCPg3HbEktBJu%2Bx0r2A0xw0Eg7cMUS%3DXSy5gu=
Snr8RfcGA%40mail.gmail.com.

--001a114df622ea07410565e04676
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 23 Feb 2018 08:58, &quot;J=C3=A9r=C3=B4me Saint-Martin&quot; &lt;<a hr=
ef=3D"mailto:jsaintmartin356@gmail.com" target=3D"_blank">jsaintmartin356@g=
mail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"m_-860=
8625336120915442quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">pseudo const Is an indication to users=
 : &quot;the method should not change the object&quot;.=C2=A0</div></blockq=
uote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><i>Con=
st</i> is an <i>guarantee</i> to users: the method <i>does</i>=C2=A0not cha=
nge the object. A pseudoconst method would also have to guarantee this or t=
he proposal wouldn&#39;t be useful at all. So, once again, come up with a w=
ay of guranteeing that a modification is reversed. A &quot;reversible&quot;=
 or similar keyword would be more interesting. All it needs to do is only p=
ermit a series of commands and functions that are themselves reversible (on=
es that lose no information, so type limitations must be considered - see, =
for example, <a href=3D"http://cpp.sh/9fet5">http://cpp.sh/9fet5</a> and <a=
 href=3D"http://cpp.sh/9redh">http://cpp.sh/9redh</a> ), in the same way th=
at const only permits use of operations that are also const. Then you need =
something built into the language that does the reversing.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">This could be useful in a variety of sit=
uations. One of which would be an enforceable pseudoconst.</div><div dir=3D=
"auto"></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPg3HbEktBJu%2Bx0r2A0xw0Eg7cM=
US%3DXSy5guSnr8RfcGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPg=
3HbEktBJu%2Bx0r2A0xw0Eg7cMUS%3DXSy5guSnr8RfcGA%40mail.gmail.com</a>.<br />

--001a114df622ea07410565e04676--

.

------=_Part_5511_46359192.1519396699983
Content-Type: multipart/alternative;
 boundary="----=_Part_5512_935405863.1519396699983"

------=_Part_5512_935405863.1519396699983
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

"reversible" sounds good to me. Attached is the small example I wrote on=20
stack and deleted.


On Friday, February 23, 2018 at 1:27:03 PM UTC+1, Jake Arkinstall wrote:
>
> On 23 Feb 2018 08:58, "J=C3=A9r=C3=B4me Saint-Martin" <jsaintm...@gmail.c=
om=20
> <javascript:>> wrote:
>
> pseudo const Is an indication to users : "the method should not change th=
e=20
> object".=20
>
>
> *Const* is an *guarantee* to users: the method *does* not change the=20
> object. A pseudoconst method would also have to guarantee this or the=20
> proposal wouldn't be useful at all. So, once again, come up with a way of=
=20
> guranteeing that a modification is reversed. A "reversible" or similar=20
> keyword would be more interesting. All it needs to do is only permit a=20
> series of commands and functions that are themselves reversible (ones tha=
t=20
> lose no information, so type limitations must be considered - see, for=20
> example, http://cpp.sh/9fet5=20
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fcpp.sh%2F9fet5&sa=3DD&sntz=3D=
1&usg=3DAFQjCNGsOlE-ePVnks77rm2pF2hvT8zUkA>=20
> and http://cpp.sh/9redh ), in the same way that const only permits use of=
=20
> operations that are also const. Then you need something built into the=20
> language that does the reversing.
>
> This could be useful in a variety of situations. One of which would be an=
=20
> enforceable pseudoconst.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/62115b8c-6c92-4c53-b036-ab4d9e509e0a%40isocpp.or=
g.

------=_Part_5512_935405863.1519396699983
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&quot;reversible&quot; sounds good to me. Attached is the =
small example I wrote on stack and deleted.<br><br><br>On Friday, February =
23, 2018 at 1:27:03 PM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"auto"><div><div><div class=3D"gmail_quote=
">On 23 Feb 2018 08:58, &quot;J=C3=A9r=C3=B4me Saint-Martin&quot; &lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"WqpozgUTAAAJ"=
 rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jsaintm...=
@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>pseudo const Is an indication to users : &quot;the method should not chang=
e the object&quot;.=C2=A0</div></blockquote></div></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto"><i>Const</i> is an <i>guarantee</i> to use=
rs: the method <i>does</i>=C2=A0not change the object. A pseudoconst method=
 would also have to guarantee this or the proposal wouldn&#39;t be useful a=
t all. So, once again, come up with a way of guranteeing that a modificatio=
n is reversed. A &quot;reversible&quot; or similar keyword would be more in=
teresting. All it needs to do is only permit a series of commands and funct=
ions that are themselves reversible (ones that lose no information, so type=
 limitations must be considered - see, for example, <a href=3D"http://www.g=
oogle.com/url?q=3Dhttp%3A%2F%2Fcpp.sh%2F9fet5&amp;sa=3DD&amp;sntz=3D1&amp;u=
sg=3DAFQjCNGsOlE-ePVnks77rm2pF2hvT8zUkA" target=3D"_blank" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%=
2Fcpp.sh%2F9fet5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGsOlE-ePVnks77rm2p=
F2hvT8zUkA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fcpp.sh%2F9fet5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNGsOlE-ePVnks77rm2pF2hvT8zUkA&#39;;return true;">http://cpp.sh/9fet5<=
/a> and <a href=3D"http://cpp.sh/9redh" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2=
Fcpp.sh%2F9redh\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXDPCUOcwWbKeaQxa7t=
7nZSpb9VQ&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fcpp.sh%2F9redh\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNGXDPCUOcwWbKeaQxa7t7nZSpb9VQ&#39;;return true;">http://cpp.sh/9redh</=
a> ), in the same way that const only permits use of operations that are al=
so const. Then you need something built into the language that does the rev=
ersing.</div><div dir=3D"auto"><br></div><div dir=3D"auto">This could be us=
eful in a variety of situations. One of which would be an enforceable pseud=
oconst.</div><div dir=3D"auto"></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/62115b8c-6c92-4c53-b036-ab4d9e509e0a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62115b8c-6c92-4c53-b036-ab4d9e509e0a=
%40isocpp.org</a>.<br />

------=_Part_5512_935405863.1519396699983--

------=_Part_5511_46359192.1519396699983
Content-Type: text/x-c++src; charset=US-ASCII; name=Reversible.cpp
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=Reversible.cpp
X-Attachment-Id: 57a72aed-ce20-441d-bad0-000963ca021c
Content-ID: <57a72aed-ce20-441d-bad0-000963ca021c>

#include <iostream>
#include <vector>
#include <algorithm>

class Vec {
public :
  Vec () : val_ (std::vector<size_t> (1000, 0)) {}
  Vec (const Vec& v) : val_ (v.val_) {}
  ~Vec () {}
  // couple of reverse methods
  void inc () {
    std::for_each (val_.begin (), val_.end (), [] (size_t&s) {++s;});
  }
  void dec () /* keyword : reverse inc () */ {
    std::for_each (val_.begin (), val_.end (), [] (size_t&s) {--s;});
  }

  void write2 (std::ostream& os) const {
    os << "val_ [2] == " << val_ [2] << std::endl;
  }
  void write_next2const (std::ostream& os) const {
    Vec v (*this);
    v.inc ();
    v.write2 (os);
  }
  void write_next2reversible (std::ostream& os) { //reversible keyword ?
    inc ();
    write2 (os);
    dec ();
  }

//private :
  std::vector<size_t> val_;
};

int main (int argc, char* argv []) {
  size_t duration (0);
  Vec v;
  clock_t t (clock ());
  v.write_next2const (std::cout);
  duration = (clock() - t);
  std::cout << "write_next2const took " << duration << " ticks" << std::endl;

  t = clock ();
  v.write_next2reversible (std::cout);
  duration = (clock() - t);
  std::cout << "write_next2reversible took " << duration << " ticks" << std::endl;
  return 0;
}


------=_Part_5511_46359192.1519396699983--

.

On 23 February 2018 at 16:38,  <jsaintmartin356@gmail.com> wrote:
> "reversible" sounds good to me. Attached is the small example I wrote on
> stack and deleted.

I don't know what sort of a reversible example that is, because it's
not exception-safe. Is that intentional?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZN2CBB9knsvfSCUvy%3D%3DWSZ%3DTaROfSCpt%2B5x1JGARzi2g%40mail.gmail.com.

.

------=_Part_5923_363724738.1519398125362
Content-Type: multipart/alternative;
 boundary="----=_Part_5924_802910218.1519398125363"

------=_Part_5924_802910218.1519398125363
Content-Type: text/plain; charset="UTF-8"

nope , was just a first example, showing reversible is faster than const

On Friday, February 23, 2018 at 3:44:40 PM UTC+1, Ville Voutilainen wrote:
>
> On 23 February 2018 at 16:38,  <jsaintm...@gmail.com <javascript:>>
> wrote:
> > "reversible" sounds good to me. Attached is the small example I wrote on
> > stack and deleted.
>
> I don't know what sort of a reversible example that is, because it's
> not exception-safe. Is that intentional?
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af%40isocpp.org.

------=_Part_5924_802910218.1519398125363
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">nope , was just a first example, showing reversible is fas=
ter than const<br><br>On Friday, February 23, 2018 at 3:44:40 PM UTC+1, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 23 Feb=
ruary 2018 at 16:38, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"oFHXKIgaAAAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">jsaintm...@gmail.com</a>&gt; wrote:
<br>&gt; &quot;reversible&quot; sounds good to me. Attached is the small ex=
ample I wrote on
<br>&gt; stack and deleted.
<br>
<br>I don&#39;t know what sort of a reversible example that is, because it&=
#39;s
<br>not exception-safe. Is that intentional?
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af=
%40isocpp.org</a>.<br />

------=_Part_5924_802910218.1519398125363--

------=_Part_5923_363724738.1519398125362--

.

--f403043ebce079b07b0565e2a5d7
Content-Type: text/plain; charset="UTF-8"

If you require that the operation is reversible, you probably shouldn't
trust the source blindly.

The idea is more along the lines of

void inc(T x) reversible{
    // ....
}

void dec(T x) reversible{
    reverse(inc)(x);
}

Where we can assume reverse(reverse(f)) is reduced to f, for some method f.
The reversible keyword informs the compiler that the method should be split
into statements, and each such statement must be reversible (i.e. is a
method that has the 'reversible' keyword). Each statement is reversed and
iterated back-to-front when the reverse() method (or some arbitrary syntax)
is called on a method. In other words, the user doesn't explicitly define
the reverse (users cannot be trusted, which is exactly why const enforces
const). This propogates all the way down to fundamental operations, so at
some point the reverse of those operations need to be defined - but by the
language, not by the user.

Then RAII could be exploited to ensure that a pseudoconst method really
undoes the initial operation:

void nonconst_example() pseudoconst{
    Transformer t(this, inc); // transformation is performed
    // do what you as long as it's const
} // t::~t() is called, undoing the transformation.

It's a bit of a strange idea, but it's the only way that I can think of
that allows pseudoconst to be reliable.

On Fri, Feb 23, 2018 at 2:44 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 23 February 2018 at 16:38,  <jsaintmartin356@gmail.com> wrote:
> > "reversible" sounds good to me. Attached is the small example I wrote on
> > stack and deleted.
>
> I don't know what sort of a reversible example that is, because it's
> not exception-safe. Is that intentional?
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAFk2RUZN2CBB9knsvfSCUvy%3D%
> 3DWSZ%3DTaROfSCpt%2B5x1JGARzi2g%40mail.gmail.com.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNjdqR71HxudOvyOUDMCaoGp0ug%3Dv5ub0_bM12_QPD3kg%40mail.gmail.com.

--f403043ebce079b07b0565e2a5d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>If you require that the operation is r=
eversible, you probably shouldn&#39;t trust the source blindly.<br><br></di=
v>The idea is more along the lines of<br><br></div>void inc(T x) reversible=
{<br>=C2=A0=C2=A0=C2=A0 // ....<br>}<br><br></div><div>void dec(T x) revers=
ible{<br></div><div>=C2=A0=C2=A0=C2=A0 reverse(inc)(x);<br></div><div>}<br>=
</div><div><br></div><div>Where we can assume reverse(reverse(f)) is reduce=
d to f, for some method f. The reversible keyword
 informs the compiler that the method should be split into statements,=20
and each such statement must be reversible (i.e. is a method that has=20
the &#39;reversible&#39; keyword). Each statement is reversed and iterated=
=20
back-to-front when the reverse() method (or some arbitrary syntax) is=20
called on a method. In other words, the user doesn&#39;t explicitly define=
=20
the reverse (users cannot be trusted, which is exactly why const=20
enforces const). This propogates all the way down to fundamental=20
operations, so at some point the reverse of those operations need to be=20
defined - but by the language, not by the user.<br><br></div><div>Then RAII=
 could be exploited to ensure that a pseudoconst method really undoes the i=
nitial operation:<br></div><div><br></div>void nonconst_example() pseudocon=
st{<br></div><div>=C2=A0=C2=A0=C2=A0 Transformer t(this, inc); // transform=
ation is performed<br></div><div>=C2=A0 =C2=A0 // do what you as long as it=
&#39;s const<br></div><div>} // t::~t() is called, undoing the transformati=
on.<br><br></div><div>It&#39;s a bit of a strange idea, but it&#39;s the on=
ly way that I can think of that allows pseudoconst to be reliable.<br></div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Fe=
b 23, 2018 at 2:44 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On 23 February 2018 at 16:38,=C2=A0 &lt;<a href=3D"mailto:jsaintmarti=
n356@gmail.com">jsaintmartin356@gmail.com</a>&gt; wrote:<br>
&gt; &quot;reversible&quot; sounds good to me. Attached is the small exampl=
e I wrote on<br>
&gt; stack and deleted.<br>
<br>
</span>I don&#39;t know what sort of a reversible example that is, because =
it&#39;s<br>
not exception-safe. Is that intentional?<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZN2CBB9knsvfSCUvy%3D%3D=
WSZ%3DTaROfSCpt%2B5x1JGARzi2g%40mail.gmail.com" rel=3D"noreferrer" target=
=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>pr=
oposals/<wbr>CAFk2RUZN2CBB9knsvfSCUvy%3D%<wbr>3DWSZ%3DTaROfSCpt%<wbr>2B5x1J=
GARzi2g%40mail.gmail.com</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNjdqR71HxudOvyOUDMCaoGp0ug%3=
Dv5ub0_bM12_QPD3kg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNjdq=
R71HxudOvyOUDMCaoGp0ug%3Dv5ub0_bM12_QPD3kg%40mail.gmail.com</a>.<br />

--f403043ebce079b07b0565e2a5d7--

.

--001a11453a72d48f590565e2ce53
Content-Type: text/plain; charset="UTF-8"

Your example shows no such thing. I have said it calmly enough times, so
I'll step it up a notch: *Stop doing benchmarks along a single run - they
are absolutely pointless, unreliable, usually wrong *(e.g DVFS)*, and
overall worthless.* As a community we *can't* take your ideas seriously if
you don't respect that, and we *won't* take your ideas seriously if you
don't learn anything when we show you a flaw in your approach.

Take the following as an example of why this is dumb:

#include <iostream>
>
> int main () {
>   size_t duration (0);
>   clock_t t (clock ());
>   std::cout << "Hello" << std::endl;
>   duration = (clock() - t);
>   std::cout << "Cout took " << duration << " ticks" << std::endl;
>
>   t = clock ();
>   std::cout << "Hello" << std::endl;
>   duration = (clock() - t);
>   std::cout << "Cout took " << duration << " ticks" << std::endl;
>   return 0;
> }
>

Output:

> Hello
> Cout took 30 ticks
> Hello
> Cout took 2 ticks
>

No one in their right mind would say that this benchmark proves anything.

On Fri, Feb 23, 2018 at 3:02 PM, <jsaintmartin356@gmail.com> wrote:

> nope , was just a first example, showing reversible is faster than const
>
> On Friday, February 23, 2018 at 3:44:40 PM UTC+1, Ville Voutilainen wrote:
>>
>> On 23 February 2018 at 16:38,  <jsaintm...@gmail.com> wrote:
>> > "reversible" sounds good to me. Attached is the small example I wrote
>> on
>> > stack and deleted.
>>
>> I don't know what sort of a reversible example that is, because it's
>> not exception-safe. Is that intentional?
>>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-
> bfae-6570e92762af%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMOJg94JZrDjjMgkt-SGBzFZfk2ECB2S50cuNbe05mHYg%40mail.gmail.com.

--001a11453a72d48f590565e2ce53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Your example shows no such thing. I have said it calm=
ly enough times, so I&#39;ll step it up a notch: <b>Stop doing benchmarks a=
long a single run - they are absolutely pointless, unreliable, usually wron=
g </b>(e.g DVFS)<b>, and overall worthless.</b> As a community we <i>can&#3=
9;t</i> take your ideas seriously if you don&#39;t respect that, and we <i>=
won&#39;t</i> take your ideas seriously if you don&#39;t learn anything whe=
n we show you a flaw in your approach.<br><br></div>Take the following as a=
n example of why this is dumb:<br><br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">#include &lt;iostream&gt;<br><br>int main () {<br>=C2=A0 size_=
t duration (0);<br>=C2=A0 clock_t t (clock ());<br>=C2=A0 std::cout &lt;&lt=
; &quot;Hello&quot; &lt;&lt; std::endl;<br>=C2=A0 duration =3D (clock() - t=
);<br>=C2=A0 std::cout &lt;&lt; &quot;Cout took &quot; &lt;&lt; duration &l=
t;&lt; &quot; ticks&quot; &lt;&lt; std::endl;<br><br>=C2=A0 t =3D clock ();=
<br>=C2=A0 std::cout &lt;&lt; &quot;Hello&quot; &lt;&lt; std::endl;<br>=C2=
=A0 duration =3D (clock() - t);<br>=C2=A0 std::cout &lt;&lt; &quot;Cout too=
k &quot; &lt;&lt; duration &lt;&lt; &quot; ticks&quot; &lt;&lt; std::endl;<=
br>=C2=A0 return 0;<br>}<br></blockquote><div><br></div><div>Output:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">Hello<br>Cout took 30 ticks<=
br>Hello<br>Cout took 2 ticks<br></blockquote><div><br></div><div>No one in=
 their right mind would say that this benchmark proves anything. <br></div>=
 </div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On F=
ri, Feb 23, 2018 at 3:02 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:jsain=
tmartin356@gmail.com" target=3D"_blank">jsaintmartin356@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">nope , was =
just a first example, showing reversible is faster than const<br><br>On Fri=
day, February 23, 2018 at 3:44:40 PM UTC+1, Ville Voutilainen wrote:<span c=
lass=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 February 2018 at 16=
:38, =C2=A0&lt;<a rel=3D"nofollow">jsaintm...@gmail.com</a>&gt; wrote:
<br>&gt; &quot;reversible&quot; sounds good to me. Attached is the small ex=
ample I wrote on
<br>&gt; stack and deleted.
<br>
<br>I don&#39;t know what sort of a reversible example that is, because it&=
#39;s
<br>not exception-safe. Is that intentional?
<br></blockquote></span></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/79e7=
4097-51db-443d-<wbr>bfae-6570e92762af%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMOJg94JZrDjjMgkt-SGBzFZfk2EC=
B2S50cuNbe05mHYg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMOJg94=
JZrDjjMgkt-SGBzFZfk2ECB2S50cuNbe05mHYg%40mail.gmail.com</a>.<br />

--001a11453a72d48f590565e2ce53--

.

------=_Part_5981_1797597099.1519400133144
Content-Type: multipart/alternative;
 boundary="----=_Part_5982_1721855401.1519400133144"

------=_Part_5982_1721855401.1519400133144
Content-Type: text/plain; charset="UTF-8"

what tool shall I use for benchmarking ?

On Friday, February 23, 2018 at 4:28:13 PM UTC+1, Jake Arkinstall wrote:
>
> Your example shows no such thing. I have said it calmly enough times, so
> I'll step it up a notch: *Stop doing benchmarks along a single run - they
> are absolutely pointless, unreliable, usually wrong *(e.g DVFS)*, and
> overall worthless.* As a community we *can't* take your ideas seriously
> if you don't respect that, and we *won't* take your ideas seriously if
> you don't learn anything when we show you a flaw in your approach.
>
> Take the following as an example of why this is dumb:
>
> #include <iostream>
>>
>> int main () {
>>   size_t duration (0);
>>   clock_t t (clock ());
>>   std::cout << "Hello" << std::endl;
>>   duration = (clock() - t);
>>   std::cout << "Cout took " << duration << " ticks" << std::endl;
>>
>>   t = clock ();
>>   std::cout << "Hello" << std::endl;
>>   duration = (clock() - t);
>>   std::cout << "Cout took " << duration << " ticks" << std::endl;
>>   return 0;
>> }
>>
>
> Output:
>
>> Hello
>> Cout took 30 ticks
>> Hello
>> Cout took 2 ticks
>>
>
> No one in their right mind would say that this benchmark proves anything.
>
> On Fri, Feb 23, 2018 at 3:02 PM, <jsaintm...@gmail.com <javascript:>>
> wrote:
>
>> nope , was just a first example, showing reversible is faster than const
>>
>> On Friday, February 23, 2018 at 3:44:40 PM UTC+1, Ville Voutilainen wrote:
>>>
>>> On 23 February 2018 at 16:38,  <jsaintm...@gmail.com> wrote:
>>> > "reversible" sounds good to me. Attached is the small example I wrote
>>> on
>>> > stack and deleted.
>>>
>>> I don't know what sort of a reversible example that is, because it's
>>> not exception-safe. Is that intentional?
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/892b52ce-dfbd-4cd5-90aa-0465db608c96%40isocpp.org.

------=_Part_5982_1721855401.1519400133144
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">what tool shall I use for benchmarking ?<br><br>On Friday,=
 February 23, 2018 at 4:28:13 PM UTC+1, Jake Arkinstall wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Your example shows no=
 such thing. I have said it calmly enough times, so I&#39;ll step it up a n=
otch: <b>Stop doing benchmarks along a single run - they are absolutely poi=
ntless, unreliable, usually wrong </b>(e.g DVFS)<b>, and overall worthless.=
</b> As a community we <i>can&#39;t</i> take your ideas seriously if you do=
n&#39;t respect that, and we <i>won&#39;t</i> take your ideas seriously if =
you don&#39;t learn anything when we show you a flaw in your approach.<br><=
br></div>Take the following as an example of why this is dumb:<br><br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">#include &lt;iostream&gt;<br><=
br>int main () {<br>=C2=A0 size_t duration (0);<br>=C2=A0 clock_t t (clock =
());<br>=C2=A0 std::cout &lt;&lt; &quot;Hello&quot; &lt;&lt; std::endl;<br>=
=C2=A0 duration =3D (clock() - t);<br>=C2=A0 std::cout &lt;&lt; &quot;Cout =
took &quot; &lt;&lt; duration &lt;&lt; &quot; ticks&quot; &lt;&lt; std::end=
l;<br><br>=C2=A0 t =3D clock ();<br>=C2=A0 std::cout &lt;&lt; &quot;Hello&q=
uot; &lt;&lt; std::endl;<br>=C2=A0 duration =3D (clock() - t);<br>=C2=A0 st=
d::cout &lt;&lt; &quot;Cout took &quot; &lt;&lt; duration &lt;&lt; &quot; t=
icks&quot; &lt;&lt; std::endl;<br>=C2=A0 return 0;<br>}<br></blockquote><di=
v><br></div><div>Output:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Hello<br>Cout took 30 ticks<br>Hello<br>Cout took 2 ticks<br></blockquot=
e><div><br></div><div>No one in their right mind would say that this benchm=
ark proves anything. <br></div> </div></div><div><br><div class=3D"gmail_qu=
ote">On Fri, Feb 23, 2018 at 3:02 PM,  <span dir=3D"ltr">&lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"rrqpj-gcAAAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onc=
lick=3D"this.href=3D&#39;javascript:&#39;;return true;">jsaintm...@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
nope , was just a first example, showing reversible is faster than const<br=
><br>On Friday, February 23, 2018 at 3:44:40 PM UTC+1, Ville Voutilainen wr=
ote:<span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 February 2018 at 16=
:38, =C2=A0&lt;<a rel=3D"nofollow">jsaintm...@gmail.com</a>&gt; wrote:
<br>&gt; &quot;reversible&quot; sounds good to me. Attached is the small ex=
ample I wrote on
<br>&gt; stack and deleted.
<br>
<br>I don&#39;t know what sort of a reversible example that is, because it&=
#39;s
<br>not exception-safe. Is that intentional?
<br></blockquote></span></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
rrqpj-gcAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"rrqpj-gcAAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/79e74097-51db-443d-bfae-6570e92762af%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/79e74097-51db-443d-bfae-6570e92762af%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/79e74097-51db-443d-<wbr>bfae-=
6570e92762af%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/892b52ce-dfbd-4cd5-90aa-0465db608c96%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/892b52ce-dfbd-4cd5-90aa-0465db608c96=
%40isocpp.org</a>.<br />

------=_Part_5982_1721855401.1519400133144--

------=_Part_5981_1797597099.1519400133144--

.

On 23 February 2018 at 17:28, Jake Arkinstall <jake.arkinstall@gmail.com> wrote:
> Your example shows no such thing. I have said it calmly enough times, so


That example shows that modifying values in an existing buffer is
faster than re-allocating a new buffer, copying data over to it,
and releasing that buffer. How that leads into a need to have a
pseudoconst in C++ is beyond me.

We have a Transactional Memory TS. It shows us that there are limits
to what operations can be transactional.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZBRZ3kA3SjbS0z7BU8FtO-KKzuJC%2B7eSQySLs7hJq2ww%40mail.gmail.com.

.

--001a114520fad701920565e31da0
Content-Type: text/plain; charset="UTF-8"

On Fri, Feb 23, 2018 at 3:37 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> That example shows that modifying values in an existing buffer is
> faster than re-allocating a new buffer, copying data over to it,
> and releasing that buffer.


It's not faster, though. See Toby's benchmark on reply 6:
http://quick-bench.com/3CuEaO513mfIZmS6Ca1rrC_DnII

I can see *some* use for a pseudoconst, in that the user is aware that the
object will be the same at the end as the beginning, but that it isn't
thread safe. There are no performance benefits but exposing and enforcing a
contract could have its perks.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNyJE_BcwPKVs3KQa2VXjLGRTC%3DBWR4r86G6GB6FbDg1Q%40mail.gmail.com.

--001a114520fad701920565e31da0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Feb 23, 2018 at 3:37 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutil=
ainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">That example shows that modifying values in an existing buf=
fer is<br>
faster than re-allocating a new buffer, copying data over to it,<br>
and releasing that buffer.</blockquote><div><br>It&#39;s not faster, though=
.. See Toby&#39;s benchmark on reply 6: <a href=3D"http://quick-bench.com/3C=
uEaO513mfIZmS6Ca1rrC_DnII">http://quick-bench.com/3CuEaO513mfIZmS6Ca1rrC_Dn=
II</a> <br><br></div><div>I can see <i>some</i> use for a pseudoconst, in t=
hat the user is aware that the object will be the same at the end as the be=
ginning, but that it isn&#39;t thread safe. There are no performance benefi=
ts but exposing and enforcing a contract could have its perks.<br></div><di=
v><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNyJE_BcwPKVs3KQa2VXjLGRTC%3D=
BWR4r86G6GB6FbDg1Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNyJE=
_BcwPKVs3KQa2VXjLGRTC%3DBWR4r86G6GB6FbDg1Q%40mail.gmail.com</a>.<br />

--001a114520fad701920565e31da0--

.

On 23 February 2018 at 17:50, Jake Arkinstall <jake.arkinstall@gmail.com> wrote:
>> That example shows that modifying values in an existing buffer is
>> faster than re-allocating a new buffer, copying data over to it,
>> and releasing that buffer.
>
>
> It's not faster, though. See Toby's benchmark on reply 6:
> http://quick-bench.com/3CuEaO513mfIZmS6Ca1rrC_DnII

Hah, indeed, the mutation of the copy doesn't need to be reversed.

> I can see some use for a pseudoconst, in that the user is aware that the
> object will be the same at the end as the beginning, but that it isn't
> thread safe. There are no performance benefits but exposing and enforcing a
> contract could have its perks.

I fail to see how that's different from traditional exception safety.
We don't have a keyword or a test for that,
though. There was a time when it was suggested that it would make
sense to add 'basic' and 'strong' to the
set of one that currently contains 'noexcept', but how that should be
used is something that never got enough
motivation for that idea to make progress.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaRH4EV8uxoeH59Q7hLeppkHwG-_D_6MsVx5yS83J%3Dduw%40mail.gmail.com.

.

On Friday, 23 February 2018 07:35:32 PST jsaintmartin356@gmail.com wrote:
> what tool shall I use for benchmarking ?

perf, over a run of the benchmark of at least a full second an otherwise-idle
system. Preferably, more. And you should do some statistics over a couple of
runs.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1620166.a9IvyEJijX%40tjmaciei-mobl1.

.

------=_Part_4839_1434418050.1519409684850
Content-Type: multipart/alternative;
 boundary="----=_Part_4840_1453010338.1519409684851"

------=_Part_4840_1453010338.1519409684851
Content-Type: text/plain; charset="UTF-8"

I would not have wirte it your way, but this way (reversible and reverse
part of declaration) but like this :

#include <vector>
class Vec {public :
  Vec () : val_ (std::vector<size_t> (1000, 0)) {}
  Vec (const Vec& v) : val_ (v.val_) {}
  ~Vec () {}
  //couple of reverse methods
  void inc () {
    std::for_each (val_.begin (), val_.end (), [] (size_t&s) {++s;});
  }
  void dec () reverse inc () {
    std::for_each (val_.begin (), val_.end (), [] (size_t&s) {--s;});
  }

  void write2 (std::ostream& os) const {
    os << "val_ [2] == " << val_ [2] << std::endl;
  }
  void write_next2const (std::ostream& os) const {
    Vec v (*this);
    v.inc ();
    v.write2 (os);
  }
  void write_next2reversible (std::ostream& os) reversible  {
    inc ();
    write2 (os);
    dec ();
  }//private :
  std::vector<size_t> val_;};

and about the "thread safe" problem, fel free to insert a muex

On Friday, February 23, 2018 at 4:16:40 PM UTC+1, Jake Arkinstall wrote:
>
> If you require that the operation is reversible, you probably shouldn't
> trust the source blindly.
>
> The idea is more along the lines of
>
> void inc(T x) reversible{
>     // ....
> }
>
> void dec(T x) reversible{
>     reverse(inc)(x);
> }
>
> Where we can assume reverse(reverse(f)) is reduced to f, for some method
> f. The reversible keyword informs the compiler that the method should be
> split into statements, and each such statement must be reversible (i.e. is
> a method that has the 'reversible' keyword). Each statement is reversed and
> iterated back-to-front when the reverse() method (or some arbitrary syntax)
> is called on a method. In other words, the user doesn't explicitly define
> the reverse (users cannot be trusted, which is exactly why const enforces
> const). This propogates all the way down to fundamental operations, so at
> some point the reverse of those operations need to be defined - but by the
> language, not by the user.
>
> Then RAII could be exploited to ensure that a pseudoconst method really
> undoes the initial operation:
>
> void nonconst_example() pseudoconst{
>     Transformer t(this, inc); // transformation is performed
>     // do what you as long as it's const
> } // t::~t() is called, undoing the transformation.
>
> It's a bit of a strange idea, but it's the only way that I can think of
> that allows pseudoconst to be reliable.
>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ae842444-add0-44b2-93b6-4bf15c699d5c%40isocpp.org.

------=_Part_4840_1453010338.1519409684851
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I would not have wirte it your way, but this way (reversib=
le and reverse part of declaration) but like this :<br><pre class=3D"lang-c=
pp prettyprint prettyprinted" style=3D""><code><span class=3D"com">#include=
</span><span class=3D"pln"> </span><span class=3D"str">&lt;vector&gt;</span=
><span class=3D"pln">

</span><span class=3D"kwd">class</span><span class=3D"pln"> </span><span cl=
ass=3D"typ">Vec</span><span class=3D"pln"> </span><span class=3D"pun">{</sp=
an><span class=3D"pln">
</span><span class=3D"kwd">public</span><span class=3D"pln"> </span><span c=
lass=3D"pun">:</span><span class=3D"pln">=20
  </span><span class=3D"typ">Vec</span><span class=3D"pln"> </span><span cl=
ass=3D"pun">()</span><span class=3D"pln"> </span><span class=3D"pun">:</spa=
n><span class=3D"pln"> val_ </span><span class=3D"pun">(</span><span class=
=3D"pln">std</span><span class=3D"pun">::</span><span class=3D"typ">vector<=
/span><span class=3D"str">&lt;size_t&gt;</span><span class=3D"pln"> </span>=
<span class=3D"pun">(</span><span class=3D"lit">1000</span><span class=3D"p=
un">,</span><span class=3D"pln"> </span><span class=3D"lit">0</span><span c=
lass=3D"pun">))</span><span class=3D"pln"> </span><span class=3D"pun">{}</s=
pan><span class=3D"pln">
  </span><span class=3D"typ">Vec</span><span class=3D"pln"> </span><span cl=
ass=3D"pun">(</span><span class=3D"kwd">const</span><span class=3D"pln"> </=
span><span class=3D"typ">Vec</span><span class=3D"pun">&amp;</span><span cl=
ass=3D"pln"> v</span><span class=3D"pun">)</span><span class=3D"pln"> </spa=
n><span class=3D"pun">:</span><span class=3D"pln"> val_ </span><span class=
=3D"pun">(</span><span class=3D"pln">v</span><span class=3D"pun">.</span><s=
pan class=3D"pln">val_</span><span class=3D"pun">)</span><span class=3D"pln=
"> </span><span class=3D"pun">{}</span><span class=3D"pln">
  </span><span class=3D"pun">~</span><span class=3D"typ">Vec</span><span cl=
ass=3D"pln"> </span><span class=3D"pun">()</span><span class=3D"pln"> </spa=
n><span class=3D"pun">{}</span><span class=3D"pln">
  </span><span class=3D"com">//couple of reverse methods</span><span class=
=3D"pln">
  </span><span class=3D"kwd">void</span><span class=3D"pln"> inc </span><sp=
an class=3D"pun">()</span><span class=3D"pln"> </span><span class=3D"pun">{=
</span><span class=3D"pln">
    std</span><span class=3D"pun">::</span><span class=3D"pln">for_each </s=
pan><span class=3D"pun">(</span><span class=3D"pln">val_</span><span class=
=3D"pun">.</span><span class=3D"pln">begin </span><span class=3D"pun">(),</=
span><span class=3D"pln"> val_</span><span class=3D"pun">.</span><span clas=
s=3D"pln">end </span><span class=3D"pun">(),</span><span class=3D"pln"> </s=
pan><span class=3D"pun">[]</span><span class=3D"pln"> </span><span class=3D=
"pun">(</span><span class=3D"typ">size_t</span><span class=3D"pun">&amp;</s=
pan><span class=3D"pln">s</span><span class=3D"pun">)</span><span class=3D"=
pln"> </span><span class=3D"pun">{++</span><span class=3D"pln">s</span><spa=
n class=3D"pun">;});</span><span class=3D"pln">
  </span><span class=3D"pun">}</span><span class=3D"pln">
  </span><span class=3D"kwd">void</span><span class=3D"pln"> dec </span><sp=
an class=3D"pun">()</span><span class=3D"pln"> reverse inc () </span><span =
class=3D"pun">{</span><span class=3D"pln">
    std</span><span class=3D"pun">::</span><span class=3D"pln">for_each </s=
pan><span class=3D"pun">(</span><span class=3D"pln">val_</span><span class=
=3D"pun">.</span><span class=3D"pln">begin </span><span class=3D"pun">(),</=
span><span class=3D"pln"> val_</span><span class=3D"pun">.</span><span clas=
s=3D"pln">end </span><span class=3D"pun">(),</span><span class=3D"pln"> </s=
pan><span class=3D"pun">[]</span><span class=3D"pln"> </span><span class=3D=
"pun">(</span><span class=3D"typ">size_t</span><span class=3D"pun">&amp;</s=
pan><span class=3D"pln">s</span><span class=3D"pun">)</span><span class=3D"=
pln"> </span><span class=3D"pun">{--</span><span class=3D"pln">s</span><spa=
n class=3D"pun">;});</span><span class=3D"pln">
  </span><span class=3D"pun">}</span><span class=3D"pln">

  </span><span class=3D"kwd">void</span><span class=3D"pln"> write2 </span>=
<span class=3D"pun">(</span><span class=3D"pln">std</span><span class=3D"pu=
n">::</span><span class=3D"pln">ostream</span><span class=3D"pun">&amp;</sp=
an><span class=3D"pln"> os</span><span class=3D"pun">)</span><span class=3D=
"pln"> </span><span class=3D"kwd">const</span><span class=3D"pln"> </span><=
span class=3D"pun">{</span><span class=3D"pln">
    os </span><span class=3D"pun">&lt;&lt;</span><span class=3D"pln"> </spa=
n><span class=3D"str">&quot;val_ [2] =3D=3D &quot;</span><span class=3D"pln=
"> </span><span class=3D"pun">&lt;&lt;</span><span class=3D"pln"> val_ </sp=
an><span class=3D"pun">[</span><span class=3D"lit">2</span><span class=3D"p=
un">]</span><span class=3D"pln"> </span><span class=3D"pun">&lt;&lt;</span>=
<span class=3D"pln"> std</span><span class=3D"pun">::</span><span class=3D"=
pln">endl</span><span class=3D"pun">;</span><span class=3D"pln">
  </span><span class=3D"pun">}</span><span class=3D"pln">
  </span><span class=3D"kwd">void</span><span class=3D"pln"> write_next2con=
st </span><span class=3D"pun">(</span><span class=3D"pln">std</span><span c=
lass=3D"pun">::</span><span class=3D"pln">ostream</span><span class=3D"pun"=
>&amp;</span><span class=3D"pln"> os</span><span class=3D"pun">)</span><spa=
n class=3D"pln"> </span><span class=3D"kwd">const</span><span class=3D"pln"=
> </span><span class=3D"pun">{</span><span class=3D"pln">
    </span><span class=3D"typ">Vec</span><span class=3D"pln"> v </span><spa=
n class=3D"pun">(*</span><span class=3D"kwd">this</span><span class=3D"pun"=
>);</span><span class=3D"pln">
    v</span><span class=3D"pun">.</span><span class=3D"pln">inc </span><spa=
n class=3D"pun">();</span><span class=3D"pln">
    v</span><span class=3D"pun">.</span><span class=3D"pln">write2 </span><=
span class=3D"pun">(</span><span class=3D"pln">os</span><span class=3D"pun"=
>);</span><span class=3D"pln">
  </span><span class=3D"pun">}</span><span class=3D"pln">
  </span><span class=3D"kwd">void</span><span class=3D"pln"> write_next2rev=
ersible </span><span class=3D"pun">(</span><span class=3D"pln">std</span><s=
pan class=3D"pun">::</span><span class=3D"pln">ostream</span><span class=3D=
"pun">&amp;</span><span class=3D"pln"> os</span><span class=3D"pun">)</span=
><span class=3D"pln"> reversible  </span><span class=3D"pun">{</span><span =
class=3D"pln"></span><span class=3D"com"></span><span class=3D"pln">
    inc </span><span class=3D"pun">();</span><span class=3D"pln">
    write2 </span><span class=3D"pun">(</span><span class=3D"pln">os</span>=
<span class=3D"pun">);</span><span class=3D"pln">
    dec </span><span class=3D"pun">();</span><span class=3D"pln">
  </span><span class=3D"pun">}</span><span class=3D"pln">
</span><span class=3D"com">//private :</span><span class=3D"pln">
  std</span><span class=3D"pun">::</span><span class=3D"typ">vector</span><=
span class=3D"str">&lt;size_t&gt;</span><span class=3D"pln"> val_</span><sp=
an class=3D"pun">;</span><span class=3D"pln">
</span><span class=3D"pun">};<br><br></span></code></pre>and about the &quo=
t;thread safe&quot; problem, fel free to insert a muex<br><br>On Friday, Fe=
bruary 23, 2018 at 4:16:40 PM UTC+1, Jake Arkinstall wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div><div>If you re=
quire that the operation is reversible, you probably shouldn&#39;t trust th=
e source blindly.<br><br></div>The idea is more along the lines of<br><br><=
/div>void inc(T x) reversible{<br>=C2=A0=C2=A0=C2=A0 // ....<br>}<br><br></=
div><div>void dec(T x) reversible{<br></div><div>=C2=A0=C2=A0=C2=A0 reverse=
(inc)(x);<br></div><div>}<br></div><div><br></div><div>Where we can assume =
reverse(reverse(f)) is reduced to f, for some method f. The reversible keyw=
ord
 informs the compiler that the method should be split into statements,=20
and each such statement must be reversible (i.e. is a method that has=20
the &#39;reversible&#39; keyword). Each statement is reversed and iterated=
=20
back-to-front when the reverse() method (or some arbitrary syntax) is=20
called on a method. In other words, the user doesn&#39;t explicitly define=
=20
the reverse (users cannot be trusted, which is exactly why const=20
enforces const). This propogates all the way down to fundamental=20
operations, so at some point the reverse of those operations need to be=20
defined - but by the language, not by the user.<br><br></div><div>Then RAII=
 could be exploited to ensure that a pseudoconst method really undoes the i=
nitial operation:<br></div><div><br></div>void nonconst_example() pseudocon=
st{<br></div><div>=C2=A0=C2=A0=C2=A0 Transformer t(this, inc); // transform=
ation is performed<br></div><div>=C2=A0 =C2=A0 // do what you as long as it=
&#39;s const<br></div><div>} // t::~t() is called, undoing the transformati=
on.<br><br></div><div>It&#39;s a bit of a strange idea, but it&#39;s the on=
ly way that I can think of that allows pseudoconst to be reliable.<br></div=
></div><div><br><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ae842444-add0-44b2-93b6-4bf15c699d5c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ae842444-add0-44b2-93b6-4bf15c699d5c=
%40isocpp.org</a>.<br />

------=_Part_4840_1453010338.1519409684851--

------=_Part_4839_1434418050.1519409684850--

.

--94eb2c124da2d835790565e647ad
Content-Type: text/plain; charset="UTF-8"

On 23 Feb 2018 18:14, <jsaintmartin356@gmail.com> wrote:

I would not have wirte it your way, but this way (reversible and reverse
part of declaration) but like this :

#include <vector>

class Vec {public :
  Vec () : val_ (std::vector<size_t> (1000, 0)) {}
  Vec (const Vec& v) : val_ (v.val_) {}

  ~Vec () {}
  //couple of reverse methods

  void inc () {
    std::for_each (val_.begin (), val_.end (), [] (size_t&s) {++s;});
  }

  void dec () reverse inc () {

    std::for_each (val_.begin (), val_.end (), [] (size_t&s) {--s;});
  }


Then you lose the guarantee that the reversal is actually valid and the
whole thing is pointless.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMk%2BrfnaixDa70AZq%2Bqs_cZb_Pufkq92sDy68rO8Vwt9A%40mail.gmail.com.

--94eb2c124da2d835790565e647ad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 23 Feb 2018 18:14,  &lt;<a href=3D"mailto:jsaintmartin=
356@gmail.com">jsaintmartin356@gmail.com</a>&gt; wrote:<br type=3D"attribut=
ion"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">I would not have wirte it yo=
ur way, but this way (reversible and reverse part of declaration) but like =
this :<br><pre class=3D"m_-3598324353250887988lang-cpp m_-35983243532508879=
88prettyprint m_-3598324353250887988prettyprinted"><code><span class=3D"m_-=
3598324353250887988com">#include</span><span class=3D"m_-359832435325088798=
8pln"> </span><span class=3D"m_-3598324353250887988str">&lt;vector&gt;</spa=
n><div class=3D"quoted-text"><span class=3D"m_-3598324353250887988pln">

</span><span class=3D"m_-3598324353250887988kwd">class</span><span class=3D=
"m_-3598324353250887988pln"> </span><span class=3D"m_-3598324353250887988ty=
p">Vec</span><span class=3D"m_-3598324353250887988pln"> </span><span class=
=3D"m_-3598324353250887988pun">{</span><span class=3D"m_-359832435325088798=
8pln">
</span><span class=3D"m_-3598324353250887988kwd">public</span><span class=
=3D"m_-3598324353250887988pln"> </span><span class=3D"m_-359832435325088798=
8pun">:</span><span class=3D"m_-3598324353250887988pln">=20
  </span><span class=3D"m_-3598324353250887988typ">Vec</span><span class=3D=
"m_-3598324353250887988pln"> </span><span class=3D"m_-3598324353250887988pu=
n">()</span><span class=3D"m_-3598324353250887988pln"> </span><span class=
=3D"m_-3598324353250887988pun">:</span><span class=3D"m_-359832435325088798=
8pln"> val_ </span><span class=3D"m_-3598324353250887988pun">(</span><span =
class=3D"m_-3598324353250887988pln">std</span><span class=3D"m_-35983243532=
50887988pun">::</span><span class=3D"m_-3598324353250887988typ">vector</spa=
n><span class=3D"m_-3598324353250887988str">&lt;size_t&gt;</span><span clas=
s=3D"m_-3598324353250887988pln"> </span><span class=3D"m_-35983243532508879=
88pun">(</span><span class=3D"m_-3598324353250887988lit">1000</span><span c=
lass=3D"m_-3598324353250887988pun">,</span><span class=3D"m_-35983243532508=
87988pln"> </span><span class=3D"m_-3598324353250887988lit">0</span><span c=
lass=3D"m_-3598324353250887988pun">))</span><span class=3D"m_-3598324353250=
887988pln"> </span><span class=3D"m_-3598324353250887988pun">{}</span><span=
 class=3D"m_-3598324353250887988pln">
  </span><span class=3D"m_-3598324353250887988typ">Vec</span><span class=3D=
"m_-3598324353250887988pln"> </span><span class=3D"m_-3598324353250887988pu=
n">(</span><span class=3D"m_-3598324353250887988kwd">const</span><span clas=
s=3D"m_-3598324353250887988pln"> </span><span class=3D"m_-35983243532508879=
88typ">Vec</span><span class=3D"m_-3598324353250887988pun">&amp;</span><spa=
n class=3D"m_-3598324353250887988pln"> v</span><span class=3D"m_-3598324353=
250887988pun">)</span><span class=3D"m_-3598324353250887988pln"> </span><sp=
an class=3D"m_-3598324353250887988pun">:</span><span class=3D"m_-3598324353=
250887988pln"> val_ </span><span class=3D"m_-3598324353250887988pun">(</spa=
n><span class=3D"m_-3598324353250887988pln">v</span><span class=3D"m_-35983=
24353250887988pun">.</span><span class=3D"m_-3598324353250887988pln">val_</=
span><span class=3D"m_-3598324353250887988pun">)</span><span class=3D"m_-35=
98324353250887988pln"> </span><span class=3D"m_-3598324353250887988pun">{}<=
/span></div><span class=3D"m_-3598324353250887988pln">
  </span><span class=3D"m_-3598324353250887988pun">~</span><span class=3D"m=
_-3598324353250887988typ">Vec</span><span class=3D"m_-3598324353250887988pl=
n"> </span><span class=3D"m_-3598324353250887988pun">()</span><span class=
=3D"m_-3598324353250887988pln"> </span><span class=3D"m_-359832435325088798=
8pun">{}</span><span class=3D"m_-3598324353250887988pln">
  </span><span class=3D"m_-3598324353250887988com">//couple of reverse meth=
ods</span><div class=3D"quoted-text"><span class=3D"m_-3598324353250887988p=
ln">
  </span><span class=3D"m_-3598324353250887988kwd">void</span><span class=
=3D"m_-3598324353250887988pln"> inc </span><span class=3D"m_-35983243532508=
87988pun">()</span><span class=3D"m_-3598324353250887988pln"> </span><span =
class=3D"m_-3598324353250887988pun">{</span><span class=3D"m_-3598324353250=
887988pln">
    std</span><span class=3D"m_-3598324353250887988pun">::</span><span clas=
s=3D"m_-3598324353250887988pln">for_each </span><span class=3D"m_-359832435=
3250887988pun">(</span><span class=3D"m_-3598324353250887988pln">val_</span=
><span class=3D"m_-3598324353250887988pun">.</span><span class=3D"m_-359832=
4353250887988pln">begin </span><span class=3D"m_-3598324353250887988pun">()=
,</span><span class=3D"m_-3598324353250887988pln"> val_</span><span class=
=3D"m_-3598324353250887988pun">.</span><span class=3D"m_-359832435325088798=
8pln">end </span><span class=3D"m_-3598324353250887988pun">(),</span><span =
class=3D"m_-3598324353250887988pln"> </span><span class=3D"m_-3598324353250=
887988pun">[]</span><span class=3D"m_-3598324353250887988pln"> </span><span=
 class=3D"m_-3598324353250887988pun">(</span><span class=3D"m_-359832435325=
0887988typ">size_t</span><span class=3D"m_-3598324353250887988pun">&amp;</s=
pan><span class=3D"m_-3598324353250887988pln">s</span><span class=3D"m_-359=
8324353250887988pun">)</span><span class=3D"m_-3598324353250887988pln"> </s=
pan><span class=3D"m_-3598324353250887988pun">{++</span><span class=3D"m_-3=
598324353250887988pln">s</span><span class=3D"m_-3598324353250887988pun">;}=
);</span><span class=3D"m_-3598324353250887988pln">
  </span><span class=3D"m_-3598324353250887988pun">}</span></div><span clas=
s=3D"m_-3598324353250887988pln">
  </span><span class=3D"m_-3598324353250887988kwd">void</span><span class=
=3D"m_-3598324353250887988pln"> dec </span><span class=3D"m_-35983243532508=
87988pun">()</span><span class=3D"m_-3598324353250887988pln"> reverse inc (=
) </span><span class=3D"m_-3598324353250887988pun">{</span><div class=3D"qu=
oted-text"><span class=3D"m_-3598324353250887988pln">
    std</span><span class=3D"m_-3598324353250887988pun">::</span><span clas=
s=3D"m_-3598324353250887988pln">for_each </span><span class=3D"m_-359832435=
3250887988pun">(</span><span class=3D"m_-3598324353250887988pln">val_</span=
><span class=3D"m_-3598324353250887988pun">.</span><span class=3D"m_-359832=
4353250887988pln">begin </span><span class=3D"m_-3598324353250887988pun">()=
,</span><span class=3D"m_-3598324353250887988pln"> val_</span><span class=
=3D"m_-3598324353250887988pun">.</span><span class=3D"m_-359832435325088798=
8pln">end </span><span class=3D"m_-3598324353250887988pun">(),</span><span =
class=3D"m_-3598324353250887988pln"> </span><span class=3D"m_-3598324353250=
887988pun">[]</span><span class=3D"m_-3598324353250887988pln"> </span><span=
 class=3D"m_-3598324353250887988pun">(</span><span class=3D"m_-359832435325=
0887988typ">size_t</span><span class=3D"m_-3598324353250887988pun">&amp;</s=
pan><span class=3D"m_-3598324353250887988pln">s</span><span class=3D"m_-359=
8324353250887988pun">)</span><span class=3D"m_-3598324353250887988pln"> </s=
pan><span class=3D"m_-3598324353250887988pun">{--</span><span class=3D"m_-3=
598324353250887988pln">s</span><span class=3D"m_-3598324353250887988pun">;}=
);</span><span class=3D"m_-3598324353250887988pln">
  </span><span class=3D"m_-3598324353250887988pun">}</span></div></code></p=
re></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Then you lose the guarantee that the reversal is actually valid and th=
e whole thing is pointless.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMk%2BrfnaixDa70AZq%2Bqs_cZb_=
Pufkq92sDy68rO8Vwt9A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMk=
%2BrfnaixDa70AZq%2Bqs_cZb_Pufkq92sDy68rO8Vwt9A%40mail.gmail.com</a>.<br />

--94eb2c124da2d835790565e647ad--

.

------=_Part_5289_751730045.1519416113861
Content-Type: multipart/alternative;
 boundary="----=_Part_5290_1563091011.1519416113861"

------=_Part_5290_1563091011.1519416113861
Content-Type: text/plain; charset="UTF-8"

reversible is for the user. You trust compiler, why would not he trust you ?


> Then you lose the guarantee that the reversal is actually valid and the
> whole thing is pointless.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%40isocpp.org.

------=_Part_5290_1563091011.1519416113861
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">reversible is for the user. You trust compiler, why would =
not he trust you ?<br><br><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">Then you lose t=
he guarantee that the reversal is actually valid and the whole thing is poi=
ntless.</div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d=
%40isocpp.org</a>.<br />

------=_Part_5290_1563091011.1519416113861--

------=_Part_5289_751730045.1519416113861--

.

--f403043ebce049651a0565e72802
Content-Type: text/plain; charset="UTF-8"

"*A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete fools*"
- Douglas Adams.

In my experience, this is very much the case. If something is worthy of
being a part of the language, it should be so in a consistent manner. A
keyword is worthless if not enforceable by the compiler, especially when
you get newer users trying to get around what they think is a restriction
in a provided API by breaking everything they can find.

On 23 Feb 2018 20:01, <jsaintmartin356@gmail.com> wrote:

> reversible is for the user. You trust compiler, why would not he trust you
> ?
>
>
>> Then you lose the guarantee that the reversal is actually valid and the
>> whole thing is pointless.
>>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-
> 909d-4fac15e8276d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCM_wMKaiAfrznknPHTvWsG8Rk7XZsKvyNep%3D0vPT-ruWA%40mail.gmail.com.

--f403043ebce049651a0565e72802
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">&quot;<i>A common mistake that people make when trying to=
 design something completely foolproof is to underestimate the ingenuity of=
 complete fools</i>&quot; - Douglas Adams.<div dir=3D"auto"><br></div><div =
dir=3D"auto">In my experience, this is very much the case. If something is =
worthy of being a part of the language, it should be so in a consistent man=
ner. A keyword is worthless if not enforceable by the compiler, especially =
when you get newer users trying to get around what they think is a restrict=
ion in a provided API by breaking everything they can find.</div></div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 23 Feb 2018 20:01,=
  &lt;<a href=3D"mailto:jsaintmartin356@gmail.com">jsaintmartin356@gmail.co=
m</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">reversible is for the user. You trust compiler, why would not=
 he trust you ?<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
auto"><div dir=3D"auto"><br></div><div dir=3D"auto">Then you lose the guara=
ntee that the reversal is actually valid and the whole thing is pointless.<=
/div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/7b21=
6bd6-d0df-462c-<wbr>909d-4fac15e8276d%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCM_wMKaiAfrznknPHTvWsG8Rk7XZs=
KvyNep%3D0vPT-ruWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCM_wM=
KaiAfrznknPHTvWsG8Rk7XZsKvyNep%3D0vPT-ruWA%40mail.gmail.com</a>.<br />

--f403043ebce049651a0565e72802--

.

------=_Part_8294_343127007.1519462496561
Content-Type: multipart/alternative;
 boundary="----=_Part_8295_1777218625.1519462496561"

------=_Part_8295_1777218625.1519462496561
Content-Type: text/plain; charset="UTF-8"

But you may avoid a great number of fools -if not all- placing a sign
"fools : no entry".

On Friday, February 23, 2018 at 9:39:34 PM UTC+1, Jake Arkinstall wrote:
>
> "*A common mistake that people make when trying to design something
> completely foolproof is to underestimate the ingenuity of complete fools*"
> - Douglas Adams.
>
> In my experience, this is very much the case. If something is worthy of
> being a part of the language, it should be so in a consistent manner. A
> keyword is worthless if not enforceable by the compiler, especially when
> you get newer users trying to get around what they think is a restriction
> in a provided API by breaking everything they can find.
>
> On 23 Feb 2018 20:01, <jsaintm...@gmail.com <javascript:>> wrote:
>
>> reversible is for the user. You trust compiler, why would not he trust
>> you ?
>>
>>
>>> Then you lose the guarantee that the reversal is actually valid and the
>>> whole thing is pointless.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8420f81c-5b9e-4077-904c-f0a507a6ff89%40isocpp.org.

------=_Part_8295_1777218625.1519462496561
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">But you may avoid a great number of fools -if not all- pla=
cing a sign &quot;fools : no entry&quot;. <br><br>On Friday, February 23, 2=
018 at 9:39:34 PM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"auto">&quot;<i>A common mistake that people ma=
ke when trying to design something completely foolproof is to underestimate=
 the ingenuity of complete fools</i>&quot; - Douglas Adams.<div dir=3D"auto=
"><br></div><div dir=3D"auto">In my experience, this is very much the case.=
 If something is worthy of being a part of the language, it should be so in=
 a consistent manner. A keyword is worthless if not enforceable by the comp=
iler, especially when you get newer users trying to get around what they th=
ink is a restriction in a provided API by breaking everything they can find=
..</div></div><div><br><div class=3D"gmail_quote">On 23 Feb 2018 20:01,  &lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Q7NN-j1=
PAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jsai=
ntm...@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">reversible is for the user. You trust compil=
er, why would not he trust you ?<br><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">Then y=
ou lose the guarantee that the reversal is actually valid and the whole thi=
ng is pointless.</div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Q7NN-j1PAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Q7NN-j1PAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/7b216bd6-d0df-462c-909d-4fac15e8276d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/7b216bd6-d0df-462c-<wbr>909d-=
4fac15e8276d%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8420f81c-5b9e-4077-904c-f0a507a6ff89%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8420f81c-5b9e-4077-904c-f0a507a6ff89=
%40isocpp.org</a>.<br />

------=_Part_8295_1777218625.1519462496561--

------=_Part_8294_343127007.1519462496561--

.

--001a1141d570199a6b0565f1c1c3
Content-Type: text/plain; charset="UTF-8"

On 24 Feb 2018 08:54, <jsaintmartin356@gmail.com> wrote:

But you may avoid a great number of fools -if not all- placing a sign
"fools : no entry".


No. They see it as an invitation.

If a keyword can't be validated by the compiler, there's no point in it.
You can get pseudoconst without any effort by simply not declaring it
const. But if you want to introduce a new concept it needs to be
enforceable or it isn't worth the work that goes into the change.

If what you want is a sign on the door, you can do that with comments. If
you want an iris-scanner and finger print reader combination deadbolt,
three armed security guards, Lego blocks on the floor, a bobcat, and a moat
containing sharks with lasers, that's when you need a language modification.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPoBXYCHx8Kx2Y4t4vorJcjvf1fdZ7OyM%2BRtWcMTJq_2w%40mail.gmail.com.

--001a1141d570199a6b0565f1c1c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-family:sans-serif">=
On 24 Feb 2018 08:54, &lt;<a href=3D"mailto:jsaintmartin356@gmail.com">jsai=
ntmartin356@gmail.com</a>&gt; wrote:</span><br style=3D"font-family:sans-se=
rif"><blockquote style=3D"font-family:sans-serif;margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Bu=
t you may avoid a great number of fools -if not all- placing a sign &quot;f=
ools : no entry&quot;.=C2=A0</div></blockquote></div><div dir=3D"auto"><br>=
</div><div>No. They see it as an invitation.<div dir=3D"auto"><br></div><di=
v dir=3D"auto">If a keyword can&#39;t be validated by the compiler, there&#=
39;s no point in it. You can get pseudoconst without any effort by simply n=
ot declaring it const. But if you want to introduce a new concept it needs =
to be enforceable or it isn&#39;t worth the work that goes into the change.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">If what you want is a s=
ign on the door, you can do that with comments. If you want an iris-scanner=
 and finger print reader combination deadbolt, three armed security guards,=
 Lego blocks on the floor, a bobcat, and a moat containing sharks with lase=
rs, that&#39;s when you need a language modification.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPoBXYCHx8Kx2Y4t4vorJcjvf1fdZ=
7OyM%2BRtWcMTJq_2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPoBX=
YCHx8Kx2Y4t4vorJcjvf1fdZ7OyM%2BRtWcMTJq_2w%40mail.gmail.com</a>.<br />

--001a1141d570199a6b0565f1c1c3--

.

------=_Part_40_555539614.1519534122210
Content-Type: multipart/alternative;
 boundary="----=_Part_41_375752085.1519534122210"

------=_Part_41_375752085.1519534122210
Content-Type: text/plain; charset="UTF-8"

you may be right I ll do it by myself. Do you have an address where I may
download g++ sources ?

On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>
> On 24 Feb 2018 08:54, <jsaintm...@gmail.com <javascript:>> wrote:
>
> But you may avoid a great number of fools -if not all- placing a sign
> "fools : no entry".
>
>
> No. They see it as an invitation.
>
> If a keyword can't be validated by the compiler, there's no point in it.
> You can get pseudoconst without any effort by simply not declaring it
> const. But if you want to introduce a new concept it needs to be
> enforceable or it isn't worth the work that goes into the change.
>
> If what you want is a sign on the door, you can do that with comments. If
> you want an iris-scanner and finger print reader combination deadbolt,
> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
> containing sharks with lasers, that's when you need a language modification.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a11fce96-b8a9-4cdc-9c90-79b0052c6148%40isocpp.org.

------=_Part_41_375752085.1519534122210
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">you may be right I ll do it by myself. Do you have an addr=
ess where I may download g++ sources ? <br><br>On Saturday, February 24, 20=
18 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-fa=
mily:sans-serif">On 24 Feb 2018 08:54, &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"2j4Dx6J4AgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">jsaintm...@gmail.com</a>&gt; wrote:=
</span><br style=3D"font-family:sans-serif"><blockquote style=3D"font-famil=
y:sans-serif;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr">But you may avoid a great number of fo=
ols -if not all- placing a sign &quot;fools : no entry&quot;.=C2=A0</div></=
blockquote></div><div dir=3D"auto"><br></div><div>No. They see it as an inv=
itation.<div dir=3D"auto"><br></div><div dir=3D"auto">If a keyword can&#39;=
t be validated by the compiler, there&#39;s no point in it. You can get pse=
udoconst without any effort by simply not declaring it const. But if you wa=
nt to introduce a new concept it needs to be enforceable or it isn&#39;t wo=
rth the work that goes into the change.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">If what you want is a sign on the door, you can do that wit=
h comments. If you want an iris-scanner and finger print reader combination=
 deadbolt, three armed security guards, Lego blocks on the floor, a bobcat,=
 and a moat containing sharks with lasers, that&#39;s when you need a langu=
age modification.</div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a11fce96-b8a9-4cdc-9c90-79b0052c6148%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a11fce96-b8a9-4cdc-9c90-79b0052c6148=
%40isocpp.org</a>.<br />

------=_Part_41_375752085.1519534122210--

------=_Part_40_555539614.1519534122210--

.

------=_Part_12977_1919291739.1519617836572
Content-Type: multipart/alternative;
 boundary="----=_Part_12978_1041599610.1519617836572"

------=_Part_12978_1041599610.1519617836572
Content-Type: text/plain; charset="UTF-8"

reverse ca be enforced by compiler if reversibility is created for basic
types. As explained upper, a pseudo const or reversible method can call in
this order : methods M, const calls, reverse methods M in reverse order

On Sunday, February 25, 2018 at 5:48:42 AM UTC+1, jsaintm...@gmail.com
wrote:
>
> you may be right I ll do it by myself. Do you have an address where I may
> download g++ sources ?
>
> On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>>
>> On 24 Feb 2018 08:54, <jsaintm...@gmail.com> wrote:
>>
>> But you may avoid a great number of fools -if not all- placing a sign
>> "fools : no entry".
>>
>>
>> No. They see it as an invitation.
>>
>> If a keyword can't be validated by the compiler, there's no point in it.
>> You can get pseudoconst without any effort by simply not declaring it
>> const. But if you want to introduce a new concept it needs to be
>> enforceable or it isn't worth the work that goes into the change.
>>
>> If what you want is a sign on the door, you can do that with comments. If
>> you want an iris-scanner and finger print reader combination deadbolt,
>> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
>> containing sharks with lasers, that's when you need a language modification.
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e6bbbb21-7d2d-438b-baaf-edf47f12204a%40isocpp.org.

------=_Part_12978_1041599610.1519617836572
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">reverse ca be enforced by compiler if reversibility is cre=
ated for basic types. As explained upper, a pseudo const or reversible meth=
od can call in this order : methods M, const calls, reverse methods M in re=
verse order<br><br>On Sunday, February 25, 2018 at 5:48:42 AM UTC+1, jsaint=
m...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">you may be right I ll do it by myself. Do you have an address wher=
e I may download g++ sources ? <br><br>On Saturday, February 24, 2018 at 10=
:18:07 AM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-family:sans-ser=
if">On 24 Feb 2018 08:54, &lt;<a rel=3D"nofollow">jsaintm...@gmail.com</a>&=
gt; wrote:</span><br style=3D"font-family:sans-serif"><blockquote style=3D"=
font-family:sans-serif;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr">But you may avoid a great nu=
mber of fools -if not all- placing a sign &quot;fools : no entry&quot;.=C2=
=A0</div></blockquote></div><div dir=3D"auto"><br></div><div>No. They see i=
t as an invitation.<div dir=3D"auto"><br></div><div dir=3D"auto">If a keywo=
rd can&#39;t be validated by the compiler, there&#39;s no point in it. You =
can get pseudoconst without any effort by simply not declaring it const. Bu=
t if you want to introduce a new concept it needs to be enforceable or it i=
sn&#39;t worth the work that goes into the change.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">If what you want is a sign on the door, you can =
do that with comments. If you want an iris-scanner and finger print reader =
combination deadbolt, three armed security guards, Lego blocks on the floor=
, a bobcat, and a moat containing sharks with lasers, that&#39;s when you n=
eed a language modification.</div></div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e6bbbb21-7d2d-438b-baaf-edf47f12204a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e6bbbb21-7d2d-438b-baaf-edf47f12204a=
%40isocpp.org</a>.<br />

------=_Part_12978_1041599610.1519617836572--

------=_Part_12977_1919291739.1519617836572--

.

------=_Part_273_1868045442.1519618075629
Content-Type: multipart/alternative;
 boundary="----=_Part_274_450344945.1519618075629"

------=_Part_274_450344945.1519618075629
Content-Type: text/plain; charset="UTF-8"

meant : methods M, const or pseudo const calls, reverse methods M in
reverse order

On Monday, February 26, 2018 at 5:03:56 AM UTC+1, jsaintm...@gmail.com
wrote:
>
> reverse ca be enforced by compiler if reversibility is created for basic
> types. As explained upper, a pseudo const or reversible method can call in
> this order : methods M, const calls, reverse methods M in reverse order
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63c52b36-d13a-4370-b6d0-bd7e30df4680%40isocpp.org.

------=_Part_274_450344945.1519618075629
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">meant : methods M, const or pseudo const calls, reverse me=
thods M in reverse order<br><br>On Monday, February 26, 2018 at 5:03:56 AM =
UTC+1, jsaintm...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">reverse ca be enforced by compiler if reversibility =
is created for basic types. As explained upper, a pseudo const or reversibl=
e method can call in this order : methods M, const calls, reverse methods M=
 in reverse order<br><br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/63c52b36-d13a-4370-b6d0-bd7e30df4680%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/63c52b36-d13a-4370-b6d0-bd7e30df4680=
%40isocpp.org</a>.<br />

------=_Part_274_450344945.1519618075629--

------=_Part_273_1868045442.1519618075629--

.

------=_Part_9594_1209600542.1519618505226
Content-Type: multipart/alternative;
 boundary="----=_Part_9595_100186521.1519618505226"

------=_Part_9595_100186521.1519618505226
Content-Type: text/plain; charset="UTF-8"

reversibility may be enforced by compiler if reversibility is created for
basic types. As explained upper, a pseudo const or reversible method can
call in this order : methods M, const or reversible calls, reverse methods
M in reverse order
- show quoted text -


On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>
> On 24 Feb 2018 08:54, <jsaintm...@gmail.com <javascript:>> wrote:
>
> But you may avoid a great number of fools -if not all- placing a sign
> "fools : no entry".
>
>
> No. They see it as an invitation.
>
> If a keyword can't be validated by the compiler, there's no point in it.
> You can get pseudoconst without any effort by simply not declaring it
> const. But if you want to introduce a new concept it needs to be
> enforceable or it isn't worth the work that goes into the change.
>
> If what you want is a sign on the door, you can do that with comments. If
> you want an iris-scanner and finger print reader combination deadbolt,
> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
> containing sharks with lasers, that's when you need a language modification.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5ea10cd9-179b-4fc4-8e4b-b01b2c0eb2cc%40isocpp.org.

------=_Part_9595_100186521.1519618505226
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">reversibility may be enforced by compiler if reversibility=
 is created for basic types.
 As explained upper, a pseudo const or reversible method can call in=20
this order : methods M, const or reversible calls, reverse methods M in rev=
erse order<div><div id=3D"t_q_O1eBoPpeAwAJ1" class=3D"F0XO1GC-Db-a">- show =
quoted text -</div></div>             <br><br>On Saturday, February 24, 201=
8 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-fam=
ily:sans-serif">On 24 Feb 2018 08:54, &lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"2j4Dx6J4AgAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">jsaintm...@gmail.com</a>&gt; wrote:<=
/span><br style=3D"font-family:sans-serif"><blockquote style=3D"font-family=
:sans-serif;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr">But you may avoid a great number of foo=
ls -if not all- placing a sign &quot;fools : no entry&quot;.=C2=A0</div></b=
lockquote></div><div dir=3D"auto"><br></div><div>No. They see it as an invi=
tation.<div dir=3D"auto"><br></div><div dir=3D"auto">If a keyword can&#39;t=
 be validated by the compiler, there&#39;s no point in it. You can get pseu=
doconst without any effort by simply not declaring it const. But if you wan=
t to introduce a new concept it needs to be enforceable or it isn&#39;t wor=
th the work that goes into the change.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">If what you want is a sign on the door, you can do that with=
 comments. If you want an iris-scanner and finger print reader combination =
deadbolt, three armed security guards, Lego blocks on the floor, a bobcat, =
and a moat containing sharks with lasers, that&#39;s when you need a langua=
ge modification.</div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5ea10cd9-179b-4fc4-8e4b-b01b2c0eb2cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5ea10cd9-179b-4fc4-8e4b-b01b2c0eb2cc=
%40isocpp.org</a>.<br />

------=_Part_9595_100186521.1519618505226--

------=_Part_9594_1209600542.1519618505226--

.

------=_Part_13084_1527451936.1519619206226
Content-Type: multipart/alternative;
 boundary="----=_Part_13085_1264837901.1519619206226"

------=_Part_13085_1264837901.1519619206226
Content-Type: text/plain; charset="UTF-8"

reversibility may be enforced by compiler if reversibility is created for
basic types. As explained upper, a pseudo const or reversible method can
call in this order : methods M, const or reversible methods, reverse
methods M in reverse order

On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>
> On 24 Feb 2018 08:54, <jsaintm...@gmail.com <javascript:>> wrote:
>
> But you may avoid a great number of fools -if not all- placing a sign
> "fools : no entry".
>
>
> No. They see it as an invitation.
>
> If a keyword can't be validated by the compiler, there's no point in it.
> You can get pseudoconst without any effort by simply not declaring it
> const. But if you want to introduce a new concept it needs to be
> enforceable or it isn't worth the work that goes into the change.
>
> If what you want is a sign on the door, you can do that with comments. If
> you want an iris-scanner and finger print reader combination deadbolt,
> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
> containing sharks with lasers, that's when you need a language modification.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/443b6a16-63bb-4267-96bb-09b874e97a92%40isocpp.org.

------=_Part_13085_1264837901.1519619206226
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">reversibility may be enforced by compiler if reversibility=
 is created for basic types.
 As explained upper, a pseudo const or reversible method can call in=20
this order : methods M, const or reversible methods, reverse methods M in r=
everse order<br><br>On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Ja=
ke Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"auto"><div dir=3D"auto"><span style=3D"font-family:sans-serif">On 24 Fe=
b 2018 08:54, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"2j4Dx6J4AgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">jsaintm...@gmail.com</a>&gt; wrote:</span><br style=3D"font-fa=
mily:sans-serif"><blockquote style=3D"font-family:sans-serif;margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr">But you may avoid a great number of fools -if not all- placing a =
sign &quot;fools : no entry&quot;.=C2=A0</div></blockquote></div><div dir=
=3D"auto"><br></div><div>No. They see it as an invitation.<div dir=3D"auto"=
><br></div><div dir=3D"auto">If a keyword can&#39;t be validated by the com=
piler, there&#39;s no point in it. You can get pseudoconst without any effo=
rt by simply not declaring it const. But if you want to introduce a new con=
cept it needs to be enforceable or it isn&#39;t worth the work that goes in=
to the change.</div><div dir=3D"auto"><br></div><div dir=3D"auto">If what y=
ou want is a sign on the door, you can do that with comments. If you want a=
n iris-scanner and finger print reader combination deadbolt, three armed se=
curity guards, Lego blocks on the floor, a bobcat, and a moat containing sh=
arks with lasers, that&#39;s when you need a language modification.</div></=
div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/443b6a16-63bb-4267-96bb-09b874e97a92%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/443b6a16-63bb-4267-96bb-09b874e97a92=
%40isocpp.org</a>.<br />

------=_Part_13085_1264837901.1519619206226--

------=_Part_13084_1527451936.1519619206226--

.

------=_Part_13288_23604070.1519620654260
Content-Type: multipart/alternative;
 boundary="----=_Part_13289_1717417303.1519620654261"

------=_Part_13289_1717417303.1519620654261
Content-Type: text/plain; charset="UTF-8"

reversibility may be enforced by compiler if reversibility is created for
basic types. As explained upper, a pseudo const or reversible method MUST
in this order : methods M, const or reversible methods, reverse methods M
in reverse order

On Monday, February 26, 2018 at 5:26:46 AM UTC+1, jsaintm...@gmail.com
wrote:
>
> reversibility may be enforced by compiler if reversibility is created for
> basic types. As explained upper, a pseudo const or reversible method can
> call in this order : methods M, const or reversible methods, reverse
> methods M in reverse order
>
> On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>>
>> On 24 Feb 2018 08:54, <jsaintm...@gmail.com> wrote:
>>
>> But you may avoid a great number of fools -if not all- placing a sign
>> "fools : no entry".
>>
>>
>> No. They see it as an invitation.
>>
>> If a keyword can't be validated by the compiler, there's no point in it.
>> You can get pseudoconst without any effort by simply not declaring it
>> const. But if you want to introduce a new concept it needs to be
>> enforceable or it isn't worth the work that goes into the change.
>>
>> If what you want is a sign on the door, you can do that with comments. If
>> you want an iris-scanner and finger print reader combination deadbolt,
>> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
>> containing sharks with lasers, that's when you need a language modification.
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2821851-d799-4c12-8716-64e8a299b4c1%40isocpp.org.

------=_Part_13289_1717417303.1519620654261
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">reversibility may be enforced by compiler if reversibility=
 is created for basic types.
 As explained upper, a pseudo const or reversible method MUST in=20
this order : methods M, const or reversible methods, reverse methods M in r=
everse order<br><br>On Monday, February 26, 2018 at 5:26:46 AM UTC+1, jsain=
tm...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">reversibility may be enforced by compiler if reversibility is crea=
ted for basic types.
 As explained upper, a pseudo const or reversible method can call in=20
this order : methods M, const or reversible methods, reverse methods M in r=
everse order<br><br>On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Ja=
ke Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"aut=
o"><div dir=3D"auto"><span style=3D"font-family:sans-serif">On 24 Feb 2018 =
08:54, &lt;<a rel=3D"nofollow">jsaintm...@gmail.com</a>&gt; wrote:</span><b=
r style=3D"font-family:sans-serif"><blockquote style=3D"font-family:sans-se=
rif;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">But you may avoid a great number of fools -if n=
ot all- placing a sign &quot;fools : no entry&quot;.=C2=A0</div></blockquot=
e></div><div dir=3D"auto"><br></div><div>No. They see it as an invitation.<=
div dir=3D"auto"><br></div><div dir=3D"auto">If a keyword can&#39;t be vali=
dated by the compiler, there&#39;s no point in it. You can get pseudoconst =
without any effort by simply not declaring it const. But if you want to int=
roduce a new concept it needs to be enforceable or it isn&#39;t worth the w=
ork that goes into the change.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">If what you want is a sign on the door, you can do that with comment=
s. If you want an iris-scanner and finger print reader combination deadbolt=
, three armed security guards, Lego blocks on the floor, a bobcat, and a mo=
at containing sharks with lasers, that&#39;s when you need a language modif=
ication.</div></div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b2821851-d799-4c12-8716-64e8a299b4c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2821851-d799-4c12-8716-64e8a299b4c1=
%40isocpp.org</a>.<br />

------=_Part_13289_1717417303.1519620654261--

------=_Part_13288_23604070.1519620654260--

.

------=_Part_1182_91584446.1519620745386
Content-Type: multipart/alternative;
 boundary="----=_Part_1183_1640645963.1519620745387"

------=_Part_1183_1640645963.1519620745387
Content-Type: text/plain; charset="UTF-8"

reversibility may be enforced by compiler if reversibility is created for
basic types. As explained upper, a pseudo const or reversible method SHOULD
call in this order : methods M, const or reversible methods, reverse
methods M in reverse order


On Monday, February 26, 2018 at 5:26:46 AM UTC+1, jsaintm...@gmail.com
wrote:
>
> reversibility may be enforced by compiler if reversibility is created for
> basic types. As explained upper, a pseudo const or reversible method can
> call in this order : methods M, const or reversible methods, reverse
> methods M in reverse order
>
> On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>>
>> On 24 Feb 2018 08:54, <jsaintm...@gmail.com> wrote:
>>
>> But you may avoid a great number of fools -if not all- placing a sign
>> "fools : no entry".
>>
>>
>> No. They see it as an invitation.
>>
>> If a keyword can't be validated by the compiler, there's no point in it.
>> You can get pseudoconst without any effort by simply not declaring it
>> const. But if you want to introduce a new concept it needs to be
>> enforceable or it isn't worth the work that goes into the change.
>>
>> If what you want is a sign on the door, you can do that with comments. If
>> you want an iris-scanner and finger print reader combination deadbolt,
>> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
>> containing sharks with lasers, that's when you need a language modification.
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86c42ca9-81dc-4988-83b6-f7a0b7a819b2%40isocpp.org.

------=_Part_1183_1640645963.1519620745387
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">reversibility may be enforced by compiler if reversibility=
 is created for basic types.
 As explained upper, a pseudo const or reversible method SHOULD call in=20
this order : methods M, const or reversible methods, reverse methods M in r=
everse order<br><br><br>On Monday, February 26, 2018 at 5:26:46 AM UTC+1, j=
saintm...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr">reversibility may be enforced by compiler if reversibility is =
created for basic types.
 As explained upper, a pseudo const or reversible method can call in=20
this order : methods M, const or reversible methods, reverse methods M in r=
everse order<br><br>On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Ja=
ke Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"aut=
o"><div dir=3D"auto"><span style=3D"font-family:sans-serif">On 24 Feb 2018 =
08:54, &lt;<a rel=3D"nofollow">jsaintm...@gmail.com</a>&gt; wrote:</span><b=
r style=3D"font-family:sans-serif"><blockquote style=3D"font-family:sans-se=
rif;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">But you may avoid a great number of fools -if n=
ot all- placing a sign &quot;fools : no entry&quot;.=C2=A0</div></blockquot=
e></div><div dir=3D"auto"><br></div><div>No. They see it as an invitation.<=
div dir=3D"auto"><br></div><div dir=3D"auto">If a keyword can&#39;t be vali=
dated by the compiler, there&#39;s no point in it. You can get pseudoconst =
without any effort by simply not declaring it const. But if you want to int=
roduce a new concept it needs to be enforceable or it isn&#39;t worth the w=
ork that goes into the change.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">If what you want is a sign on the door, you can do that with comment=
s. If you want an iris-scanner and finger print reader combination deadbolt=
, three armed security guards, Lego blocks on the floor, a bobcat, and a mo=
at containing sharks with lasers, that&#39;s when you need a language modif=
ication.</div></div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/86c42ca9-81dc-4988-83b6-f7a0b7a819b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/86c42ca9-81dc-4988-83b6-f7a0b7a819b2=
%40isocpp.org</a>.<br />

------=_Part_1183_1640645963.1519620745387--

------=_Part_1182_91584446.1519620745386--

.

------=_Part_13311_1095586059.1519621902958
Content-Type: multipart/alternative;
 boundary="----=_Part_13312_143217364.1519621902958"

------=_Part_13312_143217364.1519621902958
Content-Type: text/plain; charset="UTF-8"

all you need to do is to add the reverse and reversible qualifiers for
basic types

On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>
> On 24 Feb 2018 08:54, <jsaintm...@gmail.com <javascript:>> wrote:
>
> But you may avoid a great number of fools -if not all- placing a sign
> "fools : no entry".
>
>
> No. They see it as an invitation.
>
> If a keyword can't be validated by the compiler, there's no point in it.
> You can get pseudoconst without any effort by simply not declaring it
> const. But if you want to introduce a new concept it needs to be
> enforceable or it isn't worth the work that goes into the change.
>
> If what you want is a sign on the door, you can do that with comments. If
> you want an iris-scanner and finger print reader combination deadbolt,
> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
> containing sharks with lasers, that's when you need a language modification.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/137c4cf9-a19b-45ee-93b1-8cd75d1e0bbf%40isocpp.org.

------=_Part_13312_143217364.1519621902958
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">all you need to do is to add the reverse and reversible qu=
alifiers for basic types<br><br>On Saturday, February 24, 2018 at 10:18:07 =
AM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-family:sans-serif=
">On 24 Feb 2018 08:54, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"2j4Dx6J4AgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jsaintm...@gmail.com</a>&gt; wrote:</span><br style=
=3D"font-family:sans-serif"><blockquote style=3D"font-family:sans-serif;mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">But you may avoid a great number of fools -if not all-=
 placing a sign &quot;fools : no entry&quot;.=C2=A0</div></blockquote></div=
><div dir=3D"auto"><br></div><div>No. They see it as an invitation.<div dir=
=3D"auto"><br></div><div dir=3D"auto">If a keyword can&#39;t be validated b=
y the compiler, there&#39;s no point in it. You can get pseudoconst without=
 any effort by simply not declaring it const. But if you want to introduce =
a new concept it needs to be enforceable or it isn&#39;t worth the work tha=
t goes into the change.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
If what you want is a sign on the door, you can do that with comments. If y=
ou want an iris-scanner and finger print reader combination deadbolt, three=
 armed security guards, Lego blocks on the floor, a bobcat, and a moat cont=
aining sharks with lasers, that&#39;s when you need a language modification=
..</div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/137c4cf9-a19b-45ee-93b1-8cd75d1e0bbf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/137c4cf9-a19b-45ee-93b1-8cd75d1e0bbf=
%40isocpp.org</a>.<br />

------=_Part_13312_143217364.1519621902958--

------=_Part_13311_1095586059.1519621902958--

.

------=_Part_317_191741583.1519624776781
Content-Type: multipart/alternative;
 boundary="----=_Part_318_22865559.1519624776782"

------=_Part_318_22865559.1519624776782
Content-Type: text/plain; charset="UTF-8"

...and then compilator may enforce reversibility, as explained above : calls
to methods M, calls to const or reversible methods, calls to reverse
methods M in reverse

On Monday, February 26, 2018 at 6:11:43 AM UTC+1, jsaintm...@gmail.com
wrote:
>
> all you need to do is to add the reverse and reversible qualifiers for
> basic types
>
> On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>>
>> On 24 Feb 2018 08:54, <jsaintm...@gmail.com> wrote:
>>
>> But you may avoid a great number of fools -if not all- placing a sign
>> "fools : no entry".
>>
>>
>> No. They see it as an invitation.
>>
>> If a keyword can't be validated by the compiler, there's no point in it.
>> You can get pseudoconst without any effort by simply not declaring it
>> const. But if you want to introduce a new concept it needs to be
>> enforceable or it isn't worth the work that goes into the change.
>>
>> If what you want is a sign on the door, you can do that with comments. If
>> you want an iris-scanner and finger print reader combination deadbolt,
>> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
>> containing sharks with lasers, that's when you need a language modification.
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a31a08ce-db18-4937-877b-7c1bb49b3489%40isocpp.org.

------=_Part_318_22865559.1519624776782
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">..and then compilator may enforce reversibility, as explai=
ned above : calls to methods M, calls to const or reversible methods, calls=
 to reverse methods M in reverse<br><br>On Monday, February 26, 2018 at 6:1=
1:43 AM UTC+1, jsaintm...@gmail.com wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr">all you need to do is to add the reverse and r=
eversible qualifiers for basic types<br><br>On Saturday, February 24, 2018 =
at 10:18:07 AM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-family:san=
s-serif">On 24 Feb 2018 08:54, &lt;<a rel=3D"nofollow">jsaintm...@gmail.com=
</a>&gt; wrote:</span><br style=3D"font-family:sans-serif"><blockquote styl=
e=3D"font-family:sans-serif;margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">But you may avoid a gre=
at number of fools -if not all- placing a sign &quot;fools : no entry&quot;=
..=C2=A0</div></blockquote></div><div dir=3D"auto"><br></div><div>No. They s=
ee it as an invitation.<div dir=3D"auto"><br></div><div dir=3D"auto">If a k=
eyword can&#39;t be validated by the compiler, there&#39;s no point in it. =
You can get pseudoconst without any effort by simply not declaring it const=
.. But if you want to introduce a new concept it needs to be enforceable or =
it isn&#39;t worth the work that goes into the change.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">If what you want is a sign on the door, you =
can do that with comments. If you want an iris-scanner and finger print rea=
der combination deadbolt, three armed security guards, Lego blocks on the f=
loor, a bobcat, and a moat containing sharks with lasers, that&#39;s when y=
ou need a language modification.</div></div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a31a08ce-db18-4937-877b-7c1bb49b3489%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a31a08ce-db18-4937-877b-7c1bb49b3489=
%40isocpp.org</a>.<br />

------=_Part_318_22865559.1519624776782--

------=_Part_317_191741583.1519624776781--

.

------=_Part_5213_1477533256.1519625954470
Content-Type: multipart/alternative;
 boundary="----=_Part_5214_427866863.1519625954471"

------=_Part_5214_427866863.1519625954471
Content-Type: text/plain; charset="UTF-8"

.... and a few mutex...

On Monday, February 26, 2018 at 6:11:43 AM UTC+1, jsaintm...@gmail.com
wrote:
>
> all you need to do is to add the reverse and reversible qualifiers for
> basic types
>
> On Saturday, February 24, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:
>>
>> On 24 Feb 2018 08:54, <jsaintm...@gmail.com> wrote:
>>
>> But you may avoid a great number of fools -if not all- placing a sign
>> "fools : no entry".
>>
>>
>> No. They see it as an invitation.
>>
>> If a keyword can't be validated by the compiler, there's no point in it.
>> You can get pseudoconst without any effort by simply not declaring it
>> const. But if you want to introduce a new concept it needs to be
>> enforceable or it isn't worth the work that goes into the change.
>>
>> If what you want is a sign on the door, you can do that with comments. If
>> you want an iris-scanner and finger print reader combination deadbolt,
>> three armed security guards, Lego blocks on the floor, a bobcat, and a moat
>> containing sharks with lasers, that's when you need a language modification.
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7e7aeb82-3c0b-49fc-be99-59b63cc912d2%40isocpp.org.

------=_Part_5214_427866863.1519625954471
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">... and a few mutex...<br><br>On Monday, February 26, 2018=
 at 6:11:43 AM UTC+1, jsaintm...@gmail.com wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">all you need to do is to add the revers=
e and reversible qualifiers for basic types<br><br>On Saturday, February 24=
, 2018 at 10:18:07 AM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-fam=
ily:sans-serif">On 24 Feb 2018 08:54, &lt;<a rel=3D"nofollow">jsaintm...@gm=
ail.com</a>&gt; wrote:</span><br style=3D"font-family:sans-serif"><blockquo=
te style=3D"font-family:sans-serif;margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">But you may avoi=
d a great number of fools -if not all- placing a sign &quot;fools : no entr=
y&quot;.=C2=A0</div></blockquote></div><div dir=3D"auto"><br></div><div>No.=
 They see it as an invitation.<div dir=3D"auto"><br></div><div dir=3D"auto"=
>If a keyword can&#39;t be validated by the compiler, there&#39;s no point =
in it. You can get pseudoconst without any effort by simply not declaring i=
t const. But if you want to introduce a new concept it needs to be enforcea=
ble or it isn&#39;t worth the work that goes into the change.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">If what you want is a sign on the doo=
r, you can do that with comments. If you want an iris-scanner and finger pr=
int reader combination deadbolt, three armed security guards, Lego blocks o=
n the floor, a bobcat, and a moat containing sharks with lasers, that&#39;s=
 when you need a language modification.</div></div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7e7aeb82-3c0b-49fc-be99-59b63cc912d2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7e7aeb82-3c0b-49fc-be99-59b63cc912d2=
%40isocpp.org</a>.<br />

------=_Part_5214_427866863.1519625954471--

------=_Part_5213_1477533256.1519625954470--

.

------=_Part_6126_1363222138.1519849840991
Content-Type: multipart/alternative;
 boundary="----=_Part_6127_928035103.1519849840992"

------=_Part_6127_928035103.1519849840992
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Another use of pseudoconst / reversible would allow to use hint to find an=
=20
element in map within a pseudo const method. As far as I know,
m.insert (ihint, p) exists,=20
but not map.find (ihint, p)

With peudo const, you could write your pseudoconst find,  like this, if you=
=20
are certain -1 is not a second existing in the map, and map.erase (i) was=
=20
defined as the reverse of insert (i) :

std::map<size_t, size_t>::iterator find (std::map<size_t, size_t>& m,=20
std::pair<size_t, size_t>& p)  reversible {
  std::pair<size_t, size_t> p2 .(p.first, (size_t) -1);
  m.insert (ihint, p);
  if (ihint->second =3D=3D (size_t) -1) {
    m.erase (ihint);
    ihint =3D m.end ();
  }
  return ihint;
}
 =20


"
On Friday, February 23, 2018 at 1:27:03 PM UTC+1, Jake Arkinstall wrote:
>
> On 23 Feb 2018 08:58, "J=C3=A9r=C3=B4me Saint-Martin" <jsaintm...@gmail.c=
om=20
> <javascript:>> wrote:
>
> pseudo const Is an indication to users : "the method should not change th=
e=20
> object".=20
>
>
> *Const* is an *guarantee* to users: the method *does* not change the=20
> object. A pseudoconst method would also have to guarantee this or the=20
> proposal wouldn't be useful at all. So, once again, come up with a way of=
=20
> guranteeing that a modification is reversed. A "reversible" or similar=20
> keyword would be more interesting. All it needs to do is only permit a=20
> series of commands and functions that are themselves reversible (ones tha=
t=20
> lose no information, so type limitations must be considered - see, for=20
> example, http://cpp.sh/9fet5 and http://cpp.sh/9redh ), in the same way=
=20
> that const only permits use of operations that are also const. Then you=
=20
> need something built into the language that does the reversing.
>
> This could be useful in a variety of situations. One of which would be an=
=20
> enforceable pseudoconst.
>
"=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4b81b3b8-5def-4003-b073-89af676e837a%40isocpp.or=
g.

------=_Part_6127_928035103.1519849840992
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Another use of pseudoconst / reversible would allow to use=
 hint to find an element in map within a pseudo const method. As far as I k=
now,<br>m.insert (ihint, p) exists, <br>but not map.find (ihint, p)<br><br>=
With peudo const, you could write your pseudoconst find,=C2=A0 like this, i=
f you are certain -1 is not a second existing in the map, and map.erase (i)=
 was defined as the reverse of insert (i) :<br><br>std::map&lt;size_t, size=
_t&gt;::iterator find (std::map&lt;size_t, size_t&gt;&amp; m, std::pair&lt;=
size_t, size_t&gt;&amp; p)=C2=A0 reversible {<br>=C2=A0 std::pair&lt;size_t=
, size_t&gt; p2 .(p.first, (size_t) -1);<br>=C2=A0 m.insert (ihint, p);<br>=
=C2=A0 if (ihint-&gt;second =3D=3D (size_t) -1) {<br>=C2=A0=C2=A0=C2=A0 m.e=
rase (ihint);<br>=C2=A0=C2=A0=C2=A0 ihint =3D m.end ();<br>=C2=A0 }<br>=C2=
=A0 return ihint;<br>}<br>=C2=A0 <br><br><br>&quot;<br>On Friday, February =
23, 2018 at 1:27:03 PM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"auto"><div><div><div class=3D"gmail_quote=
">On 23 Feb 2018 08:58, &quot;J=C3=A9r=C3=B4me Saint-Martin&quot; &lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"WqpozgUTAAAJ"=
 rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jsaintm...=
@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>pseudo const Is an indication to users : &quot;the method should not chang=
e the object&quot;.=C2=A0</div></blockquote></div></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto"><i>Const</i> is an <i>guarantee</i> to use=
rs: the method <i>does</i>=C2=A0not change the object. A pseudoconst method=
 would also have to guarantee this or the proposal wouldn&#39;t be useful a=
t all. So, once again, come up with a way of guranteeing that a modificatio=
n is reversed. A &quot;reversible&quot; or similar keyword would be more in=
teresting. All it needs to do is only permit a series of commands and funct=
ions that are themselves reversible (ones that lose no information, so type=
 limitations must be considered - see, for example, <a href=3D"http://cpp.s=
h/9fet5" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcpp.sh%2F9fet5\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNGsOlE-ePVnks77rm2pF2hvT8zUkA&#39;;return true;" on=
click=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcpp.s=
h%2F9fet5\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGsOlE-ePVnks77rm2pF2hvT8z=
UkA&#39;;return true;">http://cpp.sh/9fet5</a> and <a href=3D"http://cpp.sh=
/9redh" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fcpp.sh%2F9redh\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNGXDPCUOcwWbKeaQxa7t7nZSpb9VQ&#39;;return true;" onc=
lick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcpp.sh=
%2F9redh\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXDPCUOcwWbKeaQxa7t7nZSpb9=
VQ&#39;;return true;">http://cpp.sh/9redh</a> ), in the same way that const=
 only permits use of operations that are also const. Then you need somethin=
g built into the language that does the reversing.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">This could be useful in a variety of situations.=
 One of which would be an enforceable pseudoconst.</div></div></blockquote>=
<div>&quot; <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4b81b3b8-5def-4003-b073-89af676e837a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4b81b3b8-5def-4003-b073-89af676e837a=
%40isocpp.org</a>.<br />

------=_Part_6127_928035103.1519849840992--

------=_Part_6126_1363222138.1519849840991--

.

------=_Part_6113_1649933323.1519850003959
Content-Type: multipart/alternative;
 boundary="----=_Part_6114_1652001258.1519850003959"

------=_Part_6114_1652001258.1519850003959
Content-Type: text/plain; charset="UTF-8"

sorry, ihint = m.insert (ihint, p2) instead od m.insert (ihint, p)

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/13824ba7-65be-47d6-ae27-aee4737e4612%40isocpp.org.

------=_Part_6114_1652001258.1519850003959
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">sorry, ihint =3D m.insert (ihint, p2) instead od m.insert =
(ihint, p)<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/13824ba7-65be-47d6-ae27-aee4737e4612%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/13824ba7-65be-47d6-ae27-aee4737e4612=
%40isocpp.org</a>.<br />

------=_Part_6114_1652001258.1519850003959--

------=_Part_6113_1649933323.1519850003959--

.

------=_Part_6237_1480348875.1519853884684
Content-Type: multipart/alternative;
 boundary="----=_Part_6238_1401434131.1519853884684"

------=_Part_6238_1401434131.1519853884684
Content-Type: text/plain; charset="UTF-8"

On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5, jsaintm...@gmail.com
wrote:
>
> Another use of pseudoconst / reversible would allow to use hint to find an
> element in map within a pseudo const method. As far as I know,
> m.insert (ihint, p) exists,
> but not map.find (ihint, p)
>

I fail to see how pseudoconst would be an essential element to such a
function.

With peudo const, you could write your pseudoconst find,  like this, if you
> are certain -1 is not a second existing in the map, and map.erase (i) was
> defined as the reverse of insert (i) :
>

But *why would you want to?* I don't see any performance improvement from
this function. Because if you fail to find the item, then you have to go
through the process of creating the element only to destroy it. Why would
you do that? Creating elements requires allocating memory, which is pretty
expensive.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d742b2d7-0e2a-49c8-ade1-7f21199367cc%40isocpp.org.

------=_Part_6238_1401434131.1519853884684
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5, jsain=
tm...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Another use of pseudoconst / reversible would allow to use hint to=
 find an element in map within a pseudo const method. As far as I know,<br>=
m.insert (ihint, p) exists, <br>but not map.find (ihint, p)<br></div></bloc=
kquote><div><br>I fail to see how pseudoconst would be an essential element=
 to such a function.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">With peudo const, you could write your pseudoconst f=
ind,=C2=A0 like this, if you are certain -1 is not a second existing in the=
 map, and map.erase (i) was defined as the reverse of insert (i) :<br></div=
></blockquote><div><br>But <i>why would you want to?</i> I don&#39;t see an=
y performance improvement from this function. Because if you fail to find t=
he item, then you have to go through the process of creating the element on=
ly to destroy it. Why would you do that? Creating elements requires allocat=
ing memory, which is pretty expensive.<br></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d742b2d7-0e2a-49c8-ade1-7f21199367cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d742b2d7-0e2a-49c8-ade1-7f21199367cc=
%40isocpp.org</a>.<br />

------=_Part_6238_1401434131.1519853884684--

------=_Part_6237_1480348875.1519853884684--

.

------=_Part_911_299835616.1519888549887
Content-Type: multipart/alternative;
 boundary="----=_Part_912_904627536.1519888549887"

------=_Part_912_904627536.1519888549887
Content-Type: text/plain; charset="UTF-8"

In this function, I am using insert instead of find, because it allows
hint. Insert is not const, but the element inserted is be erased

On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas wrote:
>
> On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5, jsaintm...@gmail.com
> wrote:
>>
>> Another use of pseudoconst / reversible would allow to use hint to find
>> an element in map within a pseudo const method. As far as I know,
>> m.insert (ihint, p) exists,
>> but not map.find (ihint, p)
>>
>
> I fail to see how pseudoconst would be an essential element to such a
> function.
>
> With peudo const, you could write your pseudoconst find,  like this, if
>> you are certain -1 is not a second existing in the map, and map.erase (i)
>> was defined as the reverse of insert (i) :
>>
>
> But *why would you want to?* I don't see any performance improvement from
> this function. Because if you fail to find the item, then you have to go
> through the process of creating the element only to destroy it. Why would
> you do that? Creating elements requires allocating memory, which is pretty
> expensive.
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org.

------=_Part_912_904627536.1519888549887
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In this function, I am using insert instead of find, becau=
se it allows hint. Insert is not const, but the element inserted is be eras=
ed<br><br>On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Wed=
nesday, February 28, 2018 at 3:30:41 PM UTC-5, <a>jsaintm...@gmail.com</a> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Another use =
of pseudoconst / reversible would allow to use hint to find an element in m=
ap within a pseudo const method. As far as I know,<br>m.insert (ihint, p) e=
xists, <br>but not map.find (ihint, p)<br></div></blockquote><div><br>I fai=
l to see how pseudoconst would be an essential element to such a function.<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">With =
peudo const, you could write your pseudoconst find,=C2=A0 like this, if you=
 are certain -1 is not a second existing in the map, and map.erase (i) was =
defined as the reverse of insert (i) :<br></div></blockquote><div><br>But <=
i>why would you want to?</i> I don&#39;t see any performance improvement fr=
om this function. Because if you fail to find the item, then you have to go=
 through the process of creating the element only to destroy it. Why would =
you do that? Creating elements requires allocating memory, which is pretty =
expensive.<br></div><br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d=
%40isocpp.org</a>.<br />

------=_Part_912_904627536.1519888549887--

------=_Part_911_299835616.1519888549887--

.

--001a11450c9ece2d30056656e39e
Content-Type: text/plain; charset="UTF-8"

Forgive me but I am still struggling to see the difference between const
and pseudo-const.

A long long time ago, when I used to write embedded C, "const" meant "it's
in ROM. It won't change even if you write to it". (they were simple
proprietary systems with no MMU and I wrote custom linker scripts and c
runtime startup code).

Then c++ came along and const meant "This method will not change the
logical state of the object". Which it seems to me is precisely what you
are intending to communicate with "pesudo-const". I understand that your
intention is to communicate that there will be some temporary modification
of state, but there are 2 problems with this:

1. Because the c++ memory model is single-threaded, the fact that there
have been internal state changes during the call is irrelevant. Those state
changes are not observable to the caller, so for all intents and purposes,
"pseudo-const" and "const" as it currently stand mean precisely the same
thing.

2. Telling the caller that there will be some temporary, invisible,
un-observable state change during a call which is for him/her atomic, is
simply leaking information that the caller has no way of using. It conveys
no more useful information than "const". There is therefore no use-case for
it.

In reality, the "const" keyword when applied to a method, already means
"pseudo-const". This is because we have mutable members.

There might be an argument for a new attribute (say, [[immutable]]), which
would indicate that the value is utterly immutable for the life of the
program, and that a method marked as such will always return the same value
(allowing the compiler to cache the results of calls).

Although we kind-of have that with constexpr already.

Summary:

* The existing keyword "const" really means "psuedo-const".

* const objects in c++ are not *really* constants.

* const methods are already allowed to modify internal state, but good
manners dictates that these internal state changes are not observable to
client code.



On 1 March 2018 at 07:15, <jsaintmartin356@gmail.com> wrote:

> In this function, I am using insert instead of find, because it allows
> hint. Insert is not const, but the element inserted is be erased
>
> On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas wrote:
>>
>> On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5, jsaintm...@gmail.com
>> wrote:
>>>
>>> Another use of pseudoconst / reversible would allow to use hint to find
>>> an element in map within a pseudo const method. As far as I know,
>>> m.insert (ihint, p) exists,
>>> but not map.find (ihint, p)
>>>
>>
>> I fail to see how pseudoconst would be an essential element to such a
>> function.
>>
>> With peudo const, you could write your pseudoconst find,  like this, if
>>> you are certain -1 is not a second existing in the map, and map.erase (i)
>>> was defined as the reverse of insert (i) :
>>>
>>
>> But *why would you want to?* I don't see any performance improvement
>> from this function. Because if you fail to find the item, then you have to
>> go through the process of creating the element only to destroy it. Why
>> would you do that? Creating elements requires allocating memory, which is
>> pretty expensive.
>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-
> 8ebe-a1b1936ab96d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZkoJWH4FYfSjAXjiqKSA3zT1Wpw5jnF4qZa%3DWivYkX8w%40mail.gmail.com.

--001a11450c9ece2d30056656e39e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Forgive me but I am still struggling to see the difference=
 between const and pseudo-const.<div><br></div><div>A long long time ago, w=
hen I used to write embedded C, &quot;const&quot; meant &quot;it&#39;s in R=
OM. It won&#39;t change even if you write to it&quot;. (they were simple pr=
oprietary systems with no MMU and I wrote custom linker scripts and c runti=
me startup code).</div><div><br></div><div>Then c++ came along and const me=
ant &quot;This method will not change the logical state of the object&quot;=
.. Which it seems to me is precisely what you are intending to communicate w=
ith &quot;pesudo-const&quot;. I understand that your intention is to commun=
icate that there will be some temporary modification of state, but there ar=
e 2 problems with this:</div><div><br></div><div>1. Because the c++ memory =
model is single-threaded, the fact that there have been internal state chan=
ges during the call is irrelevant. Those state changes are not observable t=
o the caller, so for all intents and purposes, &quot;pseudo-const&quot; and=
 &quot;const&quot; as it currently stand mean precisely the same thing.</di=
v><div><br></div><div>2. Telling the caller that there will be some tempora=
ry, invisible, un-observable state change during a call which is for him/he=
r atomic, is simply leaking information that the caller has no way of using=
.. It conveys no more useful information than &quot;const&quot;. There is th=
erefore no use-case for it.</div><div><br></div><div>In reality, the &quot;=
const&quot; keyword when applied to a method, already means &quot;pseudo-co=
nst&quot;. This is because we have mutable members.</div><div><br></div><di=
v>There might be an argument for a new attribute (say, <span style=3D"color=
:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:norm=
al;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;l=
etter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-d=
ecoration-style:initial;text-decoration-color:initial;float:none;display:in=
line">[[immutable]])</span>, which would indicate that the value is utterly=
 immutable for the life of the program, and that a method marked as such wi=
ll always return the same value (allowing the compiler to cache the results=
 of calls).</div><div><br></div><div>Although we kind-of have that with con=
stexpr already.</div><div><br></div><div>Summary:</div><div><br></div><div>=
* The existing keyword &quot;const&quot; really means &quot;psuedo-const&qu=
ot;.</div><div><br></div><div>* const objects in c++ are not *really* const=
ants.</div><div><br></div><div>* const methods are already allowed to modif=
y internal state, but good manners dictates that these internal state chang=
es are not observable to client code.</div><div><br></div><div>=C2=A0</div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 1 March =
2018 at 07:15,  <span dir=3D"ltr">&lt;<a href=3D"mailto:jsaintmartin356@gma=
il.com" target=3D"_blank">jsaintmartin356@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">In this function, I am us=
ing insert instead of find, because it allows hint. Insert is not const, bu=
t the element inserted is be erased<span class=3D""><br><br>On Wednesday, F=
ebruary 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, February 28, 2018 at =
3:30:41 PM UTC-5, <a>jsaintm...@gmail.com</a> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">Another use of pseudoconst / reversible w=
ould allow to use hint to find an element in map within a pseudo const meth=
od. As far as I know,<br>m.insert (ihint, p) exists, <br>but not map.find (=
ihint, p)<br></div></blockquote><div><br>I fail to see how pseudoconst woul=
d be an essential element to such a function.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">With peudo const, you could write =
your pseudoconst find,=C2=A0 like this, if you are certain -1 is not a seco=
nd existing in the map, and map.erase (i) was defined as the reverse of ins=
ert (i) :<br></div></blockquote><div><br>But <i>why would you want to?</i> =
I don&#39;t see any performance improvement from this function. Because if =
you fail to find the item, then you have to go through the process of creat=
ing the element only to destroy it. Why would you do that? Creating element=
s requires allocating memory, which is pretty expensive.<br></div><br></div=
></blockquote></span></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/34d1=
dde0-b9fd-4565-<wbr>8ebe-a1b1936ab96d%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZkoJWH4FYfSjAXjiqKSA3zT1Wpw5jn=
F4qZa%3DWivYkX8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZkoJWH4F=
YfSjAXjiqKSA3zT1Wpw5jnF4qZa%3DWivYkX8w%40mail.gmail.com</a>.<br />

--001a11450c9ece2d30056656e39e--

.

------=_Part_1612_904279504.1519909701016
Content-Type: multipart/alternative;
 boundary="----=_Part_1613_670702054.1519909701017"

------=_Part_1613_670702054.1519909701017
Content-Type: text/plain; charset="UTF-8"

Thanks for the lesson. My error : I believed mutable allowed the method to
change a const object permanently.

On Thursday, March 1, 2018 at 10:57:41 AM UTC+1, Richard Hodges wrote:
>
> Forgive me but I am still struggling to see the difference between const
> and pseudo-const.
>
> A long long time ago, when I used to write embedded C, "const" meant "it's
> in ROM. It won't change even if you write to it". (they were simple
> proprietary systems with no MMU and I wrote custom linker scripts and c
> runtime startup code).
>
> Then c++ came along and const meant "This method will not change the
> logical state of the object". Which it seems to me is precisely what you
> are intending to communicate with "pesudo-const". I understand that your
> intention is to communicate that there will be some temporary modification
> of state, but there are 2 problems with this:
>
> 1. Because the c++ memory model is single-threaded, the fact that there
> have been internal state changes during the call is irrelevant. Those state
> changes are not observable to the caller, so for all intents and purposes,
> "pseudo-const" and "const" as it currently stand mean precisely the same
> thing.
>
> 2. Telling the caller that there will be some temporary, invisible,
> un-observable state change during a call which is for him/her atomic, is
> simply leaking information that the caller has no way of using. It conveys
> no more useful information than "const". There is therefore no use-case for
> it.
>
> In reality, the "const" keyword when applied to a method, already means
> "pseudo-const". This is because we have mutable members.
>
> There might be an argument for a new attribute (say, [[immutable]]),
> which would indicate that the value is utterly immutable for the life of
> the program, and that a method marked as such will always return the same
> value (allowing the compiler to cache the results of calls).
>
> Although we kind-of have that with constexpr already.
>
> Summary:
>
> * The existing keyword "const" really means "psuedo-const".
>
> * const objects in c++ are not *really* constants.
>
> * const methods are already allowed to modify internal state, but good
> manners dictates that these internal state changes are not observable to
> client code.
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b79887f4-2be1-4e2c-9231-75b1b1e7c982%40isocpp.org.

------=_Part_1613_670702054.1519909701017
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the lesson. My error : I believed mutable allow=
ed the method to change a const object permanently.<br><br>On Thursday, Mar=
ch 1, 2018 at 10:57:41 AM UTC+1, Richard Hodges wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">Forgive me but I am still struggli=
ng to see the difference between const and pseudo-const.<div><br></div><div=
>A long long time ago, when I used to write embedded C, &quot;const&quot; m=
eant &quot;it&#39;s in ROM. It won&#39;t change even if you write to it&quo=
t;. (they were simple proprietary systems with no MMU and I wrote custom li=
nker scripts and c runtime startup code).</div><div><br></div><div>Then c++=
 came along and const meant &quot;This method will not change the logical s=
tate of the object&quot;. Which it seems to me is precisely what you are in=
tending to communicate with &quot;pesudo-const&quot;. I understand that you=
r intention is to communicate that there will be some temporary modificatio=
n of state, but there are 2 problems with this:</div><div><br></div><div>1.=
 Because the c++ memory model is single-threaded, the fact that there have =
been internal state changes during the call is irrelevant. Those state chan=
ges are not observable to the caller, so for all intents and purposes, &quo=
t;pseudo-const&quot; and &quot;const&quot; as it currently stand mean preci=
sely the same thing.</div><div><br></div><div>2. Telling the caller that th=
ere will be some temporary, invisible, un-observable state change during a =
call which is for him/her atomic, is simply leaking information that the ca=
ller has no way of using. It conveys no more useful information than &quot;=
const&quot;. There is therefore no use-case for it.</div><div><br></div><di=
v>In reality, the &quot;const&quot; keyword when applied to a method, alrea=
dy means &quot;pseudo-const&quot;. This is because we have mutable members.=
</div><div><br></div><div>There might be an argument for a new attribute (s=
ay, <span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-si=
ze:small;font-style:normal;font-weight:400;letter-spacing:normal;text-align=
:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px;background-color:rgb(255,255,255);float:none;display:inline">[[immutabl=
e]])</span>, which would indicate that the value is utterly immutable for t=
he life of the program, and that a method marked as such will always return=
 the same value (allowing the compiler to cache the results of calls).</div=
><div><br></div><div>Although we kind-of have that with constexpr already.<=
/div><div><br></div><div>Summary:</div><div><br></div><div>* The existing k=
eyword &quot;const&quot; really means &quot;psuedo-const&quot;.</div><div><=
br></div><div>* const objects in c++ are not *really* constants.</div><div>=
<br></div><div>* const methods are already allowed to modify internal state=
, but good manners dictates that these internal state changes are not obser=
vable to client code.</div><div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b79887f4-2be1-4e2c-9231-75b1b1e7c982%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b79887f4-2be1-4e2c-9231-75b1b1e7c982=
%40isocpp.org</a>.<br />

------=_Part_1613_670702054.1519909701017--

------=_Part_1612_904279504.1519909701016--

.

------=_Part_1559_1023565354.1519911871915
Content-Type: multipart/alternative;
 boundary="----=_Part_1560_2013661579.1519911871915"

------=_Part_1560_2013661579.1519911871915
Content-Type: text/plain; charset="UTF-8"

Thanks for your explanations

On Thursday, March 1, 2018 at 10:57:41 AM UTC+1, Richard Hodges wrote:
>
> Forgive me but I am still struggling to see the difference between const
> and pseudo-const.
>
> A long long time ago, when I used to write embedded C, "const" meant "it's
> in ROM. It won't change even if you write to it". (they were simple
> proprietary systems with no MMU and I wrote custom linker scripts and c
> runtime startup code).
>
> Then c++ came along and const meant "This method will not change the
> logical state of the object". Which it seems to me is precisely what you
> are intending to communicate with "pesudo-const". I understand that your
> intention is to communicate that there will be some temporary modification
> of state, but there are 2 problems with this:
>
> 1. Because the c++ memory model is single-threaded, the fact that there
> have been internal state changes during the call is irrelevant. Those state
> changes are not observable to the caller, so for all intents and purposes,
> "pseudo-const" and "const" as it currently stand mean precisely the same
> thing.
>
> 2. Telling the caller that there will be some temporary, invisible,
> un-observable state change during a call which is for him/her atomic, is
> simply leaking information that the caller has no way of using. It conveys
> no more useful information than "const". There is therefore no use-case for
> it.
>
> In reality, the "const" keyword when applied to a method, already means
> "pseudo-const". This is because we have mutable members.
>
> There might be an argument for a new attribute (say, [[immutable]]),
> which would indicate that the value is utterly immutable for the life of
> the program, and that a method marked as such will always return the same
> value (allowing the compiler to cache the results of calls).
>
> Although we kind-of have that with constexpr already.
>
> Summary:
>
> * The existing keyword "const" really means "psuedo-const".
>
> * const objects in c++ are not *really* constants.
>
> * const methods are already allowed to modify internal state, but good
> manners dictates that these internal state changes are not observable to
> client code.
>
>
>
> On 1 March 2018 at 07:15, <jsaintm...@gmail.com <javascript:>> wrote:
>
>> In this function, I am using insert instead of find, because it allows
>> hint. Insert is not const, but the element inserted is be erased
>>
>> On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas wrote:
>>>
>>> On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5,
>>> jsaintm...@gmail.com wrote:
>>>>
>>>> Another use of pseudoconst / reversible would allow to use hint to find
>>>> an element in map within a pseudo const method. As far as I know,
>>>> m.insert (ihint, p) exists,
>>>> but not map.find (ihint, p)
>>>>
>>>
>>> I fail to see how pseudoconst would be an essential element to such a
>>> function.
>>>
>>> With peudo const, you could write your pseudoconst find,  like this, if
>>>> you are certain -1 is not a second existing in the map, and map.erase (i)
>>>> was defined as the reverse of insert (i) :
>>>>
>>>
>>> But *why would you want to?* I don't see any performance improvement
>>> from this function. Because if you fail to find the item, then you have to
>>> go through the process of creating the element only to destroy it. Why
>>> would you do that? Creating elements requires allocating memory, which is
>>> pretty expensive.
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/878be2b7-f663-4f90-8f45-3c0e5a7e9150%40isocpp.org.

------=_Part_1560_2013661579.1519911871915
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for your explanations<br><br>On Thursday, March 1, =
2018 at 10:57:41 AM UTC+1, Richard Hodges wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr">Forgive me but I am still struggling to =
see the difference between const and pseudo-const.<div><br></div><div>A lon=
g long time ago, when I used to write embedded C, &quot;const&quot; meant &=
quot;it&#39;s in ROM. It won&#39;t change even if you write to it&quot;. (t=
hey were simple proprietary systems with no MMU and I wrote custom linker s=
cripts and c runtime startup code).</div><div><br></div><div>Then c++ came =
along and const meant &quot;This method will not change the logical state o=
f the object&quot;. Which it seems to me is precisely what you are intendin=
g to communicate with &quot;pesudo-const&quot;. I understand that your inte=
ntion is to communicate that there will be some temporary modification of s=
tate, but there are 2 problems with this:</div><div><br></div><div>1. Becau=
se the c++ memory model is single-threaded, the fact that there have been i=
nternal state changes during the call is irrelevant. Those state changes ar=
e not observable to the caller, so for all intents and purposes, &quot;pseu=
do-const&quot; and &quot;const&quot; as it currently stand mean precisely t=
he same thing.</div><div><br></div><div>2. Telling the caller that there wi=
ll be some temporary, invisible, un-observable state change during a call w=
hich is for him/her atomic, is simply leaking information that the caller h=
as no way of using. It conveys no more useful information than &quot;const&=
quot;. There is therefore no use-case for it.</div><div><br></div><div>In r=
eality, the &quot;const&quot; keyword when applied to a method, already mea=
ns &quot;pseudo-const&quot;. This is because we have mutable members.</div>=
<div><br></div><div>There might be an argument for a new attribute (say, <s=
pan style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sma=
ll;font-style:normal;font-weight:400;letter-spacing:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;ba=
ckground-color:rgb(255,255,255);float:none;display:inline">[[immutable]])</=
span>, which would indicate that the value is utterly immutable for the lif=
e of the program, and that a method marked as such will always return the s=
ame value (allowing the compiler to cache the results of calls).</div><div>=
<br></div><div>Although we kind-of have that with constexpr already.</div><=
div><br></div><div>Summary:</div><div><br></div><div>* The existing keyword=
 &quot;const&quot; really means &quot;psuedo-const&quot;.</div><div><br></d=
iv><div>* const objects in c++ are not *really* constants.</div><div><br></=
div><div>* const methods are already allowed to modify internal state, but =
good manners dictates that these internal state changes are not observable =
to client code.</div><div><br></div><div>=C2=A0</div></div><div><br><div cl=
ass=3D"gmail_quote">On 1 March 2018 at 07:15,  <span dir=3D"ltr">&lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"lTUz6AbYCgAJ" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jsaintm...@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">In this function, I am using insert instead of find, because it al=
lows hint. Insert is not const, but the element inserted is be erased<span>=
<br><br>On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday,=
 February 28, 2018 at 3:30:41 PM UTC-5, <a>jsaintm...@gmail.com</a> wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Another use of pseu=
doconst / reversible would allow to use hint to find an element in map with=
in a pseudo const method. As far as I know,<br>m.insert (ihint, p) exists, =
<br>but not map.find (ihint, p)<br></div></blockquote><div><br>I fail to se=
e how pseudoconst would be an essential element to such a function.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">With peudo c=
onst, you could write your pseudoconst find,=C2=A0 like this, if you are ce=
rtain -1 is not a second existing in the map, and map.erase (i) was defined=
 as the reverse of insert (i) :<br></div></blockquote><div><br>But <i>why w=
ould you want to?</i> I don&#39;t see any performance improvement from this=
 function. Because if you fail to find the item, then you have to go throug=
h the process of creating the element only to destroy it. Why would you do =
that? Creating elements requires allocating memory, which is pretty expensi=
ve.<br></div><br></div></blockquote></span></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
lTUz6AbYCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"lTUz6AbYCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/34d1dde0-b9fd-4565-<wbr>8ebe-=
a1b1936ab96d%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/878be2b7-f663-4f90-8f45-3c0e5a7e9150%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/878be2b7-f663-4f90-8f45-3c0e5a7e9150=
%40isocpp.org</a>.<br />

------=_Part_1560_2013661579.1519911871915--

------=_Part_1559_1023565354.1519911871915--

.

------=_Part_1616_1156676050.1519913795249
Content-Type: multipart/alternative;
 boundary="----=_Part_1617_1807485655.1519913795249"

------=_Part_1617_1807485655.1519913795249
Content-Type: text/plain; charset="UTF-8"

A "const" does not mean "pseudo const ". A more simple example :

class A {
public :
  A () : val_ (0) {}
  A (const A& a) : val_ (a.val_) {}
  ~A () {}
  //couple of reverse methods
  void inc () const {
    val_++;
  }
  void dec () const {
    val_--;
  }
  void write (std::ostream& os) const {
    os << val_;
  }
  void write_nextconst (std::ostream& os) const { //const method
    inc ();
    write (os);
  }
  void write_nextpseudoconst (std::ostream& os) const { //pseudo const
method
    inc ();
    write (os);
    dec ();
  }
  mutable size_t val_;
};

int main (int argc, char* argv []) {
  size_t duration (0);
  A v;

  std::cout << "\ttest write_nextconst" << std::endl;
  std::cout << "before : ";
  v.write (std::cout);
  std::cout << " next A :";
  v.write_nextconst (std::cout);
  std::cout << " after : ";
  v.write (std::cout);
  std::cout << std::endl;

  std::cout << "\ttest write_nextpseudoconst" << std::endl;
  A v2;
  std::cout << "before : ";
  v2.write (std::cout);
  std::cout << " next A : ";
  v2.write_nextpseudoconst (std::cout);
  std::cout << " after :";
  v2.write (std::cout);
  std::cout << std::endl;
  return 0;
}

results :
        test1
before : 0 next A :1 after : 1
        test2
before : 0 next A : 1 after :0

        test write_nextconst
before : 0 next A :1 after : 1
        test write_nextpseudoconst
before : 0 next A : 1 after :0

Results are different :
The const method changed the mutable object permanently.
The future pseudo const method write_next leaves the object unchanged, even
if it was changed during method. A oseudo const method shall call methods
M, const methods, and reverse methods M in reverse order

On Thursday, March 1, 2018 at 10:57:41 AM UTC+1, Richard Hodges wrote:
>
> Forgive me but I am still struggling to see the difference between const
> and pseudo-const.
>
> A long long time ago, when I used to write embedded C, "const" meant "it's
> in ROM. It won't change even if you write to it". (they were simple
> proprietary systems with no MMU and I wrote custom linker scripts and c
> runtime startup code).
>
> Then c++ came along and const meant "This method will not change the
> logical state of the object". Which it seems to me is precisely what you
> are intending to communicate with "pesudo-const". I understand that your
> intention is to communicate that there will be some temporary modification
> of state, but there are 2 problems with this:
>
> 1. Because the c++ memory model is single-threaded, the fact that there
> have been internal state changes during the call is irrelevant. Those state
> changes are not observable to the caller, so for all intents and purposes,
> "pseudo-const" and "const" as it currently stand mean precisely the same
> thing.
>
> 2. Telling the caller that there will be some temporary, invisible,
> un-observable state change during a call which is for him/her atomic, is
> simply leaking information that the caller has no way of using. It conveys
> no more useful information than "const". There is therefore no use-case for
> it.
>
> In reality, the "const" keyword when applied to a method, already means
> "pseudo-const". This is because we have mutable members.
>
> There might be an argument for a new attribute (say, [[immutable]]),
> which would indicate that the value is utterly immutable for the life of
> the program, and that a method marked as such will always return the same
> value (allowing the compiler to cache the results of calls).
>
> Although we kind-of have that with constexpr already.
>
> Summary:
>
> * The existing keyword "const" really means "psuedo-const".
>
> * const objects in c++ are not *really* constants.
>
> * const methods are already allowed to modify internal state, but good
> manners dictates that these internal state changes are not observable to
> client code.
>
>
>
> On 1 March 2018 at 07:15, <jsaintm...@gmail.com <javascript:>> wrote:
>
>> In this function, I am using insert instead of find, because it allows
>> hint. Insert is not const, but the element inserted is be erased
>>
>> On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas wrote:
>>>
>>> On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5,
>>> jsaintm...@gmail.com wrote:
>>>>
>>>> Another use of pseudoconst / reversible would allow to use hint to find
>>>> an element in map within a pseudo const method. As far as I know,
>>>> m.insert (ihint, p) exists,
>>>> but not map.find (ihint, p)
>>>>
>>>
>>> I fail to see how pseudoconst would be an essential element to such a
>>> function.
>>>
>>> With peudo const, you could write your pseudoconst find,  like this, if
>>>> you are certain -1 is not a second existing in the map, and map.erase (i)
>>>> was defined as the reverse of insert (i) :
>>>>
>>>
>>> But *why would you want to?* I don't see any performance improvement
>>> from this function. Because if you fail to find the item, then you have to
>>> go through the process of creating the element only to destroy it. Why
>>> would you do that? Creating elements requires allocating memory, which is
>>> pretty expensive.
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/99ee238e-3e02-4c5a-9b01-67e463a096d2%40isocpp.org.

------=_Part_1617_1807485655.1519913795249
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A &quot;const&quot; does not mean &quot;pseudo const &quot=
;. A more simple example :<br><br>class A {<br>public : <br>=C2=A0 A () : v=
al_ (0) {}<br>=C2=A0 A (const A&amp; a) : val_ (a.val_) {}<br>=C2=A0 ~A () =
{}<br>=C2=A0 //couple of reverse methods<br>=C2=A0 void inc () const {<br>=
=C2=A0=C2=A0=C2=A0 val_++;<br>=C2=A0 }<br>=C2=A0 void dec () const {<br>=C2=
=A0=C2=A0=C2=A0 val_--;<br>=C2=A0 }<br>=C2=A0 void write (std::ostream&amp;=
 os) const {<br>=C2=A0=C2=A0=C2=A0 os &lt;&lt; val_;<br>=C2=A0 }<br>=C2=A0 =
void write_nextconst (std::ostream&amp; os) const { //const method<br>=C2=
=A0=C2=A0=C2=A0 inc ();<br>=C2=A0=C2=A0=C2=A0 write (os);<br>=C2=A0 }<br>=
=C2=A0 void write_nextpseudoconst (std::ostream&amp; os) const { //pseudo c=
onst method<br>=C2=A0=C2=A0=C2=A0 inc ();<br>=C2=A0=C2=A0=C2=A0 write (os);=
<br>=C2=A0=C2=A0=C2=A0 dec ();<br>=C2=A0 }<br>=C2=A0 mutable size_t val_;<b=
r>};<br><br>int main (int argc, char* argv []) {<br>=C2=A0 size_t duration =
(0);<br>=C2=A0 A v;<br><br>=C2=A0 std::cout &lt;&lt; &quot;\ttest write_nex=
tconst&quot; &lt;&lt; std::endl;<br>=C2=A0 std::cout &lt;&lt; &quot;before =
: &quot;;<br>=C2=A0 v.write (std::cout);<br>=C2=A0 std::cout &lt;&lt; &quot=
; next A :&quot;;<br>=C2=A0 v.write_nextconst (std::cout);<br>=C2=A0 std::c=
out &lt;&lt; &quot; after : &quot;;<br>=C2=A0 v.write (std::cout);<br>=C2=
=A0 std::cout &lt;&lt; std::endl;<br><br>=C2=A0 std::cout &lt;&lt; &quot;\t=
test write_nextpseudoconst&quot; &lt;&lt; std::endl;<br>=C2=A0 A v2;<br>=C2=
=A0 std::cout &lt;&lt; &quot;before : &quot;;<br>=C2=A0 v2.write (std::cout=
);<br>=C2=A0 std::cout &lt;&lt; &quot; next A : &quot;;<br>=C2=A0 v2.write_=
nextpseudoconst (std::cout);<br>=C2=A0 std::cout &lt;&lt; &quot; after :&qu=
ot;;<br>=C2=A0 v2.write (std::cout);<br>=C2=A0 std::cout &lt;&lt; std::endl=
;<br>=C2=A0 return 0;<br>}<br><br>results :<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 test1<br>before : 0 next A :1 after : 1<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 test2<br>before : 0 next A : 1 after :0<br><br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test write_nextconst<br>before :=
 0 next A :1 after : 1<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test w=
rite_nextpseudoconst<br>before : 0 next A : 1 after :0<br><br>Results are d=
ifferent :<br>The const method changed the mutable object permanently.<br>T=
he future pseudo const method write_next leaves the object unchanged, even =
if it was changed during method. A oseudo const method shall call methods M=
, const methods, and reverse methods M in reverse order<br><br>On Thursday,=
 March 1, 2018 at 10:57:41 AM UTC+1, Richard Hodges wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">Forgive me but I am still stru=
ggling to see the difference between const and pseudo-const.<div><br></div>=
<div>A long long time ago, when I used to write embedded C, &quot;const&quo=
t; meant &quot;it&#39;s in ROM. It won&#39;t change even if you write to it=
&quot;. (they were simple proprietary systems with no MMU and I wrote custo=
m linker scripts and c runtime startup code).</div><div><br></div><div>Then=
 c++ came along and const meant &quot;This method will not change the logic=
al state of the object&quot;. Which it seems to me is precisely what you ar=
e intending to communicate with &quot;pesudo-const&quot;. I understand that=
 your intention is to communicate that there will be some temporary modific=
ation of state, but there are 2 problems with this:</div><div><br></div><di=
v>1. Because the c++ memory model is single-threaded, the fact that there h=
ave been internal state changes during the call is irrelevant. Those state =
changes are not observable to the caller, so for all intents and purposes, =
&quot;pseudo-const&quot; and &quot;const&quot; as it currently stand mean p=
recisely the same thing.</div><div><br></div><div>2. Telling the caller tha=
t there will be some temporary, invisible, un-observable state change durin=
g a call which is for him/her atomic, is simply leaking information that th=
e caller has no way of using. It conveys no more useful information than &q=
uot;const&quot;. There is therefore no use-case for it.</div><div><br></div=
><div>In reality, the &quot;const&quot; keyword when applied to a method, a=
lready means &quot;pseudo-const&quot;. This is because we have mutable memb=
ers.</div><div><br></div><div>There might be an argument for a new attribut=
e (say, <span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;fon=
t-size:small;font-style:normal;font-weight:400;letter-spacing:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px;background-color:rgb(255,255,255);float:none;display:inline">[[immu=
table]])</span>, which would indicate that the value is utterly immutable f=
or the life of the program, and that a method marked as such will always re=
turn the same value (allowing the compiler to cache the results of calls).<=
/div><div><br></div><div>Although we kind-of have that with constexpr alrea=
dy.</div><div><br></div><div>Summary:</div><div><br></div><div>* The existi=
ng keyword &quot;const&quot; really means &quot;psuedo-const&quot;.</div><d=
iv><br></div><div>* const objects in c++ are not *really* constants.</div><=
div><br></div><div>* const methods are already allowed to modify internal s=
tate, but good manners dictates that these internal state changes are not o=
bservable to client code.</div><div><br></div><div>=C2=A0</div></div><div><=
br><div class=3D"gmail_quote">On 1 March 2018 at 07:15,  <span dir=3D"ltr">=
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"lTUz=
6AbYCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;=
;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">j=
saintm...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">In this function, I am using insert instead of find, beca=
use it allows hint. Insert is not const, but the element inserted is be era=
sed<span><br><br>On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nico=
l Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On W=
ednesday, February 28, 2018 at 3:30:41 PM UTC-5, <a>jsaintm...@gmail.com</a=
> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Another us=
e of pseudoconst / reversible would allow to use hint to find an element in=
 map within a pseudo const method. As far as I know,<br>m.insert (ihint, p)=
 exists, <br>but not map.find (ihint, p)<br></div></blockquote><div><br>I f=
ail to see how pseudoconst would be an essential element to such a function=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Wit=
h peudo const, you could write your pseudoconst find,=C2=A0 like this, if y=
ou are certain -1 is not a second existing in the map, and map.erase (i) wa=
s defined as the reverse of insert (i) :<br></div></blockquote><div><br>But=
 <i>why would you want to?</i> I don&#39;t see any performance improvement =
from this function. Because if you fail to find the item, then you have to =
go through the process of creating the element only to destroy it. Why woul=
d you do that? Creating elements requires allocating memory, which is prett=
y expensive.<br></div><br></div></blockquote></span></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
lTUz6AbYCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"lTUz6AbYCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/34d1dde0-b9fd-4565-<wbr>8ebe-=
a1b1936ab96d%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/99ee238e-3e02-4c5a-9b01-67e463a096d2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/99ee238e-3e02-4c5a-9b01-67e463a096d2=
%40isocpp.org</a>.<br />

------=_Part_1617_1807485655.1519913795249--

------=_Part_1616_1156676050.1519913795249--

.

------=_Part_1789_555148650.1519915162406
Content-Type: multipart/alternative;
 boundary="----=_Part_1790_1456457396.1519915162407"

------=_Part_1790_1456457396.1519915162407
Content-Type: text/plain; charset="UTF-8"


"const " and "pseudo const" methods are differents. A more simple example :
class A {
public :
  A () : val_ (0) {}
  A (const A& a) : val_ (a.val_) {}
  ~A () {}
  //couple of const opposite methods
  void inc () const {
    val_++;
  }
  void dec () const {
    val_--;
  }
  void write (std::ostream& os) const {
    os << val_;
  }
  void write_nextconst (std::ostream& os) const { //const method
    inc ();
    write (os);
  }
  void write_nextpseudoconst (std::ostream& os) const { //pseudo const
method
    inc ();
    write (os);
    dec ();
  }
  mutable size_t val_;
};

int main (int argc, char* argv []) {
  size_t duration (0);
  A v;

  std::cout << "\ttest write_nextconst" << std::endl;
  std::cout << "A.val_ before : ";
  v.write (std::cout);
  std::cout << ", next val_ :";
  v.write_nextconst (std::cout);
  std::cout << ", A.val_ after : ";
  v.write (std::cout);
  std::cout << std::endl;

  std::cout << "\ttest write_nextpseudoconst" << std::endl;
  A v2;
  std::cout << "A.val_ before : ";
  v2.write (std::cout);
  std::cout << ", pseudo const nextval_ : ";
  v2.write_nextpseudoconst (std::cout);
  std::cout << ", after :";
  v2.write (std::cout);
  std::cout << std::endl;
  return 0;
}

results :
        test write_nextconst
A.val_ before : 0, next val_ :1, A.val_ after : 1
        test write_nextpseudoconst
A.val_ before : 0, pseudo const nextval_ : 1, after :0

method write_nextconst changed the mutable member val_  permenently.
pseudo const write_next_pseudoconst gives the same result, but the object
at the end is the same as the object at the beginning, because the
pseudoconst method called in this order methods M, const methods, reverse
methods M in reverse order.

On Thursday, March 1, 2018 at 10:57:41 AM UTC+1, Richard Hodges wrote:
>
> Forgive me but I am still struggling to see the difference between const
> and pseudo-const.
>
> A long long time ago, when I used to write embedded C, "const" meant "it's
> in ROM. It won't change even if you write to it". (they were simple
> proprietary systems with no MMU and I wrote custom linker scripts and c
> runtime startup code).
>
> Then c++ came along and const meant "This method will not change the
> logical state of the object". Which it seems to me is precisely what you
> are intending to communicate with "pesudo-const". I understand that your
> intention is to communicate that there will be some temporary modification
> of state, but there are 2 problems with this:
>
> 1. Because the c++ memory model is single-threaded, the fact that there
> have been internal state changes during the call is irrelevant. Those state
> changes are not observable to the caller, so for all intents and purposes,
> "pseudo-const" and "const" as it currently stand mean precisely the same
> thing.
>
> 2. Telling the caller that there will be some temporary, invisible,
> un-observable state change during a call which is for him/her atomic, is
> simply leaking information that the caller has no way of using. It conveys
> no more useful information than "const". There is therefore no use-case for
> it.
>
> In reality, the "const" keyword when applied to a method, already means
> "pseudo-const". This is because we have mutable members.
>
> There might be an argument for a new attribute (say, [[immutable]]),
> which would indicate that the value is utterly immutable for the life of
> the program, and that a method marked as such will always return the same
> value (allowing the compiler to cache the results of calls).
>
> Although we kind-of have that with constexpr already.
>
> Summary:
>
> * The existing keyword "const" really means "psuedo-const".
>
> * const objects in c++ are not *really* constants.
>
> * const methods are already allowed to modify internal state, but good
> manners dictates that these internal state changes are not observable to
> client code.
>
>
>
> On 1 March 2018 at 07:15, <jsaintm...@gmail.com <javascript:>> wrote:
>
>> In this function, I am using insert instead of find, because it allows
>> hint. Insert is not const, but the element inserted is be erased
>>
>> On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas wrote:
>>>
>>> On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5,
>>> jsaintm...@gmail.com wrote:
>>>>
>>>> Another use of pseudoconst / reversible would allow to use hint to find
>>>> an element in map within a pseudo const method. As far as I know,
>>>> m.insert (ihint, p) exists,
>>>> but not map.find (ihint, p)
>>>>
>>>
>>> I fail to see how pseudoconst would be an essential element to such a
>>> function.
>>>
>>> With peudo const, you could write your pseudoconst find,  like this, if
>>>> you are certain -1 is not a second existing in the map, and map.erase (i)
>>>> was defined as the reverse of insert (i) :
>>>>
>>>
>>> But *why would you want to?* I don't see any performance improvement
>>> from this function. Because if you fail to find the item, then you have to
>>> go through the process of creating the element only to destroy it. Why
>>> would you do that? Creating elements requires allocating memory, which is
>>> pretty expensive.
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5cc5798b-da0c-4192-ae58-ab7f7a35f275%40isocpp.org.

------=_Part_1790_1456457396.1519915162407
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>&quot;const &quot; and &quot;pseudo const&quot; method=
s are differents. A more simple example :<br>class A {<br>public : <br>=C2=
=A0 A () : val_ (0) {}<br>=C2=A0 A (const A&amp; a) : val_ (a.val_) {}<br>=
=C2=A0 ~A () {}<br>=C2=A0 //couple of const opposite methods<br>=C2=A0 void=
 inc () const {<br>=C2=A0=C2=A0=C2=A0 val_++;<br>=C2=A0 }<br>=C2=A0 void de=
c () const {<br>=C2=A0=C2=A0=C2=A0 val_--;<br>=C2=A0 }<br>=C2=A0 void write=
 (std::ostream&amp; os) const {<br>=C2=A0=C2=A0=C2=A0 os &lt;&lt; val_;<br>=
=C2=A0 }<br>=C2=A0 void write_nextconst (std::ostream&amp; os) const { //co=
nst method<br>=C2=A0=C2=A0=C2=A0 inc ();<br>=C2=A0=C2=A0=C2=A0 write (os);<=
br>=C2=A0 }<br>=C2=A0 void write_nextpseudoconst (std::ostream&amp; os) con=
st { //pseudo const method<br>=C2=A0=C2=A0=C2=A0 inc ();<br>=C2=A0=C2=A0=C2=
=A0 write (os);<br>=C2=A0=C2=A0=C2=A0 dec ();<br>=C2=A0 }<br>=C2=A0 mutable=
 size_t val_;<br>};<br><br>int main (int argc, char* argv []) {<br>=C2=A0 s=
ize_t duration (0);<br>=C2=A0 A v;<br><br>=C2=A0 std::cout &lt;&lt; &quot;\=
ttest write_nextconst&quot; &lt;&lt; std::endl;<br>=C2=A0 std::cout &lt;&lt=
; &quot;A.val_ before : &quot;;<br>=C2=A0 v.write (std::cout);<br>=C2=A0 st=
d::cout &lt;&lt; &quot;, next val_ :&quot;;<br>=C2=A0 v.write_nextconst (st=
d::cout);<br>=C2=A0 std::cout &lt;&lt; &quot;, A.val_ after : &quot;;<br>=
=C2=A0 v.write (std::cout);<br>=C2=A0 std::cout &lt;&lt; std::endl;<br><br>=
=C2=A0 std::cout &lt;&lt; &quot;\ttest write_nextpseudoconst&quot; &lt;&lt;=
 std::endl;<br>=C2=A0 A v2;<br>=C2=A0 std::cout &lt;&lt; &quot;A.val_ befor=
e : &quot;;<br>=C2=A0 v2.write (std::cout);<br>=C2=A0 std::cout &lt;&lt; &q=
uot;, pseudo const nextval_ : &quot;;<br>=C2=A0 v2.write_nextpseudoconst (s=
td::cout);<br>=C2=A0 std::cout &lt;&lt; &quot;, after :&quot;;<br>=C2=A0 v2=
..write (std::cout);<br>=C2=A0 std::cout &lt;&lt; std::endl;<br>=C2=A0 retur=
n 0;<br>}<br><br>results :<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 te=
st write_nextconst<br>A.val_ before : 0, next val_ :1, A.val_ after : 1<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test write_nextpseudoconst<br>A.=
val_ before : 0, pseudo const nextval_ : 1, after :0<br><br>method write_ne=
xtconst changed the mutable member val_=C2=A0 permenently.<br>pseudo const =
write_next_pseudoconst gives the same result, but the object at the end is =
the same as the object at the beginning, because the pseudoconst method cal=
led in this order methods M, const methods, reverse methods M in reverse or=
der. <br><br>On Thursday, March 1, 2018 at 10:57:41 AM UTC+1, Richard Hodge=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Forgi=
ve me but I am still struggling to see the difference between const and pse=
udo-const.<div><br></div><div>A long long time ago, when I used to write em=
bedded C, &quot;const&quot; meant &quot;it&#39;s in ROM. It won&#39;t chang=
e even if you write to it&quot;. (they were simple proprietary systems with=
 no MMU and I wrote custom linker scripts and c runtime startup code).</div=
><div><br></div><div>Then c++ came along and const meant &quot;This method =
will not change the logical state of the object&quot;. Which it seems to me=
 is precisely what you are intending to communicate with &quot;pesudo-const=
&quot;. I understand that your intention is to communicate that there will =
be some temporary modification of state, but there are 2 problems with this=
:</div><div><br></div><div>1. Because the c++ memory model is single-thread=
ed, the fact that there have been internal state changes during the call is=
 irrelevant. Those state changes are not observable to the caller, so for a=
ll intents and purposes, &quot;pseudo-const&quot; and &quot;const&quot; as =
it currently stand mean precisely the same thing.</div><div><br></div><div>=
2. Telling the caller that there will be some temporary, invisible, un-obse=
rvable state change during a call which is for him/her atomic, is simply le=
aking information that the caller has no way of using. It conveys no more u=
seful information than &quot;const&quot;. There is therefore no use-case fo=
r it.</div><div><br></div><div>In reality, the &quot;const&quot; keyword wh=
en applied to a method, already means &quot;pseudo-const&quot;. This is bec=
ause we have mutable members.</div><div><br></div><div>There might be an ar=
gument for a new attribute (say, <span style=3D"color:rgb(34,34,34);font-fa=
mily:arial,sans-serif;font-size:small;font-style:normal;font-weight:400;let=
ter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:no=
ne;display:inline">[[immutable]])</span>, which would indicate that the val=
ue is utterly immutable for the life of the program, and that a method mark=
ed as such will always return the same value (allowing the compiler to cach=
e the results of calls).</div><div><br></div><div>Although we kind-of have =
that with constexpr already.</div><div><br></div><div>Summary:</div><div><b=
r></div><div>* The existing keyword &quot;const&quot; really means &quot;ps=
uedo-const&quot;.</div><div><br></div><div>* const objects in c++ are not *=
really* constants.</div><div><br></div><div>* const methods are already all=
owed to modify internal state, but good manners dictates that these interna=
l state changes are not observable to client code.</div><div><br></div><div=
>=C2=A0</div></div><div><br><div class=3D"gmail_quote">On 1 March 2018 at 0=
7:15,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"lTUz6AbYCgAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">jsaintm...@gmail.com</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">In this function, I am using ins=
ert instead of find, because it allows hint. Insert is not const, but the e=
lement inserted is be erased<span><br><br>On Wednesday, February 28, 2018 a=
t 10:38:04 PM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5, <=
a>jsaintm...@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"><d=
iv dir=3D"ltr">Another use of pseudoconst / reversible would allow to use h=
int to find an element in map within a pseudo const method. As far as I kno=
w,<br>m.insert (ihint, p) exists, <br>but not map.find (ihint, p)<br></div>=
</blockquote><div><br>I fail to see how pseudoconst would be an essential e=
lement to such a function.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">With peudo const, you could write your pseudoconst fi=
nd,=C2=A0 like this, if you are certain -1 is not a second existing in the =
map, and map.erase (i) was defined as the reverse of insert (i) :<br></div>=
</blockquote><div><br>But <i>why would you want to?</i> I don&#39;t see any=
 performance improvement from this function. Because if you fail to find th=
e item, then you have to go through the process of creating the element onl=
y to destroy it. Why would you do that? Creating elements requires allocati=
ng memory, which is pretty expensive.<br></div><br></div></blockquote></spa=
n></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
lTUz6AbYCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"lTUz6AbYCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/34d1dde0-b9fd-4565-<wbr>8ebe-=
a1b1936ab96d%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5cc5798b-da0c-4192-ae58-ab7f7a35f275%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5cc5798b-da0c-4192-ae58-ab7f7a35f275=
%40isocpp.org</a>.<br />

------=_Part_1790_1456457396.1519915162407--

------=_Part_1789_555148650.1519915162406--

.

--001a11441afa3e46a905665ad9a6
Content-Type: text/plain; charset="UTF-8"

On 1 March 2018 at 14:16, <jsaintmartin356@gmail.com> wrote:

> A "const" does not mean "pseudo const ". A more simple example :
>
> class A {
> public :
>   A () : val_ (0) {}
>   A (const A& a) : val_ (a.val_) {}
>   ~A () {}
>   //couple of reverse methods
>   void inc () const {
>     val_++;
>   }
>   void dec () const {
>     val_--;
>   }
>   void write (std::ostream& os) const {
>     os << val_;
>   }
>



>   void write_nextconst (std::ostream& os) const { //const method
>     inc ();
>     write (os);
>   }
>

I understand what you are illustrating. The problem here is that the method
"write_nextconst()" is lying. It is advertised as const ("I guarantee that
I will not mutate the logical state of the object") but has, in fact, left
the logical observable state mutated. This is *certainly an anti-pattern*
and very likely to be a *logic error*.

I would agree that some compiler help in identifying this error would be
welcome, e.g.:

"warning: main.cpp:122 : const method modifies the observable state of the
object."

Quite how a compiler maintainer would implement that without giving false
positives, I cannot answer at the present time.

We have some protection, in that val_ must be marked "mutable", which at
least gives a maintainer a warning to be wary when modifying const methods
of the class.

A reliable way to implement a software transaction/reversible process is
through the constructor/destructor of a transaction object. Boost.ScopeExit
is one attempt at simplifying such a tool.

The bugbear in this kind of code is exception handling, so for code to be
truly reversible it must be exception-free and/or use objects that give the
strong guarantee.

In summary, the tools already exist. They (at least in my experience) are
used so infrequently as to beg the question, "why bake them into the
language?". If you can offer examples of common code that would benefit
from being refactored to use such reversible mutations, you'll start to
build a less sceptical audience.

R



>   void write_nextpseudoconst (std::ostream& os) const { //pseudo const
> method
>     inc ();
>     write (os);
>     dec ();
>   }
>   mutable size_t val_;
> };
>
> int main (int argc, char* argv []) {
>   size_t duration (0);
>   A v;
>
>   std::cout << "\ttest write_nextconst" << std::endl;
>   std::cout << "before : ";
>   v.write (std::cout);
>   std::cout << " next A :";
>   v.write_nextconst (std::cout);
>   std::cout << " after : ";
>   v.write (std::cout);
>   std::cout << std::endl;
>
>   std::cout << "\ttest write_nextpseudoconst" << std::endl;
>   A v2;
>   std::cout << "before : ";
>   v2.write (std::cout);
>   std::cout << " next A : ";
>   v2.write_nextpseudoconst (std::cout);
>   std::cout << " after :";
>   v2.write (std::cout);
>   std::cout << std::endl;
>   return 0;
> }
>
> results :
>         test1
> before : 0 next A :1 after : 1
>         test2
> before : 0 next A : 1 after :0
>
>         test write_nextconst
> before : 0 next A :1 after : 1
>         test write_nextpseudoconst
> before : 0 next A : 1 after :0
>
> Results are different :
> The const method changed the mutable object permanently.
> The future pseudo const method write_next leaves the object unchanged,
> even if it was changed during method. A oseudo const method shall call
> methods M, const methods, and reverse methods M in reverse order
>
> On Thursday, March 1, 2018 at 10:57:41 AM UTC+1, Richard Hodges wrote:
>>
>> Forgive me but I am still struggling to see the difference between const
>> and pseudo-const.
>>
>> A long long time ago, when I used to write embedded C, "const" meant
>> "it's in ROM. It won't change even if you write to it". (they were simple
>> proprietary systems with no MMU and I wrote custom linker scripts and c
>> runtime startup code).
>>
>> Then c++ came along and const meant "This method will not change the
>> logical state of the object". Which it seems to me is precisely what you
>> are intending to communicate with "pesudo-const". I understand that your
>> intention is to communicate that there will be some temporary modification
>> of state, but there are 2 problems with this:
>>
>> 1. Because the c++ memory model is single-threaded, the fact that there
>> have been internal state changes during the call is irrelevant. Those state
>> changes are not observable to the caller, so for all intents and purposes,
>> "pseudo-const" and "const" as it currently stand mean precisely the same
>> thing.
>>
>> 2. Telling the caller that there will be some temporary, invisible,
>> un-observable state change during a call which is for him/her atomic, is
>> simply leaking information that the caller has no way of using. It conveys
>> no more useful information than "const". There is therefore no use-case for
>> it.
>>
>> In reality, the "const" keyword when applied to a method, already means
>> "pseudo-const". This is because we have mutable members.
>>
>> There might be an argument for a new attribute (say, [[immutable]]),
>> which would indicate that the value is utterly immutable for the life of
>> the program, and that a method marked as such will always return the same
>> value (allowing the compiler to cache the results of calls).
>>
>> Although we kind-of have that with constexpr already.
>>
>> Summary:
>>
>> * The existing keyword "const" really means "psuedo-const".
>>
>> * const objects in c++ are not *really* constants.
>>
>> * const methods are already allowed to modify internal state, but good
>> manners dictates that these internal state changes are not observable to
>> client code.
>>
>>
>>
>> On 1 March 2018 at 07:15, <jsaintm...@gmail.com> wrote:
>>
>>> In this function, I am using insert instead of find, because it allows
>>> hint. Insert is not const, but the element inserted is be erased
>>>
>>> On Wednesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas wrote:
>>>>
>>>> On Wednesday, February 28, 2018 at 3:30:41 PM UTC-5,
>>>> jsaintm...@gmail.com wrote:
>>>>>
>>>>> Another use of pseudoconst / reversible would allow to use hint to
>>>>> find an element in map within a pseudo const method. As far as I know,
>>>>> m.insert (ihint, p) exists,
>>>>> but not map.find (ihint, p)
>>>>>
>>>>
>>>> I fail to see how pseudoconst would be an essential element to such a
>>>> function.
>>>>
>>>> With peudo const, you could write your pseudoconst find,  like this, if
>>>>> you are certain -1 is not a second existing in the map, and map.erase (i)
>>>>> was defined as the reverse of insert (i) :
>>>>>
>>>>
>>>> But *why would you want to?* I don't see any performance improvement
>>>> from this function. Because if you fail to find the item, then you have to
>>>> go through the process of creating the element only to destroy it. Why
>>>> would you do that? Creating elements requires allocating memory, which is
>>>> pretty expensive.
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-
>>> a1b1936ab96d%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/99ee238e-3e02-4c5a-
> 9b01-67e463a096d2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/99ee238e-3e02-4c5a-9b01-67e463a096d2%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYQ-GiQAPMRcxnY6m_prsZbZMd7FZ04OBev-cy6Hx2a3Q%40mail.gmail.com.

--001a11441afa3e46a905665ad9a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 1 March 2018 at 14:16,  <span dir=3D"ltr">&lt;<a href=3D"mailto:jsai=
ntmartin356@gmail.com" target=3D"_blank">jsaintmartin356@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">A &quot;co=
nst&quot; does not mean &quot;pseudo const &quot;. A more simple example :<=
br><br>class A {<br>public : <br>=C2=A0 A () : val_ (0) {}<br>=C2=A0 A (con=
st A&amp; a) : val_ (a.val_) {}<br>=C2=A0 ~A () {}<br>=C2=A0 //couple of re=
verse methods<br>=C2=A0 void inc () const {<br>=C2=A0=C2=A0=C2=A0 val_++;<b=
r>=C2=A0 }<br>=C2=A0 void dec () const {<br>=C2=A0=C2=A0=C2=A0 val_--;<br>=
=C2=A0 }<br>=C2=A0 void write (std::ostream&amp; os) const {<br>=C2=A0=C2=
=A0=C2=A0 os &lt;&lt; val_;<br>=C2=A0 }<br></div></blockquote><div><br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=C2=A0 v=
oid write_nextconst (std::ostream&amp; os) const { //const method<br>=C2=A0=
=C2=A0=C2=A0 inc ();<br>=C2=A0=C2=A0=C2=A0 write (os);<br>=C2=A0 }<br></div=
></blockquote><div><br></div><div>I understand what you are illustrating. T=
he problem here is that the method &quot;write_nextconst()&quot; is lying. =
It is advertised as const (&quot;I guarantee that I will not mutate the log=
ical state of the object&quot;) but has, in fact, left the logical observab=
le state mutated. This is <i>certainly an anti-pattern</i> and very likely =
to be a <i>logic error</i>.</div><div><br></div><div>I would agree that som=
e compiler help in identifying this error would be welcome, e.g.:</div><div=
><br></div><div>&quot;warning: main.cpp:122 : const method modifies the obs=
ervable state of the object.&quot;</div><div><br></div><div>Quite how a com=
piler maintainer would implement that without giving false positives, I can=
not answer at the present time.=C2=A0</div><div><br></div><div>We have some=
 protection, in that val_ must be marked &quot;mutable&quot;, which at leas=
t gives a maintainer a warning to be wary when modifying const methods of t=
he class.</div><div><br></div><div>A reliable way to implement a software t=
ransaction/reversible process is through the constructor/destructor of a tr=
ansaction object. Boost.ScopeExit is one attempt at simplifying such a tool=
..</div><div><br></div><div>The bugbear in this kind of code is exception ha=
ndling, so for code to be truly reversible it must be exception-free and/or=
 use objects that give the strong guarantee.</div><div><br></div><div>In su=
mmary, the tools already exist. They (at least in my experience) are used s=
o infrequently as to beg the question, &quot;why bake them into the languag=
e?&quot;. If you can offer examples of common code that would benefit from =
being refactored to use such reversible mutations, you&#39;ll start to buil=
d a less sceptical audience.</div><div><br></div><div>R</div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=C2=A0 vo=
id write_nextpseudoconst (std::ostream&amp; os) const { //pseudo const meth=
od<br>=C2=A0=C2=A0=C2=A0 inc ();<br>=C2=A0=C2=A0=C2=A0 write (os);<br>=C2=
=A0=C2=A0=C2=A0 dec ();<br>=C2=A0 }<br>=C2=A0 mutable size_t val_;<span cla=
ss=3D""><br>};<br><br>int main (int argc, char* argv []) {<br></span>=C2=A0=
 size_t duration (0);<br>=C2=A0 A v;<br><br>=C2=A0 std::cout &lt;&lt; &quot=
;\ttest write_nextconst&quot; &lt;&lt; std::endl;<br>=C2=A0 std::cout &lt;&=
lt; &quot;before : &quot;;<br>=C2=A0 v.write (std::cout);<br>=C2=A0 std::co=
ut &lt;&lt; &quot; next A :&quot;;<br>=C2=A0 v.write_nextconst (std::cout);=
<br>=C2=A0 std::cout &lt;&lt; &quot; after : &quot;;<br>=C2=A0 v.write (std=
::cout);<br>=C2=A0 std::cout &lt;&lt; std::endl;<br><br>=C2=A0 std::cout &l=
t;&lt; &quot;\ttest write_nextpseudoconst&quot; &lt;&lt; std::endl;<br>=C2=
=A0 A v2;<br>=C2=A0 std::cout &lt;&lt; &quot;before : &quot;;<br>=C2=A0 v2.=
write (std::cout);<br>=C2=A0 std::cout &lt;&lt; &quot; next A : &quot;;<br>=
=C2=A0 v2.write_nextpseudoconst (std::cout);<br>=C2=A0 std::cout &lt;&lt; &=
quot; after :&quot;;<br>=C2=A0 v2.write (std::cout);<br>=C2=A0 std::cout &l=
t;&lt; std::endl;<br>=C2=A0 return 0;<br>}<br><br>results :<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test1<br>before : 0 next A :1 after : 1<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test2<br>before : 0 next A : 1 a=
fter :0<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test write_nextco=
nst<br>before : 0 next A :1 after : 1<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 test write_nextpseudoconst<br>before : 0 next A : 1 after :0<br><=
br>Results are different :<br>The const method changed the mutable object p=
ermanently.<br>The future pseudo const method write_next leaves the object =
unchanged, even if it was changed during method. A oseudo const method shal=
l call methods M, const methods, and reverse methods M in reverse order<spa=
n class=3D""><br><br>On Thursday, March 1, 2018 at 10:57:41 AM UTC+1, Richa=
rd Hodges wrote:</span><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D""><div dir=3D"ltr">Forgive me but I am still struggling to see the diff=
erence between const and pseudo-const.<div><br></div><div>A long long time =
ago, when I used to write embedded C, &quot;const&quot; meant &quot;it&#39;=
s in ROM. It won&#39;t change even if you write to it&quot;. (they were sim=
ple proprietary systems with no MMU and I wrote custom linker scripts and c=
 runtime startup code).</div><div><br></div><div>Then c++ came along and co=
nst meant &quot;This method will not change the logical state of the object=
&quot;. Which it seems to me is precisely what you are intending to communi=
cate with &quot;pesudo-const&quot;. I understand that your intention is to =
communicate that there will be some temporary modification of state, but th=
ere are 2 problems with this:</div><div><br></div><div>1. Because the c++ m=
emory model is single-threaded, the fact that there have been internal stat=
e changes during the call is irrelevant. Those state changes are not observ=
able to the caller, so for all intents and purposes, &quot;pseudo-const&quo=
t; and &quot;const&quot; as it currently stand mean precisely the same thin=
g.</div><div><br></div><div>2. Telling the caller that there will be some t=
emporary, invisible, un-observable state change during a call which is for =
him/her atomic, is simply leaking information that the caller has no way of=
 using. It conveys no more useful information than &quot;const&quot;. There=
 is therefore no use-case for it.</div><div><br></div><div>In reality, the =
&quot;const&quot; keyword when applied to a method, already means &quot;pse=
udo-const&quot;. This is because we have mutable members.</div><div><br></d=
iv><div>There might be an argument for a new attribute (say, <span style=3D=
"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-styl=
e:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent=
:0px;text-transform:none;white-space:normal;word-spacing:0px;background-col=
or:rgb(255,255,255);float:none;display:inline">[[immutable]])</span>, which=
 would indicate that the value is utterly immutable for the life of the pro=
gram, and that a method marked as such will always return the same value (a=
llowing the compiler to cache the results of calls).</div><div><br></div><d=
iv>Although we kind-of have that with constexpr already.</div><div><br></di=
v><div>Summary:</div><div><br></div><div>* The existing keyword &quot;const=
&quot; really means &quot;psuedo-const&quot;.</div><div><br></div><div>* co=
nst objects in c++ are not *really* constants.</div><div><br></div><div>* c=
onst methods are already allowed to modify internal state, but good manners=
 dictates that these internal state changes are not observable to client co=
de.</div><div><br></div><div>=C2=A0</div></div></span><div><br><div class=
=3D"gmail_quote"><span class=3D"">On 1 March 2018 at 07:15,  <span dir=3D"l=
tr">&lt;<a rel=3D"nofollow">jsaintm...@gmail.com</a>&gt;</span> wrote:<br><=
/span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr">In t=
his function, I am using insert instead of find, because it allows hint. In=
sert is not const, but the element inserted is be erased<span><br><br>On We=
dnesday, February 28, 2018 at 10:38:04 PM UTC+1, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, February 28,=
 2018 at 3:30:41 PM UTC-5, <a>jsaintm...@gmail.com</a> wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">Another use of pseudoconst / rev=
ersible would allow to use hint to find an element in map within a pseudo c=
onst method. As far as I know,<br>m.insert (ihint, p) exists, <br>but not m=
ap.find (ihint, p)<br></div></blockquote><div><br>I fail to see how pseudoc=
onst would be an essential element to such a function.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">With peudo const, you cou=
ld write your pseudoconst find,=C2=A0 like this, if you are certain -1 is n=
ot a second existing in the map, and map.erase (i) was defined as the rever=
se of insert (i) :<br></div></blockquote><div><br>But <i>why would you want=
 to?</i> I don&#39;t see any performance improvement from this function. Be=
cause if you fail to find the item, then you have to go through the process=
 of creating the element only to destroy it. Why would you do that? Creatin=
g elements requires allocating memory, which is pretty expensive.<br></div>=
<br></div></blockquote></span></div></span><span><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34d1dde0-b9fd-4565-8ebe-a1b1936ab96d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/34d1dde0-b9fd-4565-8ebe-<wbr>a1b1936ab96d%40isocpp.org</a>.<br=
>
</span></blockquote></div><br></div>
</blockquote></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/99ee238e-3e02-4c5a-9b01-67e463a096d2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/99ee=
238e-3e02-4c5a-<wbr>9b01-67e463a096d2%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYQ-GiQAPMRcxnY6m_prsZbZMd7FZ04=
OBev-cy6Hx2a3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYQ-GiQAPMR=
cxnY6m_prsZbZMd7FZ04OBev-cy6Hx2a3Q%40mail.gmail.com</a>.<br />

--001a11441afa3e46a905665ad9a6--

.

------=_Part_1822_1660224876.1519916869140
Content-Type: multipart/alternative;
 boundary="----=_Part_1823_1356562895.1519916869141"

------=_Part_1823_1356562895.1519916869141
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 1, 2018 at 2:15:49 AM UTC-5, jsaintm...@gmail.com wrote:
>
> In this function, I am using insert instead of find, because it allows
> hint. Insert is not const, but the element inserted is be erased
>

Yes, I see that, but I don't understand *why you want that*. You haven't
improved the performance of this operation. So what's the point?

I've yet to see an example of this "pseudoconst" idea that shows why
someone would want to use it.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/beabc81c-aac8-4430-9641-4f1749ef69c5%40isocpp.org.

------=_Part_1823_1356562895.1519916869141
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 1, 2018 at 2:15:49 AM UTC-5, jsaintm...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">In this function, I am using insert instead of find, because it allows =
hint. Insert is not const, but the element inserted is be erased<br></div><=
/blockquote><div><br>Yes, I see that, but I don&#39;t understand <i>why you=
 want that</i>. You haven&#39;t improved the performance of this operation.=
 So what&#39;s the point?<br><br>I&#39;ve yet to see an example of this &qu=
ot;pseudoconst&quot; idea that shows why someone would want to use it.</div=
><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/beabc81c-aac8-4430-9641-4f1749ef69c5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/beabc81c-aac8-4430-9641-4f1749ef69c5=
%40isocpp.org</a>.<br />

------=_Part_1823_1356562895.1519916869141--

------=_Part_1822_1660224876.1519916869140--

.

------=_Part_2315_532722258.1519925706755
Content-Type: multipart/alternative;
 boundary="----=_Part_2316_1120157230.1519925706755"

------=_Part_2316_1120157230.1519925706755
Content-Type: text/plain; charset="UTF-8"

I want this because for I must choose between different methods, the one
giving the best result. I need to try all methods without changing the
object (with a guarantee of the compiler : const calls M, const or pseudo
const calls, reverse M calls), and then choose the method

On Thursday, March 1, 2018 at 4:07:49 PM UTC+1, Nicol Bolas wrote:
>
> On Thursday, March 1, 2018 at 2:15:49 AM UTC-5, jsaintm...@gmail.com
> wrote:
>>
>> In this function, I am using insert instead of find, because it allows
>> hint. Insert is not const, but the element inserted is be erased
>>
>
> Yes, I see that, but I don't understand *why you want that*. You haven't
> improved the performance of this operation. So what's the point?
>
> I've yet to see an example of this "pseudoconst" idea that shows why
> someone would want to use it.
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e08de6c3-e7c2-46a0-a788-24986d9c56b5%40isocpp.org.

------=_Part_2316_1120157230.1519925706755
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I want this because for I must choose between different me=
thods, the one giving the best result. I need to try all methods without ch=
anging the object (with a guarantee of the compiler : const calls M, const =
or pseudo const calls, reverse M calls), and then choose the method<br><br>=
On Thursday, March 1, 2018 at 4:07:49 PM UTC+1, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Thursday, March 1, =
2018 at 2:15:49 AM UTC-5, <a>jsaintm...@gmail.com</a> wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">In this function, I am using inse=
rt instead of find, because it allows hint. Insert is not const, but the el=
ement inserted is be erased<br></div></blockquote><div><br>Yes, I see that,=
 but I don&#39;t understand <i>why you want that</i>. You haven&#39;t impro=
ved the performance of this operation. So what&#39;s the point?<br><br>I&#3=
9;ve yet to see an example of this &quot;pseudoconst&quot; idea that shows =
why someone would want to use it.</div><br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e08de6c3-e7c2-46a0-a788-24986d9c56b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e08de6c3-e7c2-46a0-a788-24986d9c56b5=
%40isocpp.org</a>.<br />

------=_Part_2316_1120157230.1519925706755--

------=_Part_2315_532722258.1519925706755--

.

------=_Part_2441_1171982908.1519926758059
Content-Type: multipart/alternative;
 boundary="----=_Part_2442_1681474745.1519926758059"

------=_Part_2442_1681474745.1519926758059
Content-Type: text/plain; charset="UTF-8"

and then call the best method

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5262af56-c631-4c62-954c-1a2b90904319%40isocpp.org.

------=_Part_2442_1681474745.1519926758059
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">and then call the best method<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5262af56-c631-4c62-954c-1a2b90904319%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5262af56-c631-4c62-954c-1a2b90904319=
%40isocpp.org</a>.<br />

------=_Part_2442_1681474745.1519926758059--

------=_Part_2441_1171982908.1519926758059--

.

------=_Part_2424_1835898943.1519927712600
Content-Type: multipart/alternative;
 boundary="----=_Part_2425_354671784.1519927712600"

------=_Part_2425_354671784.1519927712600
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 1, 2018 at 12:35:06 PM UTC-5, jsaintm...@gmail.com wrote:
>
> I want this because for I must choose between different methods, the one
> giving the best result. I need to try all methods without changing the
> object (with a guarantee of the compiler : const calls M, const or pseudo
> const calls, reverse M calls), and then choose the method
>

You keep repeating this and giving examples, none of which actually explain
why this is *necessary*. The examples you provide only show that this is
what you want to do, not why it *needs* to be done this way.

We know what you want. I don't understand why you think this is a necessary
language feature. It seems to me that you can do it just fine as the
standard currently is.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2225c09b-b669-4057-b3e7-36c23803af41%40isocpp.org.

------=_Part_2425_354671784.1519927712600
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 1, 2018 at 12:35:06 PM UTC-5, jsaintm..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">I want this because for I must choose between different methods, the o=
ne giving the best result. I need to try all methods without changing the o=
bject (with a guarantee of the compiler : const calls M, const or pseudo co=
nst calls, reverse M calls), and then choose the method<br></div></blockquo=
te><div><br>You keep repeating this and giving examples, none of which actu=
ally explain why this is <i>necessary</i>. The examples you provide only sh=
ow that this is what you want to do, not why it <i>needs</i> to be done thi=
s way.<br><br>We know what you want. I don&#39;t understand why you think t=
his is a necessary language feature. It seems to me that you can do it just=
 fine as the standard currently is.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2225c09b-b669-4057-b3e7-36c23803af41%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2225c09b-b669-4057-b3e7-36c23803af41=
%40isocpp.org</a>.<br />

------=_Part_2425_354671784.1519927712600--

------=_Part_2424_1835898943.1519927712600--

.

------=_Part_343_1141773356.1519927906709
Content-Type: multipart/alternative;
 boundary="----=_Part_344_684525126.1519927906710"

------=_Part_344_684525126.1519927906710
Content-Type: text/plain; charset="UTF-8"

If you have several hundreds of possibilities to try, and the object is
huge, it's faster to try each, cancel it and try the next one, than to make
a copy of the whole object hundreds of times

On Thursday, March 1, 2018 at 6:52:38 PM UTC+1, jsaintm...@gmail.com wrote:
>
> and then call the best method
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2359cd87-fdca-4b4e-8fc3-9f69085acffd%40isocpp.org.

------=_Part_344_684525126.1519927906710
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">If you have several hundreds of possibilities to try, and =
the object is huge, it&#39;s faster to try each, cancel it and try the next=
 one, than to make a copy of the whole object hundreds of times<br><br>On T=
hursday, March 1, 2018 at 6:52:38 PM UTC+1, jsaintm...@gmail.com wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">and then call the=
 best method<br><br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2359cd87-fdca-4b4e-8fc3-9f69085acffd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2359cd87-fdca-4b4e-8fc3-9f69085acffd=
%40isocpp.org</a>.<br />

------=_Part_344_684525126.1519927906710--

------=_Part_343_1141773356.1519927906709--

.

------=_Part_2364_7011061.1519928686552
Content-Type: multipart/alternative;
 boundary="----=_Part_2365_101379216.1519928686553"

------=_Part_2365_101379216.1519928686553
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 1, 2018 at 1:11:46 PM UTC-5, jsaintm...@gmail.com wrote:
>
> If you have several hundreds of possibilities to try, and the object is
> huge, it's faster to try each, cancel it and try the next one, than to make
> a copy of the whole object hundreds of times
>

Then do that. Your method is non-const. There's nothing in the language
preventing you from doing this.

What you want is not nearly useful enough to be worthy of a language
feature, even if the feature could be guaranteed by the compiler in some
way.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b92bbef3-c319-4340-9dea-f72f697dd122%40isocpp.org.

------=_Part_2365_101379216.1519928686553
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 1, 2018 at 1:11:46 PM UTC-5, jsaintm...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">If you have several hundreds of possibilities to try, and the object is=
 huge, it&#39;s faster to try each, cancel it and try the next one, than to=
 make a copy of the whole object hundreds of times<br></div></blockquote><d=
iv><br>Then do that. Your method is non-const. There&#39;s nothing in the l=
anguage preventing you from doing this.<br><br>What you want is not nearly =
useful enough to be worthy of a language feature, even if the feature could=
 be guaranteed by the compiler in some way.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b92bbef3-c319-4340-9dea-f72f697dd122%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b92bbef3-c319-4340-9dea-f72f697dd122=
%40isocpp.org</a>.<br />

------=_Part_2365_101379216.1519928686553--

------=_Part_2364_7011061.1519928686552--

.

--94eb2c12ee82777fc705665dfef4
Content-Type: text/plain; charset="UTF-8"

I'm not sure if I understand - is there a scenario where you would provide
both a const and a pseudoconst method on a class?

If it's just a matter of implementation, you know you can const-cast the
this pointer into a non-const pointer so you can call mutable methods on
it? The interface method would then bear a const signature while the
implementation merely needs to ensure there can never be user-visible side
effects.

I fail to grasp a context where having a type-system-understood third layer
of constness that is never present in both flavors on a single object.

G

On Thu, Mar 1, 2018, 17:52 <jsaintmartin356@gmail.com> wrote:

> and then call the best method
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5262af56-c631-4c62-954c-1a2b90904319%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5262af56-c631-4c62-954c-1a2b90904319%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkU_VdB5otAFgcz545X%2BzamLox%2BhsP_k%3Dd5MxpOGDc3_Kw%40mail.gmail.com.

--94eb2c12ee82777fc705665dfef4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I&#39;m not sure if I understand - is there a scenario wh=
ere you would provide both a const and a pseudoconst method on a class?<div=
 dir=3D"auto"><br></div><div dir=3D"auto">If it&#39;s just a matter of impl=
ementation, you know you can const-cast the this pointer into a non-const p=
ointer so you can call mutable methods on it? The interface method would th=
en bear a const signature while the implementation merely needs to ensure t=
here can never be user-visible side effects.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">I fail to grasp a context where having a type-system-u=
nderstood third layer of constness that is never present in both flavors on=
 a single object.</div><div dir=3D"auto"><br></div><div dir=3D"auto">G</div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Mar 1, 2018,=
 17:52  &lt;<a href=3D"mailto:jsaintmartin356@gmail.com" target=3D"_blank" =
rel=3D"noreferrer">jsaintmartin356@gmail.com</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">and then call the best method<br>=
<br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" rel=3D"nore=
ferrer noreferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</=
a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-proposals@isocpp.=
org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5262af56-c631-4c62-954c-1a2b90904319%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/5262af56-c631-4c62-954c-1a2b90904319%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkU_VdB5otAFgcz545X%2BzamLox%2=
BhsP_k%3Dd5MxpOGDc3_Kw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3Dk=
U_VdB5otAFgcz545X%2BzamLox%2BhsP_k%3Dd5MxpOGDc3_Kw%40mail.gmail.com</a>.<br=
 />

--94eb2c12ee82777fc705665dfef4--

.

------=_Part_2425_322611762.1519928988773
Content-Type: multipart/alternative;
 boundary="----=_Part_2426_1681725931.1519928988773"

------=_Part_2426_1681725931.1519928988773
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Thursday, March 1, 2018 at 1:26:14 PM UTC-5, Ga=C5=A1per A=C5=BEman wrot=
e:
>
> I'm not sure if I understand - is there a scenario where you would provid=
e=20
> both a const and a pseudoconst method on a class?
>
> If it's just a matter of implementation, you know you can const-cast the=
=20
> this pointer into a non-const pointer so you can call mutable methods on =
it?
>

"Can" is a strong word. If the object itself was declared `const`, then you=
=20
"can" not. Or rather you "can", but any mutable calls will provoke UB.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ebc67007-559d-424d-aaeb-e92be7a615d7%40isocpp.or=
g.

------=_Part_2426_1681725931.1519928988773
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, March 1, 2018 at 1:26:14 PM UTC-5, Ga=
=C5=A1per A=C5=BEman wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"auto">I&#39;m not sure if I understand - is there a scenario where=
 you would provide both a const and a pseudoconst method on a class?<div di=
r=3D"auto"><br></div><div dir=3D"auto">If it&#39;s just a matter of impleme=
ntation, you know you can const-cast the this pointer into a non-const poin=
ter so you can call mutable methods on it?</div></div></blockquote><div><br=
>&quot;Can&quot; is a strong word. If the object itself was declared `const=
`, then you &quot;can&quot; not. Or rather you &quot;can&quot;, but any mut=
able calls will provoke UB.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ebc67007-559d-424d-aaeb-e92be7a615d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ebc67007-559d-424d-aaeb-e92be7a615d7=
%40isocpp.org</a>.<br />

------=_Part_2426_1681725931.1519928988773--

------=_Part_2425_322611762.1519928988773--

.

------=_Part_2485_199712785.1519930786101
Content-Type: multipart/alternative;
 boundary="----=_Part_2486_1394777146.1519930786101"

------=_Part_2486_1394777146.1519930786101
Content-Type: text/plain; charset="UTF-8"

Thank you for your answer.

On Thursday, March 1, 2018 at 7:24:46 PM UTC+1, Nicol Bolas wrote:
>
> On Thursday, March 1, 2018 at 1:11:46 PM UTC-5, jsaintm...@gmail.com
> wrote:
>>
>> If you have several hundreds of possibilities to try, and the object is
>> huge, it's faster to try each, cancel it and try the next one, than to make
>> a copy of the whole object hundreds of times
>>
>
> Then do that. Your method is non-const. There's nothing in the language
> preventing you from doing this.
>
> What you want is not nearly useful enough to be worthy of a language
> feature, even if the feature could be guaranteed by the compiler in some
> way.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f974db8d-01a1-4cc2-9d52-68516bf26dfd%40isocpp.org.

------=_Part_2486_1394777146.1519930786101
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for your answer.<br><br>On Thursday, March 1, 20=
18 at 7:24:46 PM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr">On Thursday, March 1, 2018 at 1:11:46 PM UTC-5=
, <a>jsaintm...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">If you have several hundreds of possibilities to try, and=
 the object is huge, it&#39;s faster to try each, cancel it and try the nex=
t one, than to make a copy of the whole object hundreds of times<br></div><=
/blockquote><div><br>Then do that. Your method is non-const. There&#39;s no=
thing in the language preventing you from doing this.<br><br>What you want =
is not nearly useful enough to be worthy of a language feature, even if the=
 feature could be guaranteed by the compiler in some way.<br></div></div></=
blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f974db8d-01a1-4cc2-9d52-68516bf26dfd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f974db8d-01a1-4cc2-9d52-68516bf26dfd=
%40isocpp.org</a>.<br />

------=_Part_2486_1394777146.1519930786101--

------=_Part_2485_199712785.1519930786101--

.

--089e08232cf4e409ee05665f1dbb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

So the main issue is that some method of avoiding UB is needed but the
method needs to advertise const.

Let's imagine for a second that we now have three layers in the type system
- immutable (writing to memory is always UB), const (like now sans UB so
casts permitted, can't be in ROM) and regular mutable.

Now we are forcing API designers to choose which type of const/immutable
reference they will accept, since immutable objects cannot (ever!) downcast
to const.

Option a) almost-always-immutable&:

This one is very much like the current const& thing. Unfortunately this
means that things that are const& are basically useless in the immutable&
world, since no library actually works with them - they all want immutable&
for convenience's sake so that they can be used with immutable objects.

Option b) almost-always-const&:

In this world, immutable objects are basically useless, since they can't be
used with the majority of libraries, which really just want to say "I'm not
going to mutate this" - and they don't, so could have been taking immutable=
..

Option c) Everyone does their own thing
This one is a mix of above, which sucks even more.


All of these suck. This is why we don't have different meanings of const in
the language. Introducing a third has always seemed like the cure is worse
than the disease.



Basically, I don't know how to do this in a way that doesn't make huge
problems for library authors within the typesystem. Perhaps we could define
const better, and just say that modifying objects declared const is defined
behavior as long as they haven't been put into ROM. Say we introduce
something like

class Foo {
  int bar;
  void my_pseudoconst() const mutable {
    ++bar;
    --bar;
  }
};

which basically says "classes that have mutable methods can't be put into
ROM and have defined const-cast for this semantics". I could do with
something like that. I don't see how introducing another constness category
would ever work, though.

G




On Thu, Mar 1, 2018, 18:29 Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Thursday, March 1, 2018 at 1:26:14 PM UTC-5, Ga=C5=A1per A=C5=BEman wr=
ote:
>>
>> I'm not sure if I understand - is there a scenario where you would
>> provide both a const and a pseudoconst method on a class?
>>
>> If it's just a matter of implementation, you know you can const-cast the
>> this pointer into a non-const pointer so you can call mutable methods on=
 it?
>>
>
> "Can" is a strong word. If the object itself was declared `const`, then
> you "can" not. Or rather you "can", but any mutable calls will provoke UB=
..
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/ebc67007-559d-424d-
> aaeb-e92be7a615d7%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ebc67007-55=
9d-424d-aaeb-e92be7a615d7%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAANG%3DkUYquvFbhyT_zen2Kda1H4R_R8_uMz422zmzEgu%=
3D97yrQ%40mail.gmail.com.

--089e08232cf4e409ee05665f1dbb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto">So the main issue is that some method of=
 avoiding UB is needed but the method needs to advertise const.<div dir=3D"=
auto"><br></div><div dir=3D"auto">Let&#39;s imagine for a second that we no=
w have three layers in the type system - immutable (writing to memory is al=
ways UB), const (like now sans UB so casts permitted, can&#39;t be in ROM) =
and regular mutable.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Now=
 we are forcing API designers to choose which type of const/immutable refer=
ence they will accept, since immutable objects cannot (ever!) downcast to c=
onst.</div><div dir=3D"auto"><br></div><div>Option a) almost-always-immutab=
le&amp;:</div><div><br></div><div>This one is very much like the current co=
nst&amp; thing. Unfortunately this means that things that are const&amp; ar=
e basically useless in the immutable&amp; world, since no library actually =
works with them - they all want immutable&amp; for convenience&#39;s sake s=
o that they can be used with immutable objects.</div><div><br></div><div>Op=
tion b) almost-always-const&amp;:</div><div><br></div><div>In this world, i=
mmutable objects are basically useless, since they can&#39;t be used with t=
he majority of libraries, which really just want to say &quot;I&#39;m not g=
oing to mutate this&quot; - and they don&#39;t, so could have been taking i=
mmutable.</div><div><br></div><div>Option c) Everyone does their own thing<=
/div><div>This one is a mix of above, which sucks even more.</div><div><br>=
</div><div><br></div><div>All of these suck. This is why we don&#39;t have =
different meanings of const in the language. Introducing a third has always=
 seemed like the cure is worse than the disease.</div><div><br></div><div><=
br></div><div><br></div><div>Basically, I don&#39;t know how to do this in =
a way that doesn&#39;t make huge problems for library authors within the ty=
pesystem. Perhaps we could define const better, and just say that modifying=
 objects declared const is defined behavior as long as they haven&#39;t bee=
n put into ROM. Say we introduce something like</div><div><font face=3D"mon=
ospace, monospace"><br></font></div><div><font face=3D"monospace, monospace=
">class Foo {</font></div><div><font face=3D"monospace, monospace">=C2=A0 i=
nt bar;</font></div><div><font face=3D"monospace, monospace">=C2=A0 void my=
_pseudoconst() const mutable {</font></div><div><font face=3D"monospace, mo=
nospace">=C2=A0 =C2=A0 ++bar;</font></div><div><font face=3D"monospace, mon=
ospace">=C2=A0 =C2=A0 --bar;</font></div><div><font face=3D"monospace, mono=
space">=C2=A0 }</font></div><div><font face=3D"monospace, monospace">};</fo=
nt></div><div><br></div><div>which basically says &quot;classes that have m=
utable methods can&#39;t be put into ROM and have defined const-cast for <f=
ont face=3D"monospace, monospace">this=C2=A0</font><font face=3D"arial, hel=
vetica, sans-serif">semantics&quot;. I could do with something like that. I=
 don&#39;t see how introducing another constness category would ever work, =
though.</font></div><div><font face=3D"arial, helvetica, sans-serif"><br></=
font></div><div><font face=3D"arial, helvetica, sans-serif">G</font></div><=
div><br></div><div><br></div><div><br></div></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr">On Thu, Mar 1, 2018, 18:29 Nicol Bolas &lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=
On Thursday, March 1, 2018 at 1:26:14 PM UTC-5, Ga=C5=A1per A=C5=BEman wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">I&#39;m not sur=
e if I understand - is there a scenario where you would provide both a cons=
t and a pseudoconst method on a class?<div dir=3D"auto"><br></div><div dir=
=3D"auto">If it&#39;s just a matter of implementation, you know you can con=
st-cast the this pointer into a non-const pointer so you can call mutable m=
ethods on it?</div></div></blockquote><div><br>&quot;Can&quot; is a strong =
word. If the object itself was declared `const`, then you &quot;can&quot; n=
ot. Or rather you &quot;can&quot;, but any mutable calls will provoke UB.<b=
r></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" rel=3D"nore=
ferrer" target=3D"_blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br=
>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ebc67007-559d-424d-aaeb-e92be7a615d7%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/ebc67007-559d-424d-<wbr>aaeb-e92be7a615d7%40isocpp.org</a><w=
br>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUYquvFbhyT_zen2Kda1H4R_R8_uM=
z422zmzEgu%3D97yrQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUYqu=
vFbhyT_zen2Kda1H4R_R8_uMz422zmzEgu%3D97yrQ%40mail.gmail.com</a>.<br />

--089e08232cf4e409ee05665f1dbb--

.

------=_Part_5916_2049816800.1520022260110
Content-Type: multipart/alternative;
 boundary="----=_Part_5917_1201428770.1520022260110"

------=_Part_5917_1201428770.1520022260110
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes suck yeah, . UB advertise ROM immutable suck...  || Brilliant remarks&,=
=20
thanks

On Thursday, March 1, 2018 at 8:46:36 PM UTC+1, Ga=C5=A1per A=C5=BEman wrot=
e:
>
> So the main issue is that some method of avoiding UB is needed but the=20
> method needs to advertise const.
>
> Let's imagine for a second that we now have three layers in the type=20
> system - immutable (writing to memory is always UB), const (like now sans=
=20
> UB so casts permitted, can't be in ROM) and regular mutable.
>
> Now we are forcing API designers to choose which type of const/immutable=
=20
> reference they will accept, since immutable objects cannot (ever!) downca=
st=20
> to const.
>
> Option a) almost-always-immutable&:
>
> This one is very much like the current const& thing. Unfortunately this=
=20
> means that things that are const& are basically useless in the immutable&=
=20
> world, since no library actually works with them - they all want immutabl=
e&=20
> for convenience's sake so that they can be used with immutable objects.
>
> Option b) almost-always-const&:
>
> In this world, immutable objects are basically useless, since they can't=
=20
> be used with the majority of libraries, which really just want to say "I'=
m=20
> not going to mutate this" - and they don't, so could have been taking=20
> immutable.
>
> Option c) Everyone does their own thing
> This one is a mix of above, which sucks even more.
>
>
> All of these suck. This is why we don't have different meanings of const=
=20
> in the language. Introducing a third has always seemed like the cure is=
=20
> worse than the disease.
>
>
>
> Basically, I don't know how to do this in a way that doesn't make huge=20
> problems for library authors within the typesystem. Perhaps we could defi=
ne=20
> const better, and just say that modifying objects declared const is defin=
ed=20
> behavior as long as they haven't been put into ROM. Say we introduce=20
> something like
>
> class Foo {
>   int bar;
>   void my_pseudoconst() const mutable {
>     ++bar;
>     --bar;
>   }
> };
>
> which basically says "classes that have mutable methods can't be put into=
=20
> ROM and have defined const-cast for this semantics". I could do with=20
> something like that. I don't see how introducing another constness catego=
ry=20
> would ever work, though.
>
> G
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/16dd8e15-88b9-421f-a6cb-4d69073162d0%40isocpp.or=
g.

------=_Part_5917_1201428770.1520022260110
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes suck yeah, . UB advertise ROM immutable suck...=C2=A0 =
|| Brilliant remarks&amp;, thanks<br><br>On Thursday, March 1, 2018 at 8:46=
:36 PM UTC+1, Ga=C5=A1per A=C5=BEman wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><div dir=3D"auto">So the main issue is that s=
ome method of avoiding UB is needed but the method needs to advertise const=
..<div dir=3D"auto"><br></div><div dir=3D"auto">Let&#39;s imagine for a seco=
nd that we now have three layers in the type system - immutable (writing to=
 memory is always UB), const (like now sans UB so casts permitted, can&#39;=
t be in ROM) and regular mutable.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Now we are forcing API designers to choose which type of const/im=
mutable reference they will accept, since immutable objects cannot (ever!) =
downcast to const.</div><div dir=3D"auto"><br></div><div>Option a) almost-a=
lways-immutable&amp;:</div><div><br></div><div>This one is very much like t=
he current const&amp; thing. Unfortunately this means that things that are =
const&amp; are basically useless in the immutable&amp; world, since no libr=
ary actually works with them - they all want immutable&amp; for convenience=
&#39;s sake so that they can be used with immutable objects.</div><div><br>=
</div><div>Option b) almost-always-const&amp;:</div><div><br></div><div>In =
this world, immutable objects are basically useless, since they can&#39;t b=
e used with the majority of libraries, which really just want to say &quot;=
I&#39;m not going to mutate this&quot; - and they don&#39;t, so could have =
been taking immutable.</div><div><br></div><div>Option c) Everyone does the=
ir own thing</div><div>This one is a mix of above, which sucks even more.</=
div><div><br></div><div><br></div><div>All of these suck. This is why we do=
n&#39;t have different meanings of const in the language. Introducing a thi=
rd has always seemed like the cure is worse than the disease.</div><div><br=
></div><div><br></div><div><br></div><div>Basically, I don&#39;t know how t=
o do this in a way that doesn&#39;t make huge problems for library authors =
within the typesystem. Perhaps we could define const better, and just say t=
hat modifying objects declared const is defined behavior as long as they ha=
ven&#39;t been put into ROM. Say we introduce something like</div><div><fon=
t face=3D"monospace, monospace"><br></font></div><div><font face=3D"monospa=
ce, monospace">class Foo {</font></div><div><font face=3D"monospace, monosp=
ace">=C2=A0 int bar;</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 void my_pseudoconst() const mutable {</font></div><div><font face=3D=
"monospace, monospace">=C2=A0 =C2=A0 ++bar;</font></div><div><font face=3D"=
monospace, monospace">=C2=A0 =C2=A0 --bar;</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 }</font></div><div><font face=3D"monospace, mon=
ospace">};</font></div><div><br></div><div>which basically says &quot;class=
es that have mutable methods can&#39;t be put into ROM and have defined con=
st-cast for <font face=3D"monospace, monospace">this=C2=A0</font><font face=
=3D"arial, helvetica, sans-serif">semantics&quot;. I could do with somethin=
g like that. I don&#39;t see how introducing another constness category wou=
ld ever work, though.</font></div><div><font face=3D"arial, helvetica, sans=
-serif"><br></font></div><div><font face=3D"arial, helvetica, sans-serif">G=
</font></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/16dd8e15-88b9-421f-a6cb-4d69073162d0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/16dd8e15-88b9-421f-a6cb-4d69073162d0=
%40isocpp.org</a>.<br />

------=_Part_5917_1201428770.1520022260110--

------=_Part_5916_2049816800.1520022260110--

.

------=_Part_6015_1342849460.1520023165240
Content-Type: multipart/alternative;
 boundary="----=_Part_6016_2024430145.1520023165240"

------=_Part_6016_2024430145.1520023165240
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

there might be other sites where you can write "suck" ? I did not thought=
=20
this was for this

On Thursday, March 1, 2018 at 8:46:36 PM UTC+1, Ga=C5=A1per A=C5=BEman wrot=
e:
>
> So the main issue is that some method of avoiding UB is needed but the=20
> method needs to advertise const.
>
> Let's imagine for a second that we now have three layers in the type=20
> system - immutable (writing to memory is always UB), const (like now sans=
=20
> UB so casts permitted, can't be in ROM) and regular mutable.
>
> Now we are forcing API designers to choose which type of const/immutable=
=20
> reference they will accept, since immutable objects cannot (ever!) downca=
st=20
> to const.
>
> Option a) almost-always-immutable&:
>
> This one is very much like the current const& thing. Unfortunately this=
=20
> means that things that are const& are basically useless in the immutable&=
=20
> world, since no library actually works with them - they all want immutabl=
e&=20
> for convenience's sake so that they can be used with immutable objects.
>
> Option b) almost-always-const&:
>
> In this world, immutable objects are basically useless, since they can't=
=20
> be used with the majority of libraries, which really just want to say "I'=
m=20
> not going to mutate this" - and they don't, so could have been taking=20
> immutable.
>
> Option c) Everyone does their own thing
> This one is a mix of above, which sucks even more.
>
>
> All of these suck. This is why we don't have different meanings of const=
=20
> in the language. Introducing a third has always seemed like the cure is=
=20
> worse than the disease.
>
>
>
> Basically, I don't know how to do this in a way that doesn't make huge=20
> problems for library authors within the typesystem. Perhaps we could defi=
ne=20
> const better, and just say that modifying objects declared const is defin=
ed=20
> behavior as long as they haven't been put into ROM. Say we introduce=20
> something like
>
> class Foo {
>   int bar;
>   void my_pseudoconst() const mutable {
>     ++bar;
>     --bar;
>   }
> };
>
> which basically says "classes that have mutable methods can't be put into=
=20
> ROM and have defined const-cast for this semantics". I could do with=20
> something like that. I don't see how introducing another constness catego=
ry=20
> would ever work, though.
>
> G
>
>
>
>
> On Thu, Mar 1, 2018, 18:29 Nicol Bolas <jmck...@gmail.com <javascript:>>=
=20
> wrote:
>
>>
>>
>> On Thursday, March 1, 2018 at 1:26:14 PM UTC-5, Ga=C5=A1per A=C5=BEman w=
rote:
>>>
>>> I'm not sure if I understand - is there a scenario where you would=20
>>> provide both a const and a pseudoconst method on a class?
>>>
>>> If it's just a matter of implementation, you know you can const-cast th=
e=20
>>> this pointer into a non-const pointer so you can call mutable methods o=
n it?
>>>
>>
>> "Can" is a strong word. If the object itself was declared `const`, then=
=20
>> you "can" not. Or rather you "can", but any mutable calls will provoke U=
B.
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ebc67007-55=
9d-424d-aaeb-e92be7a615d7%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ebc67007-5=
59d-424d-aaeb-e92be7a615d7%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/546e86f3-ab4e-4e8c-b163-0059910744cb%40isocpp.or=
g.

------=_Part_6016_2024430145.1520023165240
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">there might be other sites where you can write &quot;suck&=
quot; ? I did not thought this was for this<br><br>On Thursday, March 1, 20=
18 at 8:46:36 PM UTC+1, Ga=C5=A1per A=C5=BEman wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div dir=3D"auto">So the main issue=
 is that some method of avoiding UB is needed but the method needs to adver=
tise const.<div dir=3D"auto"><br></div><div dir=3D"auto">Let&#39;s imagine =
for a second that we now have three layers in the type system - immutable (=
writing to memory is always UB), const (like now sans UB so casts permitted=
, can&#39;t be in ROM) and regular mutable.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Now we are forcing API designers to choose which type o=
f const/immutable reference they will accept, since immutable objects canno=
t (ever!) downcast to const.</div><div dir=3D"auto"><br></div><div>Option a=
) almost-always-immutable&amp;:</div><div><br></div><div>This one is very m=
uch like the current const&amp; thing. Unfortunately this means that things=
 that are const&amp; are basically useless in the immutable&amp; world, sin=
ce no library actually works with them - they all want immutable&amp; for c=
onvenience&#39;s sake so that they can be used with immutable objects.</div=
><div><br></div><div>Option b) almost-always-const&amp;:</div><div><br></di=
v><div>In this world, immutable objects are basically useless, since they c=
an&#39;t be used with the majority of libraries, which really just want to =
say &quot;I&#39;m not going to mutate this&quot; - and they don&#39;t, so c=
ould have been taking immutable.</div><div><br></div><div>Option c) Everyon=
e does their own thing</div><div>This one is a mix of above, which sucks ev=
en more.</div><div><br></div><div><br></div><div>All of these suck. This is=
 why we don&#39;t have different meanings of const in the language. Introdu=
cing a third has always seemed like the cure is worse than the disease.</di=
v><div><br></div><div><br></div><div><br></div><div>Basically, I don&#39;t =
know how to do this in a way that doesn&#39;t make huge problems for librar=
y authors within the typesystem. Perhaps we could define const better, and =
just say that modifying objects declared const is defined behavior as long =
as they haven&#39;t been put into ROM. Say we introduce something like</div=
><div><font face=3D"monospace, monospace"><br></font></div><div><font face=
=3D"monospace, monospace">class Foo {</font></div><div><font face=3D"monosp=
ace, monospace">=C2=A0 int bar;</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 void my_pseudoconst() const mutable {</font></div><div><fo=
nt face=3D"monospace, monospace">=C2=A0 =C2=A0 ++bar;</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 =C2=A0 --bar;</font></div><div><font=
 face=3D"monospace, monospace">=C2=A0 }</font></div><div><font face=3D"mono=
space, monospace">};</font></div><div><br></div><div>which basically says &=
quot;classes that have mutable methods can&#39;t be put into ROM and have d=
efined const-cast for <font face=3D"monospace, monospace">this=C2=A0</font>=
<font face=3D"arial, helvetica, sans-serif">semantics&quot;. I could do wit=
h something like that. I don&#39;t see how introducing another constness ca=
tegory would ever work, though.</font></div><div><font face=3D"arial, helve=
tica, sans-serif"><br></font></div><div><font face=3D"arial, helvetica, san=
s-serif">G</font></div><div><br></div><div><br></div><div><br></div></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Mar 1, 2018, 18:29 N=
icol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"6n5SESr4CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;">jmck...@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br><br>On Thursday, March 1, 2018 at 1:26:14 PM U=
TC-5, Ga=C5=A1per A=C5=BEman wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"auto">I&#39;m not sure if I understand - is there a scenario w=
here you would provide both a const and a pseudoconst method on a class?<di=
v dir=3D"auto"><br></div><div dir=3D"auto">If it&#39;s just a matter of imp=
lementation, you know you can const-cast the this pointer into a non-const =
pointer so you can call mutable methods on it?</div></div></blockquote><div=
><br>&quot;Can&quot; is a strong word. If the object itself was declared `c=
onst`, then you &quot;can&quot; not. Or rather you &quot;can&quot;, but any=
 mutable calls will provoke UB.<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"6n5SESr4CgAJ" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"6n5SESr4CgAJ" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ebc67007-559d-424d-aaeb-e92be7a615d7%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/ebc67007-559d-424d-aaeb-e92be7a615d7%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/ebc67007-559d-424d-aaeb-e92be7a615d7%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ebc67007-559d-424d-<wbr>aaeb-=
e92be7a615d7%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/546e86f3-ab4e-4e8c-b163-0059910744cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/546e86f3-ab4e-4e8c-b163-0059910744cb=
%40isocpp.org</a>.<br />

------=_Part_6016_2024430145.1520023165240--

------=_Part_6015_1342849460.1520023165240--

.

------=_Part_1025_1688497843.1520023893786
Content-Type: multipart/alternative;
 boundary="----=_Part_1026_1799831337.1520023893786"

------=_Part_1026_1799831337.1520023893786
Content-Type: text/plain; charset="UTF-8"

or is your vocabulary limited to "suck"

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ffd4c4fd-2896-449a-b157-8c4d8894c9ec%40isocpp.org.

------=_Part_1026_1799831337.1520023893786
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">or is your vocabulary limited to &quot;suck&quot;<br></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ffd4c4fd-2896-449a-b157-8c4d8894c9ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ffd4c4fd-2896-449a-b157-8c4d8894c9ec=
%40isocpp.org</a>.<br />

------=_Part_1026_1799831337.1520023893786--

------=_Part_1025_1688497843.1520023893786--

.

--f403043ebce060055e0566744d5a
Content-Type: text/plain; charset="UTF-8"

There are plenty of more fitting four letter words, but their use would be
frowned upon.

Suck is perfectly fine. Criticising another person's choice of words is
not. Don't push your luck.

On 2 Mar 2018 20:51, <jsaintmartin356@gmail.com> wrote:

> or is your vocabulary limited to "suck"
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNvaGpqL0Y6YzS0mh1%3D8Jzsuy_b44DJs-BgOyr2bmtd6Q%40mail.gmail.com.

--f403043ebce060055e0566744d5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>There are plenty of more fitting four letter words, =
but their use would be frowned upon.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Suck is perfectly fine. Criticising another person&#39;s choic=
e of words is not. Don&#39;t push your luck.</div><div dir=3D"auto"><div cl=
ass=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quote">On 2 Mar 20=
18 20:51,  &lt;<a href=3D"mailto:jsaintmartin356@gmail.com" target=3D"_blan=
k">jsaintmartin356@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">or is your vocabulary limited to &=
quot;suck&quot;</div>
</blockquote></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNvaGpqL0Y6YzS0mh1%3D8Jzsuy_b=
44DJs-BgOyr2bmtd6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNvaG=
pqL0Y6YzS0mh1%3D8Jzsuy_b44DJs-BgOyr2bmtd6Q%40mail.gmail.com</a>.<br />

--f403043ebce060055e0566744d5a--

.

------=_Part_5950_1643914224.1520025459857
Content-Type: multipart/alternative;
 boundary="----=_Part_5951_227549309.1520025459857"

------=_Part_5951_227549309.1520025459857
Content-Type: text/plain; charset="UTF-8"

Go n buy a brain. Nicol Bolas understood. Ask him.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17253481-f55c-4a4d-b316-ef4398aaa18a%40isocpp.org.

------=_Part_5951_227549309.1520025459857
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Go n buy a brain. Nicol Bolas understood. Ask him.<br></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/17253481-f55c-4a4d-b316-ef4398aaa18a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/17253481-f55c-4a4d-b316-ef4398aaa18a=
%40isocpp.org</a>.<br />

------=_Part_5951_227549309.1520025459857--

------=_Part_5950_1643914224.1520025459857--

.

------=_Part_5997_1632131450.1520025895872
Content-Type: multipart/alternative;
 boundary="----=_Part_5998_2041820142.1520025895872"

------=_Part_5998_2041820142.1520025895872
Content-Type: text/plain; charset="UTF-8"

I dont like it. If this suit you, please, go for it, but without me

On Friday, March 2, 2018 at 10:03:05 PM UTC+1, Jake Arkinstall wrote:
>
> There are plenty of more fitting four letter words, but their use would be
> frowned upon.
>
> Suck is perfectly fine. Criticising another person's choice of words is
> not. Don't push your luck.
>
> On 2 Mar 2018 20:51, <jsaintm...@gmail.com <javascript:>> wrote:
>
>> or is your vocabulary limited to "suck"
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ff0afdc7-957e-4c51-b7d2-a2e6d0a37aa3%40isocpp.org.

------=_Part_5998_2041820142.1520025895872
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I dont like it. If this suit you, please, go for it, but w=
ithout me<br><br>On Friday, March 2, 2018 at 10:03:05 PM UTC+1, Jake Arkins=
tall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><=
div>There are plenty of more fitting four letter words, but their use would=
 be frowned upon.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Suck i=
s perfectly fine. Criticising another person&#39;s choice of words is not. =
Don&#39;t push your luck.</div><div dir=3D"auto"><div dir=3D"auto"><br><div=
 class=3D"gmail_quote">On 2 Mar 2018 20:51,  &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"8s__C-tKCwAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;">jsaintm...@gmail.com</a>&gt; wr=
ote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">or is your vocabulary limited to &quot;suck&quot;</div>
</blockquote></div></div>
</div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ff0afdc7-957e-4c51-b7d2-a2e6d0a37aa3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ff0afdc7-957e-4c51-b7d2-a2e6d0a37aa3=
%40isocpp.org</a>.<br />

------=_Part_5998_2041820142.1520025895872--

------=_Part_5997_1632131450.1520025895872--

.

------=_Part_6288_755958618.1520027268445
Content-Type: multipart/alternative;
 boundary="----=_Part_6289_1106999193.1520027268445"

------=_Part_6289_1106999193.1520027268445
Content-Type: text/plain; charset="UTF-8"

Even if there are more words in French than in English, I believed it was
possible to male two sentences in English, without using "suck". I was
mistaken. Sorry

On Friday, March 2, 2018 at 10:03:05 PM UTC+1, Jake Arkinstall wrote:
>
> There are plenty of more fitting four letter words, but their use would be
> frowned upon.
>
> Suck is perfectly fine. Criticising another person's choice of words is
> not. Don't push your luck.
>
> On 2 Mar 2018 20:51, <jsaintm...@gmail.com <javascript:>> wrote:
>
>> or is your vocabulary limited to "suck"
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%40isocpp.org.

------=_Part_6289_1106999193.1520027268445
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Even if there are more words in French than in English, I =
believed it was possible to male two sentences in English, without using &q=
uot;suck&quot;. I was mistaken. Sorry<br><br>On Friday, March 2, 2018 at 10=
:03:05 PM UTC+1, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"auto"><div>There are plenty of more fitting four lette=
r words, but their use would be frowned upon.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Suck is perfectly fine. Criticising another person&#3=
9;s choice of words is not. Don&#39;t push your luck.</div><div dir=3D"auto=
"><div dir=3D"auto"><br><div class=3D"gmail_quote">On 2 Mar 2018 20:51,  &l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8s__C-=
tKCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jsa=
intm...@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">or is your vocabulary limited to &quot;suck&=
quot;</div>
</blockquote></div></div>
</div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4=
%40isocpp.org</a>.<br />

------=_Part_6289_1106999193.1520027268445--

------=_Part_6288_755958618.1520027268445--

.

--94eb2c068ceadb97b905667e8b64
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Jerome,


I'm sorry if I offended you by using emphatic (as opposed to graphic)
language. I thought it would get the message of how unfortunate the
situation I was outlining was. Instead, I achieved a fixation on a
communication technique instead of the message, which was not my intention.
I'd also like to avoid another one-liner storm that completely derailed the
discussion.

I'd like to continue this discussion, so please, replace, in your mind, if
you don't mind, the word "suck" with "not ideal", and address my concerns
on a substantive level, like I tried to address yours.

In fact, I believe I suggested an alternative solution for your problem
that avoids the type system issues that come with bifurcating the meaning
of const, which has been *actually refused* several times, for the outlined
reasons that I'm not the first to bring up (though perhaps in this
discussion, my elucidation of them was the most direct).

The solution I suggested, if it was not obvious, is to, for classes that
define a "const mutable" method, *define (as opposed to UB) what a
const-declared object of that type is allowed to be. F*or such classes (and
classes containing them), even const-declared objects cannot be put into
ROM, which means that const-cast of *this* is not UB for them. That should
address your implementation concerns without bifurcating the type system,
unless I'm misunderstanding something and you *want* to provide both a
*const * and a *pseudoconst* method on the same class, in which case,
please elucidate why that would ever be useful, because I truly cannot
think of an example.


Ga=C5=A1per



On Fri, Mar 2, 2018 at 9:47 PM, <jsaintmartin356@gmail.com> wrote:

> Even if there are more words in French than in English, I believed it was
> possible to male two sentences in English, without using "suck". I was
> mistaken. Sorry
>
> On Friday, March 2, 2018 at 10:03:05 PM UTC+1, Jake Arkinstall wrote:
>>
>> There are plenty of more fitting four letter words, but their use would
>> be frowned upon.
>>
>> Suck is perfectly fine. Criticising another person's choice of words is
>> not. Don't push your luck.
>>
>> On 2 Mar 2018 20:51, <jsaintm...@gmail.com> wrote:
>>
>>> or is your vocabulary limited to "suck"
>>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-
> 9bfc-de4f6ffbdfd4%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-21=
94-473b-9bfc-de4f6ffbdfd4%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAANG%3DkX-Bqj_qyU0eKMx-5SvNG6BmqyHXxBaehbR3DKbb=
mqFvQ%40mail.gmail.com.

--94eb2c068ceadb97b905667e8b64
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Jerome,<div><br></div><div><br></div><div>I&#39;m sorry if=
 I offended you by using emphatic (as opposed to graphic) language. I thoug=
ht it would get the message of how unfortunate the situation I was outlinin=
g was. Instead, I achieved a fixation on a communication technique instead =
of the message, which was not my intention. I&#39;d also like to avoid anot=
her one-liner storm that completely derailed the discussion.</div><div><br>=
</div><div>I&#39;d like to continue this discussion, so please, replace, in=
 your mind, if you don&#39;t mind, the word &quot;suck&quot; with &quot;not=
 ideal&quot;, and address my concerns on a substantive level, like I tried =
to address yours.</div><div><br></div><div>In fact, I believe I suggested a=
n alternative solution for your problem that avoids the type system issues =
that come with bifurcating the meaning of const, which has been <i>actually=
 refused</i>=C2=A0several times, for the outlined reasons that I&#39;m not =
the first to bring up (though perhaps in this discussion, my elucidation of=
 them was the most direct).</div><div><br></div><div>The solution I suggest=
ed, if it was not obvious, is to,=C2=A0<span style=3D"color:rgb(34,34,34);f=
ont-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-=
ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:no=
rmal;text-align:start;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:=
initial;text-decoration-color:initial;float:none;display:inline">for classe=
s that define a &quot;const mutable&quot; method,=C2=A0</span><i>define (as=
 opposed to UB) what a const-declared object of that type is allowed to be.=
 F</i>or such classes (and classes containing them), even const-declared ob=
jects cannot be put into ROM, which means that const-cast of <i>this</i>=C2=
=A0is not UB for them. That should address your implementation concerns wit=
hout bifurcating the type system, unless I&#39;m misunderstanding something=
 and you <i>want</i> to provide both a <i>const=C2=A0</i>=C2=A0and a <i>pse=
udoconst</i>=C2=A0method on the same class, in which case, please elucidate=
 why that would ever be useful, because I truly cannot think of an example.=
</div><div><br></div><div><br></div><div>Ga=C5=A1per</div><div><br></div><d=
iv><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Fri, Mar 2, 2018 at 9:47 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:=
jsaintmartin356@gmail.com" target=3D"_blank">jsaintmartin356@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Even i=
f there are more words in French than in English, I believed it was possibl=
e to male two sentences in English, without using &quot;suck&quot;. I was m=
istaken. Sorry<span class=3D""><br><br>On Friday, March 2, 2018 at 10:03:05=
 PM UTC+1, Jake Arkinstall wrote:</span><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"auto"><span class=3D""><div>There are plenty of more fitti=
ng four letter words, but their use would be frowned upon.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Suck is perfectly fine. Criticising anot=
her person&#39;s choice of words is not. Don&#39;t push your luck.</div></s=
pan><span class=3D""><div dir=3D"auto"><div dir=3D"auto"><br><div class=3D"=
gmail_quote">On 2 Mar 2018 20:51,  &lt;<a rel=3D"nofollow">jsaintm...@gmail=
..com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">or is your vocabulary limited to &quot;suck&quot;</div>
</blockquote></div></div>
</div></span></div>
</blockquote></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/67e1=
c1c7-2194-473b-<wbr>9bfc-de4f6ffbdfd4%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkX-Bqj_qyU0eKMx-5SvNG6BmqyHXx=
BaehbR3DKbbmqFvQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkX-Bqj_=
qyU0eKMx-5SvNG6BmqyHXxBaehbR3DKbbmqFvQ%40mail.gmail.com</a>.<br />

--94eb2c068ceadb97b905667e8b64--

.

------=_Part_1668_1325101026.1520343500346
Content-Type: multipart/alternative;
 boundary="----=_Part_1669_1386101393.1520343500346"

------=_Part_1669_1386101393.1520343500346
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


got a partial answer to my own question, but it might interest some other=
=20
coders : it's looks not possible to know what will be an object at next=20
iteration in a const method, without copying it, but it is possible in a=20
const method, without creating another object (just a copy to an existing=
=20
one). const qualifier after a method that modifies static members static=20
members is valid, and I am using this. This aspect of C++ may not be known=
=20
enough :

  class Integer {
  public :
    Integer (size_t s) : val_ (s) {}
    ~Integer () {}
    Integer (const Integer& i) : val_ (i.val_) {}
    Integer& operator =3D (const Integer& i) {val_ =3D i.val_; return *this=
;}
    bool operator =3D=3D (const Integer& i) {return (val_ =3D=3D=20
i.val_?true:false);}
    bool operator !=3D (const Integer& i) {return !operator =3D=3D (i);}
    void write (std::ostream& os) const {
      os << val_;
    }
    void write_next (std::ostream& os) const {
      me_stat =3D *this;
      me_stat++;
      me_stat.write (os);
    }
    Integer& operator ++ (int) {
      val_++;
      return *this;
    }
  private :
    static Integer me_stat;
    size_t val_;
  };

  Integer Integer::me_stat (0);

  int main (int argc, char* argv []) {
    Integer i (7);
    std::cout << "i =3D=3D ";
    i.write (std::cout);
    std::cout << std::endl;
    std::cout << "i next =3D=3D ";
    i.write_next (std::cout);
    std::cout << std::endl;
    std::cout << "i again =3D=3D ";
    i.write (std::cout);
    std::cout << std::endl;
  }

results :
  i =3D=3D 7
  i next =3D=3D 8
  i again =3D=3D 7

On Saturday, March 3, 2018 at 10:16:25 AM UTC+1, Ga=C5=A1per A=C5=BEman wro=
te:
>
> Jerome,
>
>
> I'm sorry if I offended you by using emphatic (as opposed to graphic)=20
> language. I thought it would get the message of how unfortunate the=20
> situation I was outlining was. Instead, I achieved a fixation on a=20
> communication technique instead of the message, which was not my intentio=
n.=20
> I'd also like to avoid another one-liner storm that completely derailed t=
he=20
> discussion.
>
> I'd like to continue this discussion, so please, replace, in your mind, i=
f=20
> you don't mind, the word "suck" with "not ideal", and address my concerns=
=20
> on a substantive level, like I tried to address yours.
>
> In fact, I believe I suggested an alternative solution for your problem=
=20
> that avoids the type system issues that come with bifurcating the meaning=
=20
> of const, which has been *actually refused* several times, for the=20
> outlined reasons that I'm not the first to bring up (though perhaps in th=
is=20
> discussion, my elucidation of them was the most direct).
>
> The solution I suggested, if it was not obvious, is to, for classes that=
=20
> define a "const mutable" method, *define (as opposed to UB) what a=20
> const-declared object of that type is allowed to be. F*or such classes=20
> (and classes containing them), even const-declared objects cannot be put=
=20
> into ROM, which means that const-cast of *this* is not UB for them. That=
=20
> should address your implementation concerns without bifurcating the type=
=20
> system, unless I'm misunderstanding something and you *want* to provide=
=20
> both a *const * and a *pseudoconst* method on the same class, in which=20
> case, please elucidate why that would ever be useful, because I truly=20
> cannot think of an example.
>
>
> Ga=C5=A1per
>
>
>
> On Fri, Mar 2, 2018 at 9:47 PM, <jsaintm...@gmail.com <javascript:>>=20
> wrote:
>
>> Even if there are more words in French than in English, I believed it wa=
s=20
>> possible to male two sentences in English, without using "suck". I was=
=20
>> mistaken. Sorry
>>
>> On Friday, March 2, 2018 at 10:03:05 PM UTC+1, Jake Arkinstall wrote:
>>>
>>> There are plenty of more fitting four letter words, but their use would=
=20
>>> be frowned upon.
>>>
>>> Suck is perfectly fine. Criticising another person's choice of words is=
=20
>>> not. Don't push your luck.
>>>
>>> On 2 Mar 2018 20:51, <jsaintm...@gmail.com> wrote:
>>>
>>>> or is your vocabulary limited to "suck"
>>>>
>>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-21=
94-473b-9bfc-de4f6ffbdfd4%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2=
194-473b-9bfc-de4f6ffbdfd4%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5e4668bb-1653-49ef-a1bb-9a74081d1cab%40isocpp.or=
g.

------=_Part_1669_1386101393.1520343500346
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>got a partial answer to my own question, but it might =
interest some other coders : it&#39;s looks not possible to know what will =
be an object at next iteration in a const method, without copying it, but i=
t is possible in a const method, without creating another object (just a co=
py to an existing one). const qualifier after a method that modifies static=
 members static members is valid, and I am using this. This aspect of C++ m=
ay not be known enough :<br><br>=C2=A0 class Integer {<br>=C2=A0 public :<b=
r>=C2=A0=C2=A0=C2=A0 Integer (size_t s) : val_ (s) {}<br>=C2=A0 =C2=A0 ~Int=
eger () {}<br>=C2=A0=C2=A0=C2=A0 Integer (const Integer&amp; i) : val_ (i.v=
al_) {}<br>=C2=A0 =C2=A0 Integer&amp; operator =3D (const Integer&amp; i) {=
val_ =3D i.val_; return *this;}<br>=C2=A0=C2=A0=C2=A0 bool operator =3D=3D =
(const Integer&amp; i) {return (val_ =3D=3D i.val_?true:false);}<br>=C2=A0 =
=C2=A0 bool operator !=3D (const Integer&amp; i) {return !operator =3D=3D (=
i);}<br>=C2=A0=C2=A0=C2=A0 void write (std::ostream&amp; os) const {<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 os &lt;&lt; val_;<br>=C2=A0 =C2=A0 }<br>=C2=A0=
=C2=A0=C2=A0 void write_next (std::ostream&amp; os) const {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 me_stat =3D *this;<br>=C2=A0=C2=A0 =C2=A0=C2=A0 me_stat+=
+;<br>=C2=A0 =C2=A0 =C2=A0 me_stat.write (os);<br>=C2=A0 =C2=A0 }<br>=C2=A0=
=C2=A0=C2=A0 Integer&amp; operator ++ (int) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 val_++;<br>=C2=A0=C2=A0 =C2=A0=C2=A0 return *this;<br>=C2=A0=C2=A0=
=C2=A0 }<br>=C2=A0 private :<br>=C2=A0=C2=A0=C2=A0 static Integer me_stat;<=
br>=C2=A0 =C2=A0 size_t val_;<br>=C2=A0 };<br><br>=C2=A0 Integer Integer::m=
e_stat (0);<br><br>=C2=A0 int main (int argc, char* argv []) {<br>=C2=A0=C2=
=A0=C2=A0 Integer i (7);<br>=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;i =3D=3D=
 &quot;;<br>=C2=A0 =C2=A0 i.write (std::cout);<br>=C2=A0 =C2=A0 std::cout &=
lt;&lt; std::endl;<br>=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;i next =3D=3D =
&quot;;<br>=C2=A0=C2=A0=C2=A0 i.write_next (std::cout);<br>=C2=A0 =C2=A0 st=
d::cout &lt;&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;=
i again =3D=3D &quot;;<br>=C2=A0 =C2=A0 i.write (std::cout);<br>=C2=A0=C2=
=A0=C2=A0 std::cout &lt;&lt; std::endl;<br>=C2=A0 }<br><br>results :<br>=C2=
=A0 i =3D=3D 7<br>=C2=A0 i next =3D=3D 8<br>=C2=A0 i again =3D=3D 7<br><br>=
On Saturday, March 3, 2018 at 10:16:25 AM UTC+1, Ga=C5=A1per A=C5=BEman wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Jerome,<di=
v><br></div><div><br></div><div>I&#39;m sorry if I offended you by using em=
phatic (as opposed to graphic) language. I thought it would get the message=
 of how unfortunate the situation I was outlining was. Instead, I achieved =
a fixation on a communication technique instead of the message, which was n=
ot my intention. I&#39;d also like to avoid another one-liner storm that co=
mpletely derailed the discussion.</div><div><br></div><div>I&#39;d like to =
continue this discussion, so please, replace, in your mind, if you don&#39;=
t mind, the word &quot;suck&quot; with &quot;not ideal&quot;, and address m=
y concerns on a substantive level, like I tried to address yours.</div><div=
><br></div><div>In fact, I believe I suggested an alternative solution for =
your problem that avoids the type system issues that come with bifurcating =
the meaning of const, which has been <i>actually refused</i>=C2=A0several t=
imes, for the outlined reasons that I&#39;m not the first to bring up (thou=
gh perhaps in this discussion, my elucidation of them was the most direct).=
</div><div><br></div><div>The solution I suggested, if it was not obvious, =
is to,=C2=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif=
;font-size:small;font-style:normal;font-weight:400;letter-spacing:normal;te=
xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px;background-color:rgb(255,255,255);float:none;display:inline">fo=
r classes that define a &quot;const mutable&quot; method,=C2=A0</span><i>de=
fine (as opposed to UB) what a const-declared object of that type is allowe=
d to be. F</i>or such classes (and classes containing them), even const-dec=
lared objects cannot be put into ROM, which means that const-cast of <i>thi=
s</i>=C2=A0is not UB for them. That should address your implementation conc=
erns without bifurcating the type system, unless I&#39;m misunderstanding s=
omething and you <i>want</i> to provide both a <i>const=C2=A0</i>=C2=A0and =
a <i>pseudoconst</i>=C2=A0method on the same class, in which case, please e=
lucidate why that would ever be useful, because I truly cannot think of an =
example.</div><div><br></div><div><br></div><div>Ga=C5=A1per</div><div><br>=
</div><div><br></div></div><div><br><div class=3D"gmail_quote">On Fri, Mar =
2, 2018 at 9:47 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"QcFLkO9yCwAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">jsaintm...@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Even if there ar=
e more words in French than in English, I believed it was possible to male =
two sentences in English, without using &quot;suck&quot;. I was mistaken. S=
orry<span><br><br>On Friday, March 2, 2018 at 10:03:05 PM UTC+1, Jake Arkin=
stall wrote:</span><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto=
"><span><div>There are plenty of more fitting four letter words, but their =
use would be frowned upon.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Suck is perfectly fine. Criticising another person&#39;s choice of words=
 is not. Don&#39;t push your luck.</div></span><span><div dir=3D"auto"><div=
 dir=3D"auto"><br><div class=3D"gmail_quote">On 2 Mar 2018 20:51,  &lt;<a r=
el=3D"nofollow">jsaintm...@gmail.com</a>&gt; wrote:<br type=3D"attribution"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">or is your vocabulary limi=
ted to &quot;suck&quot;</div>
</blockquote></div></div>
</div></span></div>
</blockquote></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
QcFLkO9yCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"QcFLkO9yCwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/67e1c1c7-2194-473b-<wbr>9bfc-=
de4f6ffbdfd4%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5e4668bb-1653-49ef-a1bb-9a74081d1cab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e4668bb-1653-49ef-a1bb-9a74081d1cab=
%40isocpp.org</a>.<br />

------=_Part_1669_1386101393.1520343500346--

------=_Part_1668_1325101026.1520343500346--

.

--001a1141d570dde09f0566bf3607
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This isn't thread safe, so I'd throw a mutex in there. Also it is no
different to just creating a new object when you call the method, except
that you're keeping a temporary object in memory for the duration of the
program. If your object is designed to be short-lived, e.g. it utilises
RAII, then keeping it alive for longer than anticipated might cause
confusion; the lifetime is determined not by the object itself, but by the
next object to replace it (or by the program terminating).

I still think the optimal solution is usually going to be a view. This
allows you to keep the underlying object completely unchanged and prevents
you from having to copy the intended object at all. You can also chain
these views, storing the underlying const reference each time, and
successively adding the addition parameter.

class addition_view{
public:
    addition_view(const Integer& underlying, size_t to_add)
    :
        underlying(underlying),
        to_add(to_add)
    {}
    addition_view(const addition_view& other, size_t to_add)
    :
        underlying(other.underlying),
        to_add(other.to_add + to_add)
    {}
    void write(std::ostream& os) const{
        os << "The number is "
           << (underlying.value + to_add);
    }
protected:
    const Integer& underlying;
    size_t to_add;
};

You can then make addition_view a friend class of Integer and utilise it
whenever you want a const method that "appears" to modify the value. The
benefit for a single size_t is minimal, but when you're working with many
values with fewer modifiers (e.g. your original example of 1000 size_ts
with a single to_add that applies to all) it can really start to show
memory improvements - after all, you'd only be creating a single size_t
to_add, reading from the existing 1000 values, then freeing to_add.

On 6 Mar 2018 13:38, <jsaintmartin356@gmail.com> wrote:


got a partial answer to my own question, but it might interest some other
coders : it's looks not possible to know what will be an object at next
iteration in a const method, without copying it, but it is possible in a
const method, without creating another object (just a copy to an existing
one). const qualifier after a method that modifies static members static
members is valid, and I am using this. This aspect of C++ may not be known
enough :

  class Integer {
  public :
    Integer (size_t s) : val_ (s) {}
    ~Integer () {}
    Integer (const Integer& i) : val_ (i.val_) {}
    Integer& operator =3D (const Integer& i) {val_ =3D i.val_; return *this=
;}
    bool operator =3D=3D (const Integer& i) {return (val_ =3D=3D
i.val_?true:false);}
    bool operator !=3D (const Integer& i) {return !operator =3D=3D (i);}

    void write (std::ostream& os) const {
      os << val_;
    }
    void write_next (std::ostream& os) const {
      me_stat =3D *this;
      me_stat++;
      me_stat.write (os);
    }
    Integer& operator ++ (int) {
      val_++;
      return *this;
    }
  private :
    static Integer me_stat;
    size_t val_;
  };

  Integer Integer::me_stat (0);


  int main (int argc, char* argv []) {
    Integer i (7);
    std::cout << "i =3D=3D ";
    i.write (std::cout);
    std::cout << std::endl;
    std::cout << "i next =3D=3D ";
    i.write_next (std::cout);
    std::cout << std::endl;
    std::cout << "i again =3D=3D ";
    i.write (std::cout);
    std::cout << std::endl;
  }

results :
  i =3D=3D 7
  i next =3D=3D 8
  i again =3D=3D 7


On Saturday, March 3, 2018 at 10:16:25 AM UTC+1, Ga=C5=A1per A=C5=BEman wro=
te:

> Jerome,
>
>
> I'm sorry if I offended you by using emphatic (as opposed to graphic)
> language. I thought it would get the message of how unfortunate the
> situation I was outlining was. Instead, I achieved a fixation on a
> communication technique instead of the message, which was not my intentio=
n.
> I'd also like to avoid another one-liner storm that completely derailed t=
he
> discussion.
>
> I'd like to continue this discussion, so please, replace, in your mind, i=
f
> you don't mind, the word "suck" with "not ideal", and address my concerns
> on a substantive level, like I tried to address yours.
>
> In fact, I believe I suggested an alternative solution for your problem
> that avoids the type system issues that come with bifurcating the meaning
> of const, which has been *actually refused* several times, for the
> outlined reasons that I'm not the first to bring up (though perhaps in th=
is
> discussion, my elucidation of them was the most direct).
>
> The solution I suggested, if it was not obvious, is to, for classes that
> define a "const mutable" method, *define (as opposed to UB) what a
> const-declared object of that type is allowed to be. F*or such classes
> (and classes containing them), even const-declared objects cannot be put
> into ROM, which means that const-cast of *this* is not UB for them. That
> should address your implementation concerns without bifurcating the type
> system, unless I'm misunderstanding something and you *want* to provide
> both a *const * and a *pseudoconst* method on the same class, in which
> case, please elucidate why that would ever be useful, because I truly
> cannot think of an example.
>
>
> Ga=C5=A1per
>
>
>
> On Fri, Mar 2, 2018 at 9:47 PM, <jsaintm...@gmail.com> wrote:
>
>> Even if there are more words in French than in English, I believed it wa=
s
>> possible to male two sentences in English, without using "suck". I was
>> mistaken. Sorry
>>
>> On Friday, March 2, 2018 at 10:03:05 PM UTC+1, Jake Arkinstall wrote:
>>>
>>> There are plenty of more fitting four letter words, but their use would
>>> be frowned upon.
>>>
>>> Suck is perfectly fine. Criticising another person's choice of words is
>>> not. Don't push your luck.
>>>
>>> On 2 Mar 2018 20:51, <jsaintm...@gmail.com> wrote:
>>>
>>>> or is your vocabulary limited to "suck"
>>>>
>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposal...@isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-
>> de4f6ffbdfd4%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2=
194-473b-9bfc-de4f6ffbdfd4%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
> --
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.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/5e4668bb-1653-49ef-
a1bb-9a74081d1cab%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5e4668bb-1653=
-49ef-a1bb-9a74081d1cab%40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter=
>
..

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAC%2B0CCP2PwcsO2Roxr%3DuOEt_QPYH1ktZQcFgsYTdGWb=
bq3jHYg%40mail.gmail.com.

--001a1141d570dde09f0566bf3607
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>This isn&#39;t thread safe, so I&#39;d throw a mutex=
 in there. Also it is no different to just creating a new object when you c=
all the method, except that you&#39;re keeping a temporary object in memory=
 for the duration of the program. If your object is designed to be short-li=
ved, e.g. it utilises RAII, then keeping it alive for longer than anticipat=
ed might cause confusion; the lifetime is determined not by the object itse=
lf, but by the next object to replace it (or by the program terminating).</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">I still think the optimal=
 solution is usually going to be a view. This allows you to keep the underl=
ying object completely unchanged and prevents you from having to copy the i=
ntended object at all. You can also chain these views, storing the underlyi=
ng const reference each time, and successively adding the addition paramete=
r.</div><div dir=3D"auto"><br></div><div dir=3D"auto">class addition_view{<=
/div><div dir=3D"auto">public:</div><div dir=3D"auto">=C2=A0 =C2=A0 additio=
n_view(const Integer&amp; underlying, size_t to_add)</div><div dir=3D"auto"=
>=C2=A0 =C2=A0 :</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 underly=
ing(underlying),</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 to_add(=
to_add)</div><div dir=3D"auto">=C2=A0 =C2=A0 {}</div><div dir=3D"auto">=C2=
=A0 =C2=A0 addition_view(const addition_view&amp; other, size_t to_add)</di=
v><div dir=3D"auto">=C2=A0 =C2=A0 :</div><div dir=3D"auto">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 underlying(other.underlying),</div><div dir=3D"auto">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 to_add(other.to_add + to_add)</div><div dir=3D"auto">=
=C2=A0 =C2=A0 {}</div><div dir=3D"auto">=C2=A0 =C2=A0 void write(std::ostre=
am&amp; os) const{</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 os &l=
t;&lt; &quot;The number is &quot;</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0&lt;&lt; (underlying.value + to_add);</div><div dir=
=3D"auto">=C2=A0 =C2=A0 }</div><div dir=3D"auto">protected:</div><div dir=
=3D"auto">=C2=A0 =C2=A0 const Integer&amp; underlying;</div><div dir=3D"aut=
o">=C2=A0 =C2=A0 size_t to_add;</div><div dir=3D"auto">};</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">You can then make addition_view a friend =
class of Integer and utilise it whenever you want a const method that &quot=
;appears&quot; to modify the value. The benefit for a single size_t is mini=
mal, but when you&#39;re working with many values with fewer modifiers (e.g=
.. your original example of 1000 size_ts with a single to_add that applies t=
o all) it can really start to show memory improvements - after all, you&#39=
;d only be creating a single size_t to_add, reading from the existing 1000 =
values, then freeing to_add.</div><div dir=3D"auto"><div class=3D"gmail_ext=
ra" dir=3D"auto"><br><div class=3D"gmail_quote">On 6 Mar 2018 13:38,  &lt;<=
a href=3D"mailto:jsaintmartin356@gmail.com">jsaintmartin356@gmail.com</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><br>got a partial answer to my own question, but it might interest some ot=
her coders : it&#39;s looks not possible to know what will be an object at =
next iteration in a const method, without copying it, but it is possible in=
 a const method, without creating another object (just a copy to an existin=
g one). const qualifier after a method that modifies static members static =
members is valid, and I am using this. This aspect of C++ may not be known =
enough :<br><br>=C2=A0 class Integer {<br>=C2=A0 public :<br>=C2=A0=C2=A0=
=C2=A0 Integer (size_t s) : val_ (s) {}<br>=C2=A0 =C2=A0 ~Integer () {}<br>=
=C2=A0=C2=A0=C2=A0 Integer (const Integer&amp; i) : val_ (i.val_) {}<br>=C2=
=A0 =C2=A0 Integer&amp; operator =3D (const Integer&amp; i) {val_ =3D i.val=
_; return *this;}<br>=C2=A0=C2=A0=C2=A0 bool operator =3D=3D (const Integer=
&amp; i) {return (val_ =3D=3D i.val_?true:false);}<br>=C2=A0 =C2=A0 bool op=
erator !=3D (const Integer&amp; i) {return !operator =3D=3D (i);}<div class=
=3D"quoted-text"><br>=C2=A0=C2=A0=C2=A0 void write (std::ostream&amp; os) c=
onst {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 os &lt;&lt; val_;<br>=C2=A0 =C2=A0=
 }<br></div>=C2=A0=C2=A0=C2=A0 void write_next (std::ostream&amp; os) const=
 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 me_stat =3D *this;<br>=C2=A0=C2=A0 =C2=
=A0=C2=A0 me_stat++;<br>=C2=A0 =C2=A0 =C2=A0 me_stat.write (os);<br>=C2=A0 =
=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 Integer&amp; operator ++ (int) {<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 val_++;<br>=C2=A0=C2=A0 =C2=A0=C2=A0 return *this;=
<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0 private :<br>=C2=A0=C2=A0=C2=A0 static I=
nteger me_stat;<br>=C2=A0 =C2=A0 size_t val_;<br>=C2=A0 };<br><br>=C2=A0 In=
teger Integer::me_stat (0);<div class=3D"quoted-text"><br><br>=C2=A0 int ma=
in (int argc, char* argv []) {<br></div>=C2=A0=C2=A0=C2=A0 Integer i (7);<b=
r>=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;i =3D=3D &quot;;<br>=C2=A0 =C2=A0 =
i.write (std::cout);<br>=C2=A0 =C2=A0 std::cout &lt;&lt; std::endl;<br>=C2=
=A0 =C2=A0 std::cout &lt;&lt; &quot;i next =3D=3D &quot;;<br>=C2=A0=C2=A0=
=C2=A0 i.write_next (std::cout);<br>=C2=A0 =C2=A0 std::cout &lt;&lt; std::e=
ndl;<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;i again =3D=3D &quot;;<=
br>=C2=A0 =C2=A0 i.write (std::cout);<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&=
lt; std::endl;<br>=C2=A0 }<br><br>results :<br>=C2=A0 i =3D=3D 7<br>=C2=A0 =
i next =3D=3D 8<br>=C2=A0 i again =3D=3D 7<div class=3D"quoted-text"><br><b=
r>On Saturday, March 3, 2018 at 10:16:25 AM UTC+1, Ga=C5=A1per A=C5=BEman w=
rote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-tex=
t"><div dir=3D"ltr">Jerome,<div><br></div><div><br></div><div>I&#39;m sorry=
 if I offended you by using emphatic (as opposed to graphic) language. I th=
ought it would get the message of how unfortunate the situation I was outli=
ning was. Instead, I achieved a fixation on a communication technique inste=
ad of the message, which was not my intention. I&#39;d also like to avoid a=
nother one-liner storm that completely derailed the discussion.</div><div><=
br></div><div>I&#39;d like to continue this discussion, so please, replace,=
 in your mind, if you don&#39;t mind, the word &quot;suck&quot; with &quot;=
not ideal&quot;, and address my concerns on a substantive level, like I tri=
ed to address yours.</div><div><br></div><div>In fact, I believe I suggeste=
d an alternative solution for your problem that avoids the type system issu=
es that come with bifurcating the meaning of const, which has been <i>actua=
lly refused</i>=C2=A0several times, for the outlined reasons that I&#39;m n=
ot the first to bring up (though perhaps in this discussion, my elucidation=
 of them was the most direct).</div><div><br></div><div>The solution I sugg=
ested, if it was not obvious, is to,=C2=A0<span style=3D"color:rgb(34,34,34=
);font-family:arial,sans-serif;font-size:small;font-style:normal;font-weigh=
t:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)=
;float:none;display:inline">for classes that define a &quot;const mutable&q=
uot; method,=C2=A0</span><i>define (as opposed to UB) what a const-declared=
 object of that type is allowed to be. F</i>or such classes (and classes co=
ntaining them), even const-declared objects cannot be put into ROM, which m=
eans that const-cast of <i>this</i>=C2=A0is not UB for them. That should ad=
dress your implementation concerns without bifurcating the type system, unl=
ess I&#39;m misunderstanding something and you <i>want</i> to provide both =
a <i>const=C2=A0</i>=C2=A0and a <i>pseudoconst</i>=C2=A0method on the same =
class, in which case, please elucidate why that would ever be useful, becau=
se I truly cannot think of an example.</div><div><br></div><div><br></div><=
div>Ga=C5=A1per</div><div><br></div><div><br></div></div></div><div><br><di=
v class=3D"gmail_quote"><div class=3D"quoted-text">On Fri, Mar 2, 2018 at 9=
:47 PM,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jsaintm...@gmail.com</a>=
&gt;</span> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"qu=
oted-text"><div dir=3D"ltr">Even if there are more words in French than in =
English, I believed it was possible to male two sentences in English, witho=
ut using &quot;suck&quot;. I was mistaken. Sorry<span><br><br>On Friday, Ma=
rch 2, 2018 at 10:03:05 PM UTC+1, Jake Arkinstall wrote:</span><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"auto"><span><div>There are plenty o=
f more fitting four letter words, but their use would be frowned upon.</div=
><div dir=3D"auto"><br></div><div dir=3D"auto">Suck is perfectly fine. Crit=
icising another person&#39;s choice of words is not. Don&#39;t push your lu=
ck.</div></span><span><div dir=3D"auto"><div dir=3D"auto"><br><div class=3D=
"gmail_quote">On 2 Mar 2018 20:51,  &lt;<a rel=3D"nofollow">jsaintm...@gmai=
l.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">or is your vocabulary limited to &quot;suck&quot;</div>
</blockquote></div></div>
</div></span></div>
</blockquote></div></div><span><div class=3D"quoted-text">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><div class=3D"quoted-text">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/67e1c1c7-2194-473b-9bfc-<wbr>de4f6ffbdfd4%40isocpp.org</a>.<br=
>
</div></blockquote></div><br></div>
</blockquote></div><div class=3D"quoted-text">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5e4668bb-1653-49ef-a1bb-9a74081d1cab%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5e46=
68bb-1653-49ef-<wbr>a1bb-9a74081d1cab%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP2PwcsO2Roxr%3DuOEt_QPYH1ktZ=
QcFgsYTdGWbbq3jHYg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP2Pw=
csO2Roxr%3DuOEt_QPYH1ktZQcFgsYTdGWbbq3jHYg%40mail.gmail.com</a>.<br />

--001a1141d570dde09f0566bf3607--

.

------=_Part_18167_921073134.1520364142586
Content-Type: multipart/alternative;
 boundary="----=_Part_18168_1153184200.1520364142587"

------=_Part_18168_1153184200.1520364142587
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't care about Thread Safe Stuff. This is a sample example, to show=20
"how it's working". Feel free to add them. Who is RAII ?=20

On Tuesday, March 6, 2018 at 3:25:31 PM UTC+1, Jake Arkinstall wrote:
>
> This isn't thread safe, so I'd throw a mutex in there. Also it is no=20
> different to just creating a new object when you call the method, except=
=20
> that you're keeping a temporary object in memory for the duration of the=
=20
> program. If your object is designed to be short-lived, e.g. it utilises=
=20
> RAII, then keeping it alive for longer than anticipated might cause=20
> confusion; the lifetime is determined not by the object itself, but by th=
e=20
> next object to replace it (or by the program terminating).
>
> I still think the optimal solution is usually going to be a view. This=20
> allows you to keep the underlying object completely unchanged and prevent=
s=20
> you from having to copy the intended object at all. You can also chain=20
> these views, storing the underlying const reference each time, and=20
> successively adding the addition parameter.
>
> class addition_view{
> public:
>     addition_view(const Integer& underlying, size_t to_add)
>     :
>         underlying(underlying),
>         to_add(to_add)
>     {}
>     addition_view(const addition_view& other, size_t to_add)
>     :
>         underlying(other.underlying),
>         to_add(other.to_add + to_add)
>     {}
>     void write(std::ostream& os) const{
>         os << "The number is "
>            << (underlying.value + to_add);
>     }
> protected:
>     const Integer& underlying;
>     size_t to_add;
> };
>
> You can then make addition_view a friend class of Integer and utilise it=
=20
> whenever you want a const method that "appears" to modify the value. The=
=20
> benefit for a single size_t is minimal, but when you're working with many=
=20
> values with fewer modifiers (e.g. your original example of 1000 size_ts=
=20
> with a single to_add that applies to all) it can really start to show=20
> memory improvements - after all, you'd only be creating a single size_t=
=20
> to_add, reading from the existing 1000 values, then freeing to_add.
>
> On 6 Mar 2018 13:38, <jsaintm...@gmail.com <javascript:>> wrote:
>
>
> got a partial answer to my own question, but it might interest some other=
=20
> coders : it's looks not possible to know what will be an object at next=
=20
> iteration in a const method, without copying it, but it is possible in a=
=20
> const method, without creating another object (just a copy to an existing=
=20
> one). const qualifier after a method that modifies static members static=
=20
> members is valid, and I am using this. This aspect of C++ may not be know=
n=20
> enough :
>
>   class Integer {
>   public :
>     Integer (size_t s) : val_ (s) {}
>     ~Integer () {}
>     Integer (const Integer& i) : val_ (i.val_) {}
>     Integer& operator =3D (const Integer& i) {val_ =3D i.val_; return *th=
is;}
>     bool operator =3D=3D (const Integer& i) {return (val_ =3D=3D=20
> i.val_?true:false);}
>     bool operator !=3D (const Integer& i) {return !operator =3D=3D (i);}
>
>     void write (std::ostream& os) const {
>       os << val_;
>     }
>     void write_next (std::ostream& os) const {
>       me_stat =3D *this;
>       me_stat++;
>       me_stat.write (os);
>     }
>     Integer& operator ++ (int) {
>       val_++;
>       return *this;
>     }
>   private :
>     static Integer me_stat;
>     size_t val_;
>   };
>
>   Integer Integer::me_stat (0);
>
>
>   int main (int argc, char* argv []) {
>     Integer i (7);
>     std::cout << "i =3D=3D ";
>     i.write (std::cout);
>     std::cout << std::endl;
>     std::cout << "i next =3D=3D ";
>     i.write_next (std::cout);
>     std::cout << std::endl;
>     std::cout << "i again =3D=3D ";
>     i.write (std::cout);
>     std::cout << std::endl;
>   }
>
> results :
>   i =3D=3D 7
>   i next =3D=3D 8
>   i again =3D=3D 7
>
>
> On Saturday, March 3, 2018 at 10:16:25 AM UTC+1, Ga=C5=A1per A=C5=BEman w=
rote:
>
>> Jerome,
>>
>>
>> I'm sorry if I offended you by using emphatic (as opposed to graphic)=20
>> language. I thought it would get the message of how unfortunate the=20
>> situation I was outlining was. Instead, I achieved a fixation on a=20
>> communication technique instead of the message, which was not my intenti=
on.=20
>> I'd also like to avoid another one-liner storm that completely derailed =
the=20
>> discussion.
>>
>> I'd like to continue this discussion, so please, replace, in your mind,=
=20
>> if you don't mind, the word "suck" with "not ideal", and address my=20
>> concerns on a substantive level, like I tried to address yours.
>>
>> In fact, I believe I suggested an alternative solution for your problem=
=20
>> that avoids the type system issues that come with bifurcating the meanin=
g=20
>> of const, which has been *actually refused* several times, for the=20
>> outlined reasons that I'm not the first to bring up (though perhaps in t=
his=20
>> discussion, my elucidation of them was the most direct).
>>
>> The solution I suggested, if it was not obvious, is to, for classes that=
=20
>> define a "const mutable" method, *define (as opposed to UB) what a=20
>> const-declared object of that type is allowed to be. F*or such classes=
=20
>> (and classes containing them), even const-declared objects cannot be put=
=20
>> into ROM, which means that const-cast of *this* is not UB for them. That=
=20
>> should address your implementation concerns without bifurcating the type=
=20
>> system, unless I'm misunderstanding something and you *want* to provide=
=20
>> both a *const * and a *pseudoconst* method on the same class, in which=
=20
>> case, please elucidate why that would ever be useful, because I truly=20
>> cannot think of an example.
>>
>>
>> Ga=C5=A1per
>>
>>
>>
>> On Fri, Mar 2, 2018 at 9:47 PM, <jsaintm...@gmail.com> wrote:
>>
>>> Even if there are more words in French than in English, I believed it=
=20
>>> was possible to male two sentences in English, without using "suck". I =
was=20
>>> mistaken. Sorry
>>>
>>> On Friday, March 2, 2018 at 10:03:05 PM UTC+1, Jake Arkinstall wrote:
>>>>
>>>> There are plenty of more fitting four letter words, but their use woul=
d=20
>>>> be frowned upon.
>>>>
>>>> Suck is perfectly fine. Criticising another person's choice of words i=
s=20
>>>> not. Don't push your luck.
>>>>
>>>> On 2 Mar 2018 20:51, <jsaintm...@gmail.com> wrote:
>>>>
>>>>> or is your vocabulary limited to "suck"
>>>>>
>>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2=
194-473b-9bfc-de4f6ffbdfd4%40isocpp.org=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-=
2194-473b-9bfc-de4f6ffbdfd4%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5e4668bb-165=
3-49ef-a1bb-9a74081d1cab%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5e4668bb-16=
53-49ef-a1bb-9a74081d1cab%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/40fc303c-a40e-493d-a62a-2d030e0a4d57%40isocpp.or=
g.

------=_Part_18168_1153184200.1520364142587
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t care about Thread Safe Stuff. This is a sample=
 example, to show &quot;how it&#39;s working&quot;. Feel free to add them. =
Who is RAII ? <br><br>On Tuesday, March 6, 2018 at 3:25:31 PM UTC+1, Jake A=
rkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"au=
to"><div>This isn&#39;t thread safe, so I&#39;d throw a mutex in there. Als=
o it is no different to just creating a new object when you call the method=
, except that you&#39;re keeping a temporary object in memory for the durat=
ion of the program. If your object is designed to be short-lived, e.g. it u=
tilises RAII, then keeping it alive for longer than anticipated might cause=
 confusion; the lifetime is determined not by the object itself, but by the=
 next object to replace it (or by the program terminating).</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I still think the optimal solution is=
 usually going to be a view. This allows you to keep the underlying object =
completely unchanged and prevents you from having to copy the intended obje=
ct at all. You can also chain these views, storing the underlying const ref=
erence each time, and successively adding the addition parameter.</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">class addition_view{</div><div di=
r=3D"auto">public:</div><div dir=3D"auto">=C2=A0 =C2=A0 addition_view(const=
 Integer&amp; underlying, size_t to_add)</div><div dir=3D"auto">=C2=A0 =C2=
=A0 :</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 underlying(underly=
ing),</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 to_add(to_add)</di=
v><div dir=3D"auto">=C2=A0 =C2=A0 {}</div><div dir=3D"auto">=C2=A0 =C2=A0 a=
ddition_view(const addition_view&amp; other, size_t to_add)</div><div dir=
=3D"auto">=C2=A0 =C2=A0 :</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 underlying(other.underlying),</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 to_add(other.to_add + to_add)</div><div dir=3D"auto">=C2=A0 =C2=
=A0 {}</div><div dir=3D"auto">=C2=A0 =C2=A0 void write(std::ostream&amp; os=
) const{</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 os &lt;&lt; &qu=
ot;The number is &quot;</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0&lt;&lt; (underlying.value + to_add);</div><div dir=3D"auto">=
=C2=A0 =C2=A0 }</div><div dir=3D"auto">protected:</div><div dir=3D"auto">=
=C2=A0 =C2=A0 const Integer&amp; underlying;</div><div dir=3D"auto">=C2=A0 =
=C2=A0 size_t to_add;</div><div dir=3D"auto">};</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">You can then make addition_view a friend class of I=
nteger and utilise it whenever you want a const method that &quot;appears&q=
uot; to modify the value. The benefit for a single size_t is minimal, but w=
hen you&#39;re working with many values with fewer modifiers (e.g. your ori=
ginal example of 1000 size_ts with a single to_add that applies to all) it =
can really start to show memory improvements - after all, you&#39;d only be=
 creating a single size_t to_add, reading from the existing 1000 values, th=
en freeing to_add.</div><div dir=3D"auto"><div dir=3D"auto"><br><div class=
=3D"gmail_quote">On 6 Mar 2018 13:38,  &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"TJk6w-8RAAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">jsaintm...@gmail.com</a>&gt; wrote:=
<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>got a partial answer=
 to my own question, but it might interest some other coders : it&#39;s loo=
ks not possible to know what will be an object at next iteration in a const=
 method, without copying it, but it is possible in a const method, without =
creating another object (just a copy to an existing one). const qualifier a=
fter a method that modifies static members static members is valid, and I a=
m using this. This aspect of C++ may not be known enough :<br><br>=C2=A0 cl=
ass Integer {<br>=C2=A0 public :<br>=C2=A0=C2=A0=C2=A0 Integer (size_t s) :=
 val_ (s) {}<br>=C2=A0 =C2=A0 ~Integer () {}<br>=C2=A0=C2=A0=C2=A0 Integer =
(const Integer&amp; i) : val_ (i.val_) {}<br>=C2=A0 =C2=A0 Integer&amp; ope=
rator =3D (const Integer&amp; i) {val_ =3D i.val_; return *this;}<br>=C2=A0=
=C2=A0=C2=A0 bool operator =3D=3D (const Integer&amp; i) {return (val_ =3D=
=3D i.val_?true:false);}<br>=C2=A0 =C2=A0 bool operator !=3D (const Integer=
&amp; i) {return !operator =3D=3D (i);}<div><br>=C2=A0=C2=A0=C2=A0 void wri=
te (std::ostream&amp; os) const {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 os &lt;=
&lt; val_;<br>=C2=A0 =C2=A0 }<br></div>=C2=A0=C2=A0=C2=A0 void write_next (=
std::ostream&amp; os) const {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 me_stat =3D=
 *this;<br>=C2=A0=C2=A0 =C2=A0=C2=A0 me_stat++;<br>=C2=A0 =C2=A0 =C2=A0 me_=
stat.write (os);<br>=C2=A0 =C2=A0 }<br>=C2=A0=C2=A0=C2=A0 Integer&amp; oper=
ator ++ (int) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 val_++;<br>=C2=A0=C2=A0 =
=C2=A0=C2=A0 return *this;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0 private :<br>=
=C2=A0=C2=A0=C2=A0 static Integer me_stat;<br>=C2=A0 =C2=A0 size_t val_;<br=
>=C2=A0 };<br><br>=C2=A0 Integer Integer::me_stat (0);<div><br><br>=C2=A0 i=
nt main (int argc, char* argv []) {<br></div>=C2=A0=C2=A0=C2=A0 Integer i (=
7);<br>=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;i =3D=3D &quot;;<br>=C2=A0 =
=C2=A0 i.write (std::cout);<br>=C2=A0 =C2=A0 std::cout &lt;&lt; std::endl;<=
br>=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;i next =3D=3D &quot;;<br>=C2=A0=
=C2=A0=C2=A0 i.write_next (std::cout);<br>=C2=A0 =C2=A0 std::cout &lt;&lt; =
std::endl;<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;i again =3D=3D &q=
uot;;<br>=C2=A0 =C2=A0 i.write (std::cout);<br>=C2=A0=C2=A0=C2=A0 std::cout=
 &lt;&lt; std::endl;<br>=C2=A0 }<br><br>results :<br>=C2=A0 i =3D=3D 7<br>=
=C2=A0 i next =3D=3D 8<br>=C2=A0 i again =3D=3D 7<div><br><br>On Saturday, =
March 3, 2018 at 10:16:25 AM UTC+1, Ga=C5=A1per A=C5=BEman wrote:</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div><div dir=3D"ltr">Jerome,<div><br><=
/div><div><br></div><div>I&#39;m sorry if I offended you by using emphatic =
(as opposed to graphic) language. I thought it would get the message of how=
 unfortunate the situation I was outlining was. Instead, I achieved a fixat=
ion on a communication technique instead of the message, which was not my i=
ntention. I&#39;d also like to avoid another one-liner storm that completel=
y derailed the discussion.</div><div><br></div><div>I&#39;d like to continu=
e this discussion, so please, replace, in your mind, if you don&#39;t mind,=
 the word &quot;suck&quot; with &quot;not ideal&quot;, and address my conce=
rns on a substantive level, like I tried to address yours.</div><div><br></=
div><div>In fact, I believe I suggested an alternative solution for your pr=
oblem that avoids the type system issues that come with bifurcating the mea=
ning of const, which has been <i>actually refused</i>=C2=A0several times, f=
or the outlined reasons that I&#39;m not the first to bring up (though perh=
aps in this discussion, my elucidation of them was the most direct).</div><=
div><br></div><div>The solution I suggested, if it was not obvious, is to,=
=C2=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-=
size:small;font-style:normal;font-weight:400;letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;background-color:rgb(255,255,255);float:none;display:inline">for clas=
ses that define a &quot;const mutable&quot; method,=C2=A0</span><i>define (=
as opposed to UB) what a const-declared object of that type is allowed to b=
e. F</i>or such classes (and classes containing them), even const-declared =
objects cannot be put into ROM, which means that const-cast of <i>this</i>=
=C2=A0is not UB for them. That should address your implementation concerns =
without bifurcating the type system, unless I&#39;m misunderstanding someth=
ing and you <i>want</i> to provide both a <i>const=C2=A0</i>=C2=A0and a <i>=
pseudoconst</i>=C2=A0method on the same class, in which case, please elucid=
ate why that would ever be useful, because I truly cannot think of an examp=
le.</div><div><br></div><div><br></div><div>Ga=C5=A1per</div><div><br></div=
><div><br></div></div></div><div><br><div class=3D"gmail_quote"><div>On Fri=
, Mar 2, 2018 at 9:47 PM,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jsaint=
m...@gmail.com</a>&gt;</span> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div><div dir=3D"ltr">Even if there are more words in French than in Engl=
ish, I believed it was possible to male two sentences in English, without u=
sing &quot;suck&quot;. I was mistaken. Sorry<span><br><br>On Friday, March =
2, 2018 at 10:03:05 PM UTC+1, Jake Arkinstall wrote:</span><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"auto"><span><div>There are plenty of mo=
re fitting four letter words, but their use would be frowned upon.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Suck is perfectly fine. Criticis=
ing another person&#39;s choice of words is not. Don&#39;t push your luck.<=
/div></span><span><div dir=3D"auto"><div dir=3D"auto"><br><div class=3D"gma=
il_quote">On 2 Mar 2018 20:51,  &lt;<a rel=3D"nofollow">jsaintm...@gmail.co=
m</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">or is your vocabulary limited to &quot;suck&quot;</div>
</blockquote></div></div>
</div></span></div>
</blockquote></div></div><span><div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/67e1c1c7-2194-473b-9bfc-de4f6ffbdfd4%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/67e1c1c7-2194-473b-<wbr>9bfc-=
de4f6ffbdfd4%40isocpp.org</a><wbr>.<br>
</div></blockquote></div><br></div>
</blockquote></div><div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
TJk6w-8RAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"TJk6w-8RAAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5e4668bb-1653-49ef-a1bb-9a74081d1cab%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/5e4668bb-1653-49ef-a1bb-9a74081d1cab%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/5e4668bb-1653-49ef-a1bb-9a74081d1cab%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5e4668bb-1653-49ef-<wbr>a1bb-=
9a74081d1cab%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/40fc303c-a40e-493d-a62a-2d030e0a4d57%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40fc303c-a40e-493d-a62a-2d030e0a4d57=
%40isocpp.org</a>.<br />

------=_Part_18168_1153184200.1520364142587--

------=_Part_18167_921073134.1520364142586--

.

--001a114df6220a0c130566c397dd
Content-Type: text/plain; charset="UTF-8"

On 6 Mar 2018 19:22, <jsaintmartin356@gmail.com> wrote:

I don't care about Thread Safe Stuff.


You want to submit a proposal to people who do. I recommend you start
caring about thread safety.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOcbM8QKqrHKFvTZZJ0n5gL9WVpJ%3D-TOC8YnfLCDiRFaw%40mail.gmail.com.

--001a114df6220a0c130566c397dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 6 Mar 2018 19:22,  &lt;<a href=3D"mailto:jsaintmartin356@gmail.com">js=
aintmartin356@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote =
class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">I don&#39;t care about Thread Safe Stuff.</di=
v></blockquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">You want to submit a proposal to people who do. I recommend you start c=
aring about thread safety.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOcbM8QKqrHKFvTZZJ0n5gL9WVpJ%=
3D-TOC8YnfLCDiRFaw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOcbM=
8QKqrHKFvTZZJ0n5gL9WVpJ%3D-TOC8YnfLCDiRFaw%40mail.gmail.com</a>.<br />

--001a114df6220a0c130566c397dd--

.

------=_Part_10619_1716645883.1526053568259
Content-Type: multipart/alternative;
 boundary="----=_Part_10620_1998300706.1526053568260"

------=_Part_10620_1998300706.1526053568260
Content-Type: text/plain; charset="UTF-8"



On Tuesday, March 6, 2018 at 8:38:44 PM UTC+1, Jake Arkinstall wrote:
>
> On 6 Mar 2018 19:22, <jsaintm...@gmail.com <javascript:>> wrote:
>
> I don't care about Thread Safe Stuff.
>
>
> You want to submit a proposal to people who do. I recommend you start
> caring about thread safety.
>

okie : added throw and a mutex

  #include <mutex>

  class Integer {
  public :
    static std::mutex le_mutex;
    Integer (size_t s) throw (): val_ (s)  {}
    ~Integer () {}
    Integer (const Integer& i) throw () : val_ (i.val_)  {}
    Integer& operator = (const Integer& i) throw () {val_ = i.val_; return
*this;}
    bool operator == (const Integer& i) throw () {return (val_ ==
i.val_?true:false);}
    bool operator != (const Integer& i) throw () {return !operator == (i);}

    void write (std::ostream& os) const throw () {
      os << val_;
    }
    void write_next (std::ostream& os) const throw () {
      le_mutex.lock ();
      me_stat = *this;
      me_stat++;
      me_stat.write (os);
      le_mutex.unlock ();
    }
    Integer& operator ++ (int) throw () {
      val_++;
      return *this;
    }
  private :
    static Integer me_stat;
    size_t val_;
  };

  std::mutex Integer::le_mutex;
  Integer Integer::me_stat (0);


  int main (int argc, char* argv []) {
    Integer i (7);
    std::cout << "i == ";
    i.write (std::cout);
    std::cout << std::endl;
    std::cout << "i next == ";
    i.write_next (std::cout);
    std::cout << std::endl;
    std::cout << "i again == ";
    i.write (std::cout);
    std::cout << std::endl;
  }


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b9bb4cc-2cd9-4d27-a2b5-21692bdb333e%40isocpp.org.

------=_Part_10620_1998300706.1526053568260
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, March 6, 2018 at 8:38:44 PM UTC+1, Jak=
e Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"auto"><div><div><div class=3D"gmail_quote">On 6 Mar 2018 19:22,  &lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"uiiPZ77CAwAJ"=
 rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jsaintm...=
@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>I don&#39;t care about Thread Safe Stuff.</div></blockquote></div></div></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">You want to submit a prop=
osal to people who do. I recommend you start caring about thread safety.</d=
iv></div></blockquote><div><br>okie : added throw and a mutex<br><br>=C2=A0=
 #include &lt;mutex&gt;<br><br>=C2=A0 class Integer {<br>=C2=A0 public :<br=
>=C2=A0=C2=A0=C2=A0 static std::mutex le_mutex;<br>=C2=A0=C2=A0=C2=A0 Integ=
er (size_t s) throw (): val_ (s)=C2=A0 {}<br>=C2=A0=C2=A0=C2=A0 ~Integer ()=
 {}<br>=C2=A0=C2=A0=C2=A0 Integer (const Integer&amp; i) throw () : val_ (i=
..val_)=C2=A0 {}<br>=C2=A0=C2=A0=C2=A0 Integer&amp; operator =3D (const Inte=
ger&amp; i) throw () {val_ =3D i.val_; return *this;}<br>=C2=A0=C2=A0=C2=A0=
 bool operator =3D=3D (const Integer&amp; i) throw () {return (val_ =3D=3D =
i.val_?true:false);}<br>=C2=A0=C2=A0=C2=A0 bool operator !=3D (const Intege=
r&amp; i) throw () {return !operator =3D=3D (i);}<br><br>=C2=A0=C2=A0=C2=A0=
 void write (std::ostream&amp; os) const throw () {<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 os &lt;&lt; val_;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=
=A0 void write_next (std::ostream&amp; os) const throw () {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 le_mutex.lock ();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 me_s=
tat =3D *this;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 me_stat++;<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 me_stat.write (os);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 le=
_mutex.unlock ();<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 Integer&amp=
; operator ++ (int) throw () {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 val_++;<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return *this;<br>=C2=A0=C2=A0=C2=A0 }<br>=
=C2=A0 private :<br>=C2=A0=C2=A0=C2=A0 static Integer me_stat;<br>=C2=A0=C2=
=A0=C2=A0 size_t val_;<br>=C2=A0 };<br><br>=C2=A0 std::mutex Integer::le_mu=
tex;<br>=C2=A0 Integer Integer::me_stat (0);<br><br><br>=C2=A0 int main (in=
t argc, char* argv []) {<br>=C2=A0=C2=A0=C2=A0 Integer i (7);<br>=C2=A0=C2=
=A0=C2=A0 std::cout &lt;&lt; &quot;i =3D=3D &quot;;<br>=C2=A0=C2=A0=C2=A0 i=
..write (std::cout);<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; std::endl;<br>=
=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;i next =3D=3D &quot;;<br>=C2=A0=
=C2=A0=C2=A0 i.write_next (std::cout);<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;=
&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;i again =3D=
=3D &quot;;<br>=C2=A0=C2=A0=C2=A0 i.write (std::cout);<br>=C2=A0=C2=A0=C2=
=A0 std::cout &lt;&lt; std::endl;<br>=C2=A0 }<br>=C2=A0<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2b9bb4cc-2cd9-4d27-a2b5-21692bdb333e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b9bb4cc-2cd9-4d27-a2b5-21692bdb333e=
%40isocpp.org</a>.<br />

------=_Part_10620_1998300706.1526053568260--

------=_Part_10619_1716645883.1526053568259--

.

------=_Part_111976_1704483942.1528798137172
Content-Type: multipart/alternative;
 boundary="----=_Part_111977_1499486414.1528798137172"

------=_Part_111977_1499486414.1528798137172
Content-Type: text/plain; charset="UTF-8"

As far as I know, you cant find an iterator in a map with hint method, but
it is possible to insert a pair with a hint (faster).
With pseudo consness, you may insert with hint a pair in a map to find an
iterator, return that iterator if it was inserted or an iterator to the end
of the map. Map find (ihint) pseudocont :

std::map<size_t, size_t>::iterator find (std::map<size_t, size_t>& m,
std::map<size_t, size_t>::iterator& ihint, size_t s)  /*pseudo const*/ {
  std::pair<size_t, size_t> p (s, (size_t) -1);
  std::map<size_t, size_t>::iterator i (m.begin ());
  i = m.insert (ihint, p);
  if (i->second == (size_t) -1) {
    m.erase (i);
    i = m.end ();
  }
  return i;
}

int main (int argc, char* argv []) {
  std::pair<size_t, size_t> tmp [5] = {
    std::pair<size_t, size_t> (2, 5),
    std::pair<size_t, size_t> (3, 4),
    std::pair<size_t, size_t> (5, 2),
    std::pair<size_t, size_t> (8, 3),
    std::pair<size_t, size_t> (9, 7)
  };
  std::map<size_t, size_t> m;
  m.insert ((std::pair<size_t, size_t>*) tmp, (std::pair<size_t, size_t>*)
&tmp [5]);
  std::cout << "m == " << std::endl;
  std::for_each (m.begin (), m.end (), [] (const std::pair<size_t, size_t>&
p) {
    std::cout << p.first << "->" << p.second << std::endl;
  });
  {
    std::cout << "finding 5..." << std::endl;
    std::map<size_t, size_t>::iterator ihint (m.find (5)), i (m.begin ());
    i = find (m, ihint, 5);
    std::cout << "5 ";
    if (i == m.end ()) std::cout << "not in map" << std::endl;
    else std::cout << "i in map :" << i->first << "->" << i->second <<
std::endl;
  }
  {
    std::cout << "finding 6..." << std::endl;
    std::map<size_t, size_t>::iterator ihint (m.find (5)), i (m.begin ());
    i = find (m, ihint, 6);
    std::cout << "6 ";
    if (i == m.end ()) std::cout << "not in map" << std::endl;
    else std::cout << "i in map :" << i->first << "->" << i->second <<
std::endl;
  }

  return 0;
}

and the results :

m ==
2->5
3->4
5->2
8->3
9->7
finding 5...
5 i in map :5->2
finding 6...
6 not in map

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86c72707-d505-4413-b086-5f8e3b62d89a%40isocpp.org.

------=_Part_111977_1499486414.1528798137172
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As far as I know, you cant find an iterator in a map with =
hint method, but it is possible to insert a pair with a hint (faster).<br>W=
ith pseudo consness, you may insert with hint a pair in a map to find an it=
erator, return that iterator if it was inserted or an iterator to the end o=
f the map. Map find (ihint) pseudocont :<br><br>std::map&lt;size_t, size_t&=
gt;::iterator find (std::map&lt;size_t, size_t&gt;&amp; m, std::map&lt;size=
_t, size_t&gt;::iterator&amp; ihint, size_t s)=C2=A0 /*pseudo const*/ {<br>=
=C2=A0 std::pair&lt;size_t, size_t&gt; p (s, (size_t) -1);<br>=C2=A0 std::m=
ap&lt;size_t, size_t&gt;::iterator i (m.begin ());<br>=C2=A0 i =3D m.insert=
 (ihint, p);<br>=C2=A0 if (i-&gt;second =3D=3D (size_t) -1) {<br>=C2=A0=C2=
=A0=C2=A0 m.erase (i);<br>=C2=A0=C2=A0=C2=A0 i =3D m.end ();<br>=C2=A0 }<br=
>=C2=A0 return i;<br>}<br><br>int main (int argc, char* argv []) {<br>=C2=
=A0 std::pair&lt;size_t, size_t&gt; tmp [5] =3D {<br>=C2=A0=C2=A0=C2=A0 std=
::pair&lt;size_t, size_t&gt; (2, 5),<br>=C2=A0=C2=A0=C2=A0 std::pair&lt;siz=
e_t, size_t&gt; (3, 4),<br>=C2=A0=C2=A0=C2=A0 std::pair&lt;size_t, size_t&g=
t; (5, 2),<br>=C2=A0=C2=A0=C2=A0 std::pair&lt;size_t, size_t&gt; (8, 3),<br=
>=C2=A0=C2=A0=C2=A0 std::pair&lt;size_t, size_t&gt; (9, 7)<br>=C2=A0 };<br>=
=C2=A0 std::map&lt;size_t, size_t&gt; m;<br>=C2=A0 m.insert ((std::pair&lt;=
size_t, size_t&gt;*) tmp, (std::pair&lt;size_t, size_t&gt;*) &amp;tmp [5]);=
<br>=C2=A0 std::cout &lt;&lt; &quot;m =3D=3D &quot; &lt;&lt; std::endl;<br>=
=C2=A0 std::for_each (m.begin (), m.end (), [] (const std::pair&lt;size_t, =
size_t&gt;&amp; p) {<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; p.first &lt;&=
lt; &quot;-&gt;&quot; &lt;&lt; p.second &lt;&lt; std::endl;<br>=C2=A0 });<b=
r>=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;finding 5...&quot=
; &lt;&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0 std::map&lt;size_t, size_t&gt;:=
:iterator ihint (m.find (5)), i (m.begin ());<br>=C2=A0=C2=A0=C2=A0 i =3D f=
ind (m, ihint, 5);<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;5 &quot;;=
<br>=C2=A0=C2=A0=C2=A0 if (i =3D=3D m.end ()) std::cout &lt;&lt; &quot;not =
in map&quot; &lt;&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0 else std::cout &lt;&=
lt; &quot;i in map :&quot; &lt;&lt; i-&gt;first &lt;&lt; &quot;-&gt;&quot; =
&lt;&lt; i-&gt;second &lt;&lt; std::endl;<br>=C2=A0 }<br>=C2=A0 {<br>=C2=A0=
=C2=A0=C2=A0 std::cout &lt;&lt; &quot;finding 6...&quot; &lt;&lt; std::endl=
;<br>=C2=A0=C2=A0=C2=A0 std::map&lt;size_t, size_t&gt;::iterator ihint (m.f=
ind (5)), i (m.begin ());<br>=C2=A0=C2=A0=C2=A0 i =3D find (m, ihint, 6);<b=
r>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;6 &quot;;<br>=C2=A0=C2=A0=C2=
=A0 if (i =3D=3D m.end ()) std::cout &lt;&lt; &quot;not in map&quot; &lt;&l=
t; std::endl;<br>=C2=A0=C2=A0=C2=A0 else std::cout &lt;&lt; &quot;i in map =
:&quot; &lt;&lt; i-&gt;first &lt;&lt; &quot;-&gt;&quot; &lt;&lt; i-&gt;seco=
nd &lt;&lt; std::endl;<br>=C2=A0 }<br><br>=C2=A0 return 0;<br>}<br><br>and =
the results :<br><br>m =3D=3D <br>2-&gt;5<br>3-&gt;4<br>5-&gt;2<br>8-&gt;3<=
br>9-&gt;7<br>finding 5...<br>5 i in map :5-&gt;2<br>finding 6...<br>6 not =
in map<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/86c72707-d505-4413-b086-5f8e3b62d89a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/86c72707-d505-4413-b086-5f8e3b62d89a=
%40isocpp.org</a>.<br />

------=_Part_111977_1499486414.1528798137172--

------=_Part_111976_1704483942.1528798137172--

.