------=_Part_3997_944510884.1532026840732
Content-Type: multipart/alternative;
 boundary="----=_Part_3998_930403800.1532026840732"

------=_Part_3998_930403800.1532026840732
Content-Type: text/plain; charset="UTF-8"

Hello,
I was reading "out_ptr - a scalable output pointer abstraction" P1132R0
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1132r0.html>
and there, there is referenced to Intrusive Smart Pointer
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html>
proposal from two years back.

Does anyone know what happed to that proposal?

About Copy On Write - is there (was there) any proposal for it?
Does CoW has some bad reputation? Did miracles for Qt, honestly - for some
things it is Just Right.


In any case Intrusive Smart Pointer + polymorphic_value + some more work
and we should be able to come up with something pretty easy to work with on
the user side.

--
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/c407f327-d2ea-4024-8b96-a2f47bae7bbc%40isocpp.org.

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

<div dir=3D"ltr"><div>Hello,</div><div>I was reading &quot;out_ptr - a scal=
able output pointer abstraction&quot; <a href=3D"http://www.open-std.org/JT=
C1/SC22/WG21/docs/papers/2018/p1132r0.html">P1132R0</a><br></div><div>and t=
here, there is referenced to <a href=3D"http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2016/p0468r0.html">Intrusive Smart Pointer</a> proposal fro=
m two years back.</div><div><br></div><div>Does anyone know what happed to =
that proposal?</div><div><br></div><div>About Copy On Write - is there (was=
 there) any proposal for it?=C2=A0<br></div><div>Does CoW has some bad repu=
tation? Did miracles for Qt, honestly - for some things it is Just Right.=
=C2=A0</div><div><br></div><div><br></div><div>In any case=C2=A0Intrusive S=
mart Pointer + polymorphic_value + some more work and we should be able to =
come up with something pretty easy to work with on the user side.</div><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/c407f327-d2ea-4024-8b96-a2f47bae7bbc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c407f327-d2ea-4024-8b96-a2f47bae7bbc=
%40isocpp.org</a>.<br />

------=_Part_3998_930403800.1532026840732--

------=_Part_3997_944510884.1532026840732--

.

On 2018-07-19 15:00, mihailnajdenov@gmail.com wrote:
> I was reading "out_ptr - a scalable output pointer abstraction" P1132R0
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1132r0.html>
> and there, there is referenced to Intrusive Smart Pointer
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html>
> proposal from two years back.
>
> Does anyone know what happed to that proposal?
>
> About Copy On Write - is there (was there) any proposal for it?
> Does CoW has some bad reputation? Did miracles for Qt, honestly - for some
> things it is Just Right.

CoW is very much "out of vogue". Various folk these days claim that the
cost of an atomic pointer increment is extremely high (which is mostly
true) while the cost of making deep copies of things is much lower than
it used to be, if indeed it was ever high to begin with.

While I'm sure there is truth in that when dealing with *small* data
structures (i.e. on the order of a few hundred bytes), I'm not convinced
it's true for complicated structures that are several KiB or even MiB.
Nevertheless, those folks that dislike CoW are in the ascendancy right
now...

--
Matthew

--
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/783888bc-c4c6-71c5-de50-5b522a53e63c%40gmail.com.

.

On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
> CoW is very much "out of vogue". Various folk these days claim that the
> cost of an atomic pointer increment is extremely high (which is mostly
> true) while the cost of making deep copies of things is much lower than
> it used to be, if indeed it was ever high to begin with.

The problem was when you compared the two. For example, a function that
returns a container by value was forced to make a copy before C++11, then
destroy the original. The pair of atomic operation is usually cheaper than the
memory allocation alone, not even counting the actual element copy.

But since C++11 and move semantics, the return by value uses the move
constructor of the type in question and those can be faster than the pair of
atomics. Then again, CoW containers also get move constructors and then are
just as efficient.

The problem for non-CoW is that all programmers are not created equal. There
are quite a few who do not write efficient C++ code and often trip into
causing copies of containers. The use of CoW allows the container not to deep-
copy unless there's a need to.

On the other hand, the other problem for CoW is the unexpected memory
allocation: any non-const function can cause the shared container to stop
sharing, which means all non-const operations (including operator[]) can
potentially throw. Now, Qt doesn't care about exceptions, so this isn't a
problem, but in terms of code expansion and timing consistency, it can be
surprising.

Finally, there are some long-standing unsolvable defects with CoW: what
happens if you obtain a reference to the contents of such a container and
*then* share it again? This happens every now and again for Qt containers and
there's nothing we can do. We just have to teach people not to do that. For
Qt 6, I'd like to have some API to make it easier to write code that avoids
this.

PS: I am in favour of CoW and will likely keep QString, QByteArray and QVector
CoW in Qt 6. QLinkedList, QMap and QHash will likely be reimplemented in terms
of std::list, std::map and std::unordered_map, so they'll likely lose their
CoW.

PPS: QHash requires studying how to make std::unordered_map use salted hashes
or a security study concluding it's acceptable to lose that.

--
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/5919637.gWUId7SRl9%40tjmaciei-mobl1.

.

------=_Part_4878_1561936272.1532056637536
Content-Type: multipart/alternative;
 boundary="----=_Part_4879_1476346680.1532056637536"

------=_Part_4879_1476346680.1532056637536
Content-Type: text/plain; charset="UTF-8"

On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>
> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
> > CoW is very much "out of vogue". Various folk these days claim that the
> > cost of an atomic pointer increment is extremely high (which is mostly
> > true) while the cost of making deep copies of things is much lower than
> > it used to be, if indeed it was ever high to begin with.
>
> The problem was when you compared the two. For example, a function that
> returns a container by value was forced to make a copy before C++11, then
> destroy the original. The pair of atomic operation is usually cheaper than
> the
> memory allocation alone, not even counting the actual element copy.
>
> But since C++11 and move semantics, the return by value uses the move
> constructor of the type in question and those can be faster than the pair
> of
> atomics. Then again, CoW containers also get move constructors and then
> are
> just as efficient.
>
> The problem for non-CoW is that all programmers are not created equal.
> There
> are quite a few who do not write efficient C++ code and often trip into
> causing copies of containers. The use of CoW allows the container not to
> deep-
> copy unless there's a need to.
>
> On the other hand, the other problem for CoW is the unexpected memory
> allocation: any non-const function can cause the shared container to stop
> sharing, which means all non-const operations (including operator[]) can
> potentially throw. Now, Qt doesn't care about exceptions, so this isn't a
> problem, but in terms of code expansion and timing consistency, it can be
> surprising.
>

Throwing isn't necessarily the biggest issue with regard to CoW's
allocations. Unexpected memory allocation is basically unacceptable if you
want to have some reasonable guarantee of an APIs latency. SG14 is debating
adding insertion functions to `vector` that *can't* allocate memory. This
would allow users to be able to have APIs with static guarantees that
"unexpected memory allocation" will never occur.

From a low-latency perspective, CoW is a *bad* idea.

--
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/464a45af-deeb-4d78-ae6a-8d1b0df32c02%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, 19 Ju=
ly 2018 13:04:43 PDT Matthew Woehlke wrote:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</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/464a45af-deeb-4d78-ae6a-8d1b0df32c02%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/464a45af-deeb-4d78-ae6a-8d1b0df32c02=
%40isocpp.org</a>.<br />

------=_Part_4879_1476346680.1532056637536--

------=_Part_4878_1561936272.1532056637536--

.

On Thursday, 19 July 2018 20:17:17 PDT Nicol Bolas wrote:
> Throwing isn't necessarily the biggest issue with regard to CoW's
> allocations. Unexpected memory allocation is basically unacceptable if you
> want to have some reasonable guarantee of an APIs latency. SG14 is debating
> adding insertion functions to `vector` that *can't* allocate memory. This
> would allow users to be able to have APIs with static guarantees that
> "unexpected memory allocation" will never occur.
>
> From a low-latency perspective, CoW is a *bad* idea.

All you need to do is ensure that the share count is 1 before you start your
operations. There's no CoW if it's not shared.

--
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/1673290.38ALar1JvE%40tjmaciei-mobl1.

.

------=_Part_4859_628512448.1532060343132
Content-Type: multipart/alternative;
 boundary="----=_Part_4860_126447602.1532060343132"

------=_Part_4860_126447602.1532060343132
Content-Type: text/plain; charset="UTF-8"

On Thursday, July 19, 2018 at 11:38:20 PM UTC-4, Thiago Macieira wrote:
>
> On Thursday, 19 July 2018 20:17:17 PDT Nicol Bolas wrote:
> > Throwing isn't necessarily the biggest issue with regard to CoW's
> > allocations. Unexpected memory allocation is basically unacceptable if
> you
> > want to have some reasonable guarantee of an APIs latency. SG14 is
> debating
> > adding insertion functions to `vector` that *can't* allocate memory.
> This
> > would allow users to be able to have APIs with static guarantees that
> > "unexpected memory allocation" will never occur.
> >
> > From a low-latency perspective, CoW is a *bad* idea.
>
> All you need to do is ensure that the share count is 1 before you start
> your
> operations. There's no CoW if it's not shared.
>

And all you need to do to use `vector::push_back` safely is ensure that it
has sufficient size before you start your operations. And yet, here we are:
trying to add "try_push_back" and the like to `vector`. And it's not just
for `bad_alloc` throwing. Indeed, a manifesto of sorts for SG14
<https://groups.google.com/a/isocpp.org/d/msg/sg14/lqTkSzxs_W4/P0lYG8hpCgAJ>
is being written with this kind of thing at its core.

Basically, SG14 and those who support their aims are unconvinced of the
"just ensure that no allocations will occur before the low-latency part of
your code" approach. So any kind of effort to add generalized CoW-isms to
the C++ standard library is going to be looked at with suspicion by them.
Or at least annoyance, as yet another "pointless standard library thing
that I'll ignore".

And personally, I find it hard to disagree in this case. I understand the
sensibility that some users don't know how to use the language correctly
and thus get inferior performance due to extraneous copying. I get that.
But embracing their mistakes isn't the answer.

That's not to say that CoW is a bad thing; it has its place. But there are
places where CoW is just the wrong tool, and those places are kind of
important use cases for the language.

--
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/4e1b33c3-770f-4085-848d-b7ab89a3928f%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, July 19, 2018 at 11:38:20 PM UTC-4, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, 19 J=
uly 2018 20:17:17 PDT Nicol Bolas wrote:
<br>&gt; Throwing isn&#39;t necessarily the biggest issue with regard to Co=
W&#39;s
<br>&gt; allocations. Unexpected memory allocation is basically unacceptabl=
e if you
<br>&gt; want to have some reasonable guarantee of an APIs latency. SG14 is=
 debating
<br>&gt; adding insertion functions to `vector` that *can&#39;t* allocate m=
emory. This
<br>&gt; would allow users to be able to have APIs with static guarantees t=
hat
<br>&gt; &quot;unexpected memory allocation&quot; will never occur.
<br>&gt;=20
<br>&gt; From a low-latency perspective, CoW is a *bad* idea.
<br>
<br>All you need to do is ensure that the share count is 1 before you start=
 your=20
<br>operations. There&#39;s no CoW if it&#39;s not shared.<br></blockquote>=
<div><br></div><div>And all you need to do to use `vector::push_back` safel=
y is ensure that it has sufficient size before you start your operations. A=
nd yet, here we are: trying to add &quot;try_push_back&quot; and the like t=
o `vector`. And it&#39;s not just for `bad_alloc` throwing. Indeed, a <a hr=
ef=3D"https://groups.google.com/a/isocpp.org/d/msg/sg14/lqTkSzxs_W4/P0lYG8h=
pCgAJ">manifesto of sorts for SG14</a> is being written with this kind of t=
hing at its core.<br></div><div><br></div><div>Basically, SG14 and those wh=
o support their aims are unconvinced of the &quot;just ensure that no alloc=
ations will occur before the low-latency part of your code&quot; approach. =
So any kind of effort to add generalized CoW-isms to the C++ standard libra=
ry is going to be looked at with suspicion by them. Or at least annoyance, =
as yet another &quot;pointless standard library thing that I&#39;ll ignore&=
quot;.</div><div><br></div><div>And personally, I find it hard to disagree =
in this case. I understand the sensibility that some users don&#39;t know h=
ow to use the language correctly and thus get inferior performance due to e=
xtraneous copying. I get that. But embracing their mistakes isn&#39;t the a=
nswer.</div><div><br></div><div>That&#39;s not to say that CoW is a bad thi=
ng; it has its place. But there are places where CoW is just the wrong tool=
, and those places are kind of important use cases for the language.<br></d=
iv></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/4e1b33c3-770f-4085-848d-b7ab89a3928f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e1b33c3-770f-4085-848d-b7ab89a3928f=
%40isocpp.org</a>.<br />

------=_Part_4860_126447602.1532060343132--

------=_Part_4859_628512448.1532060343132--

.

------=_Part_5162_1864783999.1532071663961
Content-Type: multipart/alternative;
 boundary="----=_Part_5163_812990273.1532071663961"

------=_Part_5163_812990273.1532071663961
Content-Type: text/plain; charset="UTF-8"



On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:
>
> On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>>
>> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
>> > CoW is very much "out of vogue". Various folk these days claim that the
>> > cost of an atomic pointer increment is extremely high (which is mostly
>> > true) while the cost of making deep copies of things is much lower than
>> > it used to be, if indeed it was ever high to begin with.
>>
>> The problem was when you compared the two. For example, a function that
>> returns a container by value was forced to make a copy before C++11, then
>> destroy the original. The pair of atomic operation is usually cheaper
>> than the
>> memory allocation alone, not even counting the actual element copy.
>>
>> But since C++11 and move semantics, the return by value uses the move
>> constructor of the type in question and those can be faster than the pair
>> of
>> atomics. Then again, CoW containers also get move constructors and then
>> are
>> just as efficient.
>>
>> The problem for non-CoW is that all programmers are not created equal.
>> There
>> are quite a few who do not write efficient C++ code and often trip into
>> causing copies of containers. The use of CoW allows the container not to
>> deep-
>> copy unless there's a need to.
>>
>> On the other hand, the other problem for CoW is the unexpected memory
>> allocation: any non-const function can cause the shared container to stop
>> sharing, which means all non-const operations (including operator[]) can
>> potentially throw. Now, Qt doesn't care about exceptions, so this isn't a
>> problem, but in terms of code expansion and timing consistency, it can be
>> surprising.
>>
>
> Throwing isn't necessarily the biggest issue with regard to CoW's
> allocations. Unexpected memory allocation is basically unacceptable if you
> want to have some reasonable guarantee of an APIs latency. SG14 is debating
> adding insertion functions to `vector` that *can't* allocate memory. This
> would allow users to be able to have APIs with static guarantees that
> "unexpected memory allocation" will never occur.
>
> From a low-latency perspective, CoW is a *bad* idea.
>

CoW is the most user friendly memory management - it is the bridge that can
(and does) bring b/w CG and (A)RC languages and C++ closer together.

I am NOT saying std should be CoW, but it will be great to finally
acknowledge the most popular memory management on the planet and provide
tools for the users to CoW their objects.

Intrusive Pointers was a step in the right direction, but way, way too
small one - it still needs an expert to build a CoW-managed object.
That should not be the case, if C++ tries to be competitive - the user
should have full spectrum of options on his disposal, and CoW is one of the
major ones.

Care for the low-latency crowd should not be on the expense of mainstream
high-level programming, otherwise C++ will corner itself into a niche for
absolutely no good reason.

--
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/8be5b915-dcac-4c84-92e9-55b4216e27ed%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nico=
l Bolas wrote:<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"=
>On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">On Thursday, 19 July 2018 13:04:43 PDT =
Matthew Woehlke wrote:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</div></div></blockquote><div><br=
></div><div>CoW is the most user friendly memory management - it is the bri=
dge that can (and does) bring b/w CG and (A)RC languages and C++ closer tog=
ether.</div><div><br></div><div>I am NOT saying std should be CoW, but it w=
ill be great to finally acknowledge the most popular memory management on t=
he planet and provide tools for the users to CoW their objects.</div><div><=
br></div><div>Intrusive Pointers was a step in the right direction, but way=
, way too small one - it still needs an expert to build a CoW-managed objec=
t.=C2=A0<br></div><div>That should not be the case, if C++ tries to be comp=
etitive - the user should have full spectrum of options on his disposal, an=
d CoW is one of the major ones.</div><div><br></div><div>Care for the=C2=A0=
<span style=3D"display: inline !important; float: none; background-color: t=
ransparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;He=
lvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant=
: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align:=
 left; text-decoration: none; text-indent: 0px; text-transform: none; -webk=
it-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">low-lat=
ency crowd should not be on the expense of mainstream high-level programmin=
g, otherwise C++ will corner itself into a niche for absolutely no good rea=
son.=C2=A0</span></div><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/8be5b915-dcac-4c84-92e9-55b4216e27ed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8be5b915-dcac-4c84-92e9-55b4216e27ed=
%40isocpp.org</a>.<br />

------=_Part_5163_812990273.1532071663961--

------=_Part_5162_1864783999.1532071663961--

.

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

Except low latency is not as niche as you think.

I myself don't buy the advantange of CoW on existing standard container
considering move semantic and (N)RVO which are easily taught and used.

I think forcing CoW on people is violating the "dont pay for what you dont
use" philosophy.

Now having options to use other, CoW enabled containers or providing
building blocks for user to build their own is fine. Just don't make my
std::vector non vegan without my express consent.


Le ven. 20 juil. 2018 09:27, <mihailnajdenov@gmail.com> a =C3=A9crit :

>
>
> On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:
>>
>> On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>>>
>>> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
>>> > CoW is very much "out of vogue". Various folk these days claim that
>>> the
>>> > cost of an atomic pointer increment is extremely high (which is mostl=
y
>>> > true) while the cost of making deep copies of things is much lower
>>> than
>>> > it used to be, if indeed it was ever high to begin with.
>>>
>>> The problem was when you compared the two. For example, a function that
>>> returns a container by value was forced to make a copy before C++11,
>>> then
>>> destroy the original. The pair of atomic operation is usually cheaper
>>> than the
>>> memory allocation alone, not even counting the actual element copy.
>>>
>>> But since C++11 and move semantics, the return by value uses the move
>>> constructor of the type in question and those can be faster than the
>>> pair of
>>> atomics. Then again, CoW containers also get move constructors and then
>>> are
>>> just as efficient.
>>>
>>> The problem for non-CoW is that all programmers are not created equal.
>>> There
>>> are quite a few who do not write efficient C++ code and often trip into
>>> causing copies of containers. The use of CoW allows the container not t=
o
>>> deep-
>>> copy unless there's a need to.
>>>
>>> On the other hand, the other problem for CoW is the unexpected memory
>>> allocation: any non-const function can cause the shared container to
>>> stop
>>> sharing, which means all non-const operations (including operator[]) ca=
n
>>> potentially throw. Now, Qt doesn't care about exceptions, so this isn't
>>> a
>>> problem, but in terms of code expansion and timing consistency, it can
>>> be
>>> surprising.
>>>
>>
>> Throwing isn't necessarily the biggest issue with regard to CoW's
>> allocations. Unexpected memory allocation is basically unacceptable if y=
ou
>> want to have some reasonable guarantee of an APIs latency. SG14 is debat=
ing
>> adding insertion functions to `vector` that *can't* allocate memory.
>> This would allow users to be able to have APIs with static guarantees th=
at
>> "unexpected memory allocation" will never occur.
>>
>> From a low-latency perspective, CoW is a *bad* idea.
>>
>
> CoW is the most user friendly memory management - it is the bridge that
> can (and does) bring b/w CG and (A)RC languages and C++ closer together.
>
> I am NOT saying std should be CoW, but it will be great to finally
> acknowledge the most popular memory management on the planet and provide
> tools for the users to CoW their objects.
>
> Intrusive Pointers was a step in the right direction, but way, way too
> small one - it still needs an expert to build a CoW-managed object.
> That should not be the case, if C++ tries to be competitive - the user
> should have full spectrum of options on his disposal, and CoW is one of t=
he
> major ones.
>
> Care for the low-latency crowd should not be on the expense of mainstream
> high-level programming, otherwise C++ will corner itself into a niche for
> absolutely no good reason.
>
> --
> 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/8be5b915-dca=
c-4c84-92e9-55b4216e27ed%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8be5b915-dc=
ac-4c84-92e9-55b4216e27ed%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/CAOG9n2Fad6ZPoQu0Rav2%2Bcry-M0CXDpjAGkhNUdMwrGpd=
yW_oA%40mail.gmail.com.

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

<div dir=3D"auto">Except low latency is not as niche as you think.<div dir=
=3D"auto"><br></div><div dir=3D"auto">I myself don&#39;t buy the advantange=
 of CoW on existing standard container considering move semantic and (N)RVO=
 which are easily taught and used.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">I think forcing CoW on people is violating the &quot;dont pay fo=
r what you dont use&quot; philosophy.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">Now having options to use other, CoW enabled containers or pr=
oviding building blocks for user to build their own is fine. Just don&#39;t=
 make my std::vector non vegan without my express consent.</div><div dir=3D=
"auto"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le v=
en. 20 juil. 2018 09:27,  &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">m=
ihailnajdenov@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><br>On Friday, July 20, 2018 at 6:17:=
17 AM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieir=
a wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 19 July 2018 1=
3:04:43 PDT Matthew Woehlke wrote:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</div></div></blockquote><div><br=
></div><div>CoW is the most user friendly memory management - it is the bri=
dge that can (and does) bring b/w CG and (A)RC languages and C++ closer tog=
ether.</div><div><br></div><div>I am NOT saying std should be CoW, but it w=
ill be great to finally acknowledge the most popular memory management on t=
he planet and provide tools for the users to CoW their objects.</div><div><=
br></div><div>Intrusive Pointers was a step in the right direction, but way=
, way too small one - it still needs an expert to build a CoW-managed objec=
t.=C2=A0<br></div><div>That should not be the case, if C++ tries to be comp=
etitive - the user should have full spectrum of options on his disposal, an=
d CoW is one of the major ones.</div><div><br></div><div>Care for the=C2=A0=
<span style=3D"display:inline!important;float:none;background-color:transpa=
rent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot=
;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weig=
ht:400;letter-spacing:normal;text-align:left;text-decoration:none;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px">low-latency=
 crowd should not be on the expense of mainstream high-level programming, o=
therwise C++ will corner itself into a niche for absolutely no good reason.=
=C2=A0</span></div><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" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/8be5b915-dcac-4c84-92e9-55b4216e27ed%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/8be5b915-dcac-4c84-92e9-55b4216e27ed%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/CAOG9n2Fad6ZPoQu0Rav2%2Bcry-M0CXDpjAG=
khNUdMwrGpdyW_oA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOG9n2Fad6ZPoQ=
u0Rav2%2Bcry-M0CXDpjAGkhNUdMwrGpdyW_oA%40mail.gmail.com</a>.<br />

--00000000000060a8c105716a12ac--

.

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

On Fri, Jul 20, 2018 at 8:27 AM, <mihailnajdenov@gmail.com> wrote:

>
>
> On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:
>>
>> On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>>>
>>> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
>>> > CoW is very much "out of vogue". Various folk these days claim that
>>> the
>>> > cost of an atomic pointer increment is extremely high (which is mostly
>>> > true) while the cost of making deep copies of things is much lower
>>> than
>>> > it used to be, if indeed it was ever high to begin with.
>>>
>>> The problem was when you compared the two. For example, a function that
>>> returns a container by value was forced to make a copy before C++11,
>>> then
>>> destroy the original. The pair of atomic operation is usually cheaper
>>> than the
>>> memory allocation alone, not even counting the actual element copy.
>>>
>>> But since C++11 and move semantics, the return by value uses the move
>>> constructor of the type in question and those can be faster than the
>>> pair of
>>> atomics. Then again, CoW containers also get move constructors and then
>>> are
>>> just as efficient.
>>>
>>> The problem for non-CoW is that all programmers are not created equal.
>>> There
>>> are quite a few who do not write efficient C++ code and often trip into
>>> causing copies of containers. The use of CoW allows the container not to
>>> deep-
>>> copy unless there's a need to.
>>>
>>> On the other hand, the other problem for CoW is the unexpected memory
>>> allocation: any non-const function can cause the shared container to
>>> stop
>>> sharing, which means all non-const operations (including operator[]) can
>>> potentially throw. Now, Qt doesn't care about exceptions, so this isn't
>>> a
>>> problem, but in terms of code expansion and timing consistency, it can
>>> be
>>> surprising.
>>>
>>
>> Throwing isn't necessarily the biggest issue with regard to CoW's
>> allocations. Unexpected memory allocation is basically unacceptable if you
>> want to have some reasonable guarantee of an APIs latency. SG14 is debating
>> adding insertion functions to `vector` that *can't* allocate memory.
>> This would allow users to be able to have APIs with static guarantees that
>> "unexpected memory allocation" will never occur.
>>
>> From a low-latency perspective, CoW is a *bad* idea.
>>
>
> CoW is the most user friendly memory management - it is the bridge that
> can (and does) bring b/w CG and (A)RC languages and C++ closer together.
>

People don't use C++ for its user friendliness. C++ doesn't need to be
brought closer to GC languages, what it does need is a similarly rich set
of libraries
so that users can get up and running far more quickly.


> I am NOT saying std should be CoW, but it will be great to finally
> acknowledge the most popular memory management on the planet and provide
> tools for the users to CoW their objects.
>
> Intrusive Pointers was a step in the right direction, but way, way too
> small one - it still needs an expert to build a CoW-managed object.
> That should not be the case, if C++ tries to be competitive - the user
> should have full spectrum of options on his disposal, and CoW is one of the
> major ones.
>
> Care for the low-latency crowd should not be on the expense of mainstream
> high-level programming, otherwise C++ will corner itself into a niche for
> absolutely no good reason.
>

There's already little reason to use C++ for anything 'mainstream'. You're
likely to be far more productive and stress-free with other languages, and
this isn't because of memory management. People only choose C++ for
something only if they truly need it. If you want Java, use Java.

--
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/CAFQaeCBcZNzV1d7zhAnC47qjxkLp0eevXc3g1aFC3RA4GTkzwA%40mail.gmail.com.

--00000000000004645b05716bc047
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 Fri, Jul 20, 2018 at 8:27 AM,  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:mihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@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"><div>=
<div class=3D"h5"><br><br>On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nic=
ol Bolas wrote:<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">On =
Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex">On Thursday, 19 July 2018 13:04:43 PDT Matt=
hew Woehlke wrote:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</div></div></blockquote><div><br=
></div></div></div><div>CoW is the most user friendly memory management - i=
t is the bridge that can (and does) bring b/w CG and (A)RC languages and C+=
+ closer together.<br></div></div></blockquote><div><br></div><div>People d=
on&#39;t use C++ for its user friendliness. C++ doesn&#39;t need to be brou=
ght closer to GC languages, what it does need is a similarly rich set of li=
braries</div><div>so that users can get up and running far more quickly.</d=
iv><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"><div></=
div><div>I am NOT saying std should be CoW, but it will be great to finally=
 acknowledge the most popular memory management on the planet and provide t=
ools for the users to CoW their objects.</div><div><br></div><div>Intrusive=
 Pointers was a step in the right direction, but way, way too small one - i=
t still needs an expert to build a CoW-managed object.=C2=A0<br></div><div>=
That should not be the case, if C++ tries to be competitive - the user shou=
ld have full spectrum of options on his disposal, and CoW is one of the maj=
or ones.</div><div><br></div><div>Care for the=C2=A0<span style=3D"display:=
inline!important;float:none;background-color:transparent;color:rgb(34,34,34=
);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:=
13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:n=
ormal;text-align:left;text-decoration:none;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px">low-latency crowd should not be on=
 the expense of mainstream high-level programming, otherwise C++ will corne=
r itself into a niche for absolutely no good reason.=C2=A0</span></div></di=
v></blockquote><div><br></div><div>There&#39;s already little reason to use=
 C++ for anything &#39;mainstream&#39;. You&#39;re likely to be far more pr=
oductive and stress-free with other languages, and this isn&#39;t because o=
f memory management. People only choose C++ for something only if they trul=
y need it. If you want Java, use Java.</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/CAFQaeCBcZNzV1d7zhAnC47qjxkLp0eevXc3g=
1aFC3RA4GTkzwA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCBcZNzV1d7z=
hAnC47qjxkLp0eevXc3g1aFC3RA4GTkzwA%40mail.gmail.com</a>.<br />

--00000000000004645b05716bc047--

.

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

I, for one, use C++ because of its user-friendliness. In this case,
user-friendliness means being able to convince the compiler to tell me
where I need to fix things because I can make it understand loads of things
through static typing.

Python is nowhere near as "user friendly" as that. Sure, you can write
things quickly in python, but evolving a codebase is like pulling teeth.

G

On Fri, Jul 20, 2018 at 11:27 AM, j c <james.a.cooper@gmail.com> wrote:

>
>
> On Fri, Jul 20, 2018 at 8:27 AM, <mihailnajdenov@gmail.com> wrote:
>
>>
>>
>> On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:
>>>
>>> On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>>>>
>>>> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
>>>> > CoW is very much "out of vogue". Various folk these days claim that
>>>> the
>>>> > cost of an atomic pointer increment is extremely high (which is
>>>> mostly
>>>> > true) while the cost of making deep copies of things is much lower
>>>> than
>>>> > it used to be, if indeed it was ever high to begin with.
>>>>
>>>> The problem was when you compared the two. For example, a function that
>>>> returns a container by value was forced to make a copy before C++11,
>>>> then
>>>> destroy the original. The pair of atomic operation is usually cheaper
>>>> than the
>>>> memory allocation alone, not even counting the actual element copy.
>>>>
>>>> But since C++11 and move semantics, the return by value uses the move
>>>> constructor of the type in question and those can be faster than the
>>>> pair of
>>>> atomics. Then again, CoW containers also get move constructors and then
>>>> are
>>>> just as efficient.
>>>>
>>>> The problem for non-CoW is that all programmers are not created equal.
>>>> There
>>>> are quite a few who do not write efficient C++ code and often trip into
>>>> causing copies of containers. The use of CoW allows the container not
>>>> to deep-
>>>> copy unless there's a need to.
>>>>
>>>> On the other hand, the other problem for CoW is the unexpected memory
>>>> allocation: any non-const function can cause the shared container to
>>>> stop
>>>> sharing, which means all non-const operations (including operator[])
>>>> can
>>>> potentially throw. Now, Qt doesn't care about exceptions, so this isn't
>>>> a
>>>> problem, but in terms of code expansion and timing consistency, it can
>>>> be
>>>> surprising.
>>>>
>>>
>>> Throwing isn't necessarily the biggest issue with regard to CoW's
>>> allocations. Unexpected memory allocation is basically unacceptable if you
>>> want to have some reasonable guarantee of an APIs latency. SG14 is debating
>>> adding insertion functions to `vector` that *can't* allocate memory.
>>> This would allow users to be able to have APIs with static guarantees that
>>> "unexpected memory allocation" will never occur.
>>>
>>> From a low-latency perspective, CoW is a *bad* idea.
>>>
>>
>> CoW is the most user friendly memory management - it is the bridge that
>> can (and does) bring b/w CG and (A)RC languages and C++ closer together.
>>
>
> People don't use C++ for its user friendliness. C++ doesn't need to be
> brought closer to GC languages, what it does need is a similarly rich set
> of libraries
> so that users can get up and running far more quickly.
>
>
>> I am NOT saying std should be CoW, but it will be great to finally
>> acknowledge the most popular memory management on the planet and provide
>> tools for the users to CoW their objects.
>>
>> Intrusive Pointers was a step in the right direction, but way, way too
>> small one - it still needs an expert to build a CoW-managed object.
>> That should not be the case, if C++ tries to be competitive - the user
>> should have full spectrum of options on his disposal, and CoW is one of the
>> major ones.
>>
>> Care for the low-latency crowd should not be on the expense of
>> mainstream high-level programming, otherwise C++ will corner itself into a
>> niche for absolutely no good reason.
>>
>
> There's already little reason to use C++ for anything 'mainstream'. You're
> likely to be far more productive and stress-free with other languages, and
> this isn't because of memory management. People only choose C++ for
> something only if they truly need it. If you want Java, use Java.
>
> --
> 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/CAFQaeCBcZNzV1d7zhAnC47qjxkLp0
> eevXc3g1aFC3RA4GTkzwA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCBcZNzV1d7zhAnC47qjxkLp0eevXc3g1aFC3RA4GTkzwA%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/CAANG%3DkW7dTQrLMtvQ0QU1fnSx_ZXTwPsEC-CSzyr9Ge6Y9bRWA%40mail.gmail.com.

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

<div dir=3D"ltr">I, for one, use C++ because of its user-friendliness. In t=
his case, user-friendliness means being able to convince the compiler to te=
ll me where I need to fix things because I can make it understand loads of =
things through static typing.<div><br></div><div>Python is nowhere near as =
&quot;user friendly&quot; as that. Sure, you can write things quickly in py=
thon, but evolving a codebase is like pulling teeth.</div><div><br></div><d=
iv>G</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Fri, Jul 20, 2018 at 11:27 AM, j c <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:james.a.cooper@gmail.com" target=3D"_blank">james.a.cooper@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"><br><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=3D"=
h5">On Fri, Jul 20, 2018 at 8:27 AM,  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:mihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@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"><div>=
<div class=3D"m_3298741510394971650h5"><br><br>On Friday, July 20, 2018 at =
6:17:17 AM UTC+3, 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, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 19 July 2=
018 13:04:43 PDT Matthew Woehlke wrote:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</div></div></blockquote><div><br=
></div></div></div><div>CoW is the most user friendly memory management - i=
t is the bridge that can (and does) bring b/w CG and (A)RC languages and C+=
+ closer together.<br></div></div></blockquote><div><br></div></div></div><=
div>People don&#39;t use C++ for its user friendliness. C++ doesn&#39;t nee=
d to be brought closer to GC languages, what it does need is a similarly ri=
ch set of libraries</div><div>so that users can get up and running far more=
 quickly.</div><span class=3D""><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"><div></div><div>I am NOT saying std should be CoW, bu=
t it will be great to finally acknowledge the most popular memory managemen=
t on the planet and provide tools for the users to CoW their objects.</div>=
<div><br></div><div>Intrusive Pointers was a step in the right direction, b=
ut way, way too small one - it still needs an expert to build a CoW-managed=
 object.=C2=A0<br></div><div>That should not be the case, if C++ tries to b=
e competitive - the user should have full spectrum of options on his dispos=
al, and CoW is one of the major ones.</div><div><br></div><div>Care for the=
=C2=A0<span style=3D"display:inline!important;float:none;background-color:t=
ransparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetic=
a&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;fon=
t-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;tex=
t-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">low-l=
atency crowd should not be on the expense of mainstream high-level programm=
ing, otherwise C++ will corner itself into a niche for absolutely no good r=
eason.=C2=A0</span></div></div></blockquote><div><br></div></span><div>Ther=
e&#39;s already little reason to use C++ for anything &#39;mainstream&#39;.=
 You&#39;re likely to be far more productive and stress-free with other lan=
guages, and this isn&#39;t because of memory management. People only choose=
 C++ for something only if they truly need it. If you want Java, use Java.<=
/div></div></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/CAFQaeCBcZNzV1d7zhAnC47qjxkLp0eevXc3g=
1aFC3RA4GTkzwA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAFQaeCBcZNzV1d7zhAnC47qjxkLp0<wbr>eevXc3g1aFC3RA4GTkzw=
A%40mail.<wbr>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/CAANG%3DkW7dTQrLMtvQ0QU1fnSx_ZXTwPsEC=
-CSzyr9Ge6Y9bRWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkW7dTQr=
LMtvQ0QU1fnSx_ZXTwPsEC-CSzyr9Ge6Y9bRWA%40mail.gmail.com</a>.<br />

--000000000000e5fb3605716bce92--

.

------=_Part_5501_1775981444.1532090321751
Content-Type: multipart/alternative;
 boundary="----=_Part_5502_1322037017.1532090321751"

------=_Part_5502_1322037017.1532090321751
Content-Type: text/plain; charset="UTF-8"



On Friday, July 20, 2018 at 1:28:02 PM UTC+3, j c wrote:
>
>
>
> On Fri, Jul 20, 2018 at 8:27 AM, <mihailn...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:
>>>
>>> On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>>>>
>>>> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
>>>> > CoW is very much "out of vogue". Various folk these days claim that
>>>> the
>>>> > cost of an atomic pointer increment is extremely high (which is
>>>> mostly
>>>> > true) while the cost of making deep copies of things is much lower
>>>> than
>>>> > it used to be, if indeed it was ever high to begin with.
>>>>
>>>> The problem was when you compared the two. For example, a function that
>>>> returns a container by value was forced to make a copy before C++11,
>>>> then
>>>> destroy the original. The pair of atomic operation is usually cheaper
>>>> than the
>>>> memory allocation alone, not even counting the actual element copy.
>>>>
>>>> But since C++11 and move semantics, the return by value uses the move
>>>> constructor of the type in question and those can be faster than the
>>>> pair of
>>>> atomics. Then again, CoW containers also get move constructors and then
>>>> are
>>>> just as efficient.
>>>>
>>>> The problem for non-CoW is that all programmers are not created equal.
>>>> There
>>>> are quite a few who do not write efficient C++ code and often trip into
>>>> causing copies of containers. The use of CoW allows the container not
>>>> to deep-
>>>> copy unless there's a need to.
>>>>
>>>> On the other hand, the other problem for CoW is the unexpected memory
>>>> allocation: any non-const function can cause the shared container to
>>>> stop
>>>> sharing, which means all non-const operations (including operator[])
>>>> can
>>>> potentially throw. Now, Qt doesn't care about exceptions, so this isn't
>>>> a
>>>> problem, but in terms of code expansion and timing consistency, it can
>>>> be
>>>> surprising.
>>>>
>>>
>>> Throwing isn't necessarily the biggest issue with regard to CoW's
>>> allocations. Unexpected memory allocation is basically unacceptable if you
>>> want to have some reasonable guarantee of an APIs latency. SG14 is debating
>>> adding insertion functions to `vector` that *can't* allocate memory.
>>> This would allow users to be able to have APIs with static guarantees that
>>> "unexpected memory allocation" will never occur.
>>>
>>> From a low-latency perspective, CoW is a *bad* idea.
>>>
>>
>> CoW is the most user friendly memory management - it is the bridge that
>> can (and does) bring b/w CG and (A)RC languages and C++ closer together.
>>
>
> People don't use C++ for its user friendliness. C++ doesn't need to be
> brought closer to GC languages, what it does need is a similarly rich set
> of libraries
> so that users can get up and running far more quickly.
>
>
>> I am NOT saying std should be CoW, but it will be great to finally
>> acknowledge the most popular memory management on the planet and provide
>> tools for the users to CoW their objects.
>>
>> Intrusive Pointers was a step in the right direction, but way, way too
>> small one - it still needs an expert to build a CoW-managed object.
>> That should not be the case, if C++ tries to be competitive - the user
>> should have full spectrum of options on his disposal, and CoW is one of the
>> major ones.
>>
>> Care for the low-latency crowd should not be on the expense of
>> mainstream high-level programming, otherwise C++ will corner itself into a
>> niche for absolutely no good reason.
>>
>
> There's already little reason to use C++ for anything 'mainstream'. You're
> likely to be far more productive and stress-free with other languages, and
> this isn't because of memory management. People only choose C++ for
> something only if they truly need it. If you want Java, use Java.
>

Why should developers be forced into another languages when C++ can cover
their needs with some additional tools?
Why should developers, coming from GC/RC languages be force into cultural
shock instead offering tools for smooth transition?
No one is deprecating unique and shared pointer, but users of other
languages, which want to use C++, should have the option to use a model,
familiar to them.

"Don't pay for what you don't use", ok, but what if I the user *wants* to
pay? Where are his potions?!? "Fake it" using shared_ptr?
Besides, it is not like CoW objects don't have intrinsic value on their own
like never-null, value semantics and cheap copy.

*Sidenote*, funny how* even Rust* could not get away without a
std::borrow::Cow, and that, after they tried to reinvent lifetime
management.
This leaves C++ arguably the only high level language without this kind of
lifetime management in its toolbox. This is not a win.

--
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/afc40ef9-2789-4e5a-b191-d02eb92807a6%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, July 20, 2018 at 1:28:02 PM UTC+3, j c =
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"><br><di=
v><br><div class=3D"gmail_quote">On Fri, Jul 20, 2018 at 8:27 AM,  <span di=
r=3D"ltr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"jav=
ascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"Q2x_I=
5AmAwAJ">mihailn...@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"><div><div><br><br>On Friday, July 20, 2018 at 6=
:17:17 AM UTC+3, 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, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 19 July 2=
018 13:04:43 PDT Matthew Woehlke wrote:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</div></div></blockquote><div><br=
></div></div></div><div>CoW is the most user friendly memory management - i=
t is the bridge that can (and does) bring b/w CG and (A)RC languages and C+=
+ closer together.<br></div></div></blockquote><div><br></div><div>People d=
on&#39;t use C++ for its user friendliness. C++ doesn&#39;t need to be brou=
ght closer to GC languages, what it does need is a similarly rich set of li=
braries</div><div>so that users can get up and running far more quickly.</d=
iv><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"><div></=
div><div>I am NOT saying std should be CoW, but it will be great to finally=
 acknowledge the most popular memory management on the planet and provide t=
ools for the users to CoW their objects.</div><div><br></div><div>Intrusive=
 Pointers was a step in the right direction, but way, way too small one - i=
t still needs an expert to build a CoW-managed object.=C2=A0<br></div><div>=
That should not be the case, if C++ tries to be competitive - the user shou=
ld have full spectrum of options on his disposal, and CoW is one of the maj=
or ones.</div><div><br></div><div>Care for the=C2=A0<span style=3D"display:=
inline!important;float:none;background-color:transparent;color:rgb(34,34,34=
);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:=
13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:n=
ormal;text-align:left;text-decoration:none;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px">low-latency crowd should not be on=
 the expense of mainstream high-level programming, otherwise C++ will corne=
r itself into a niche for absolutely no good reason.=C2=A0</span></div></di=
v></blockquote><div><br></div><div>There&#39;s already little reason to use=
 C++ for anything &#39;mainstream&#39;. You&#39;re likely to be far more pr=
oductive and stress-free with other languages, and this isn&#39;t because o=
f memory management. People only choose C++ for something only if they trul=
y need it. If you want Java, use Java.</div></div></div></div></blockquote>=
<div><br></div><div>Why should developers be forced into another languages =
when C++ can cover their needs with some additional tools?</div><div>Why sh=
ould developers, coming from GC/RC languages be force into cultural shock i=
nstead offering tools for smooth transition?=C2=A0</div><div>No one is depr=
ecating unique and shared pointer, but users of other languages, which want=
 to use C++, should have the option to use a model, familiar to them.</div>=
<div><br></div><div>&quot;D<span style=3D"display: inline !important; float=
: none; background-color: transparent; color: rgb(34, 34, 34); font-family:=
 &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-=
style: normal; font-variant: normal; font-weight: 400; letter-spacing: norm=
al; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; =
text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; =
word-spacing: 0px;">on&#39;t pay for what you don&#39;t use</span>&quot;, o=
k, but what if I the user <i>wants</i> to pay? Where are his potions?!? &qu=
ot;Fake it&quot; using shared_ptr?</div><div><div style=3D"background-color=
: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: n=
one; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat:=
 stretch; border-image-slice: 100%; border-image-source: none; border-image=
-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; bor=
der-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-styl=
e: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border=
-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-famil=
y: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font=
-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; le=
tter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0=
px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; pa=
dding-right: 0px; padding-top: 0px; text-align: left; text-decoration: none=
; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; w=
hite-space: normal; word-spacing: 0px;">Besides, it is not like CoW objects=
 don&#39;t have intrinsic value on their own like never-null, value semanti=
cs and cheap copy. =C2=A0<br></div></div><div><b></b><i></i><u></u><sub></s=
ub><sup></sup><strike></strike><br></div><div><b>Sidenote</b>, funny how<i>=
 even Rust</i> could not get away without a=C2=A0<font face=3D"courier new,=
monospace">std::borrow::Cow</font>, and that, after they tried to reinvent =
lifetime management.</div><div>This leaves C++ arguably the only high level=
 language without this kind of lifetime management in its toolbox. This is =
not a win.</div><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/afc40ef9-2789-4e5a-b191-d02eb92807a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/afc40ef9-2789-4e5a-b191-d02eb92807a6=
%40isocpp.org</a>.<br />

------=_Part_5502_1322037017.1532090321751--

------=_Part_5501_1775981444.1532090321751--

.

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

Lifetime management on c++ is the job for RAII enabled type.

Le ven. 20 juil. 2018 14:38, <mihailnajdenov@gmail.com> a =C3=A9crit :

>
>
> On Friday, July 20, 2018 at 1:28:02 PM UTC+3, j c wrote:
>>
>>
>>
>> On Fri, Jul 20, 2018 at 8:27 AM, <mihailn...@gmail.com> wrote:
>>
>>>
>>>
>>> On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>>>>>
>>>>> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
>>>>> > CoW is very much "out of vogue". Various folk these days claim that
>>>>> the
>>>>> > cost of an atomic pointer increment is extremely high (which is
>>>>> mostly
>>>>> > true) while the cost of making deep copies of things is much lower
>>>>> than
>>>>> > it used to be, if indeed it was ever high to begin with.
>>>>>
>>>>> The problem was when you compared the two. For example, a function
>>>>> that
>>>>> returns a container by value was forced to make a copy before C++11,
>>>>> then
>>>>> destroy the original. The pair of atomic operation is usually cheaper
>>>>> than the
>>>>> memory allocation alone, not even counting the actual element copy.
>>>>>
>>>>> But since C++11 and move semantics, the return by value uses the move
>>>>> constructor of the type in question and those can be faster than the
>>>>> pair of
>>>>> atomics. Then again, CoW containers also get move constructors and
>>>>> then are
>>>>> just as efficient.
>>>>>
>>>>> The problem for non-CoW is that all programmers are not created equal=
..
>>>>> There
>>>>> are quite a few who do not write efficient C++ code and often trip
>>>>> into
>>>>> causing copies of containers. The use of CoW allows the container not
>>>>> to deep-
>>>>> copy unless there's a need to.
>>>>>
>>>>> On the other hand, the other problem for CoW is the unexpected memory
>>>>> allocation: any non-const function can cause the shared container to
>>>>> stop
>>>>> sharing, which means all non-const operations (including operator[])
>>>>> can
>>>>> potentially throw. Now, Qt doesn't care about exceptions, so this
>>>>> isn't a
>>>>> problem, but in terms of code expansion and timing consistency, it ca=
n
>>>>> be
>>>>> surprising.
>>>>>
>>>>
>>>> Throwing isn't necessarily the biggest issue with regard to CoW's
>>>> allocations. Unexpected memory allocation is basically unacceptable if=
 you
>>>> want to have some reasonable guarantee of an APIs latency. SG14 is deb=
ating
>>>> adding insertion functions to `vector` that *can't* allocate memory.
>>>> This would allow users to be able to have APIs with static guarantees =
that
>>>> "unexpected memory allocation" will never occur.
>>>>
>>>> From a low-latency perspective, CoW is a *bad* idea.
>>>>
>>>
>>> CoW is the most user friendly memory management - it is the bridge that
>>> can (and does) bring b/w CG and (A)RC languages and C++ closer together=
..
>>>
>>
>> People don't use C++ for its user friendliness. C++ doesn't need to be
>> brought closer to GC languages, what it does need is a similarly rich se=
t
>> of libraries
>> so that users can get up and running far more quickly.
>>
>>
>>> I am NOT saying std should be CoW, but it will be great to finally
>>> acknowledge the most popular memory management on the planet and provid=
e
>>> tools for the users to CoW their objects.
>>>
>>> Intrusive Pointers was a step in the right direction, but way, way too
>>> small one - it still needs an expert to build a CoW-managed object.
>>> That should not be the case, if C++ tries to be competitive - the user
>>> should have full spectrum of options on his disposal, and CoW is one of=
 the
>>> major ones.
>>>
>>> Care for the low-latency crowd should not be on the expense of
>>> mainstream high-level programming, otherwise C++ will corner itself int=
o a
>>> niche for absolutely no good reason.
>>>
>>
>> There's already little reason to use C++ for anything 'mainstream'.
>> You're likely to be far more productive and stress-free with other
>> languages, and this isn't because of memory management. People only choo=
se
>> C++ for something only if they truly need it. If you want Java, use Java=
..
>>
>
> Why should developers be forced into another languages when C++ can cover
> their needs with some additional tools?
> Why should developers, coming from GC/RC languages be force into cultural
> shock instead offering tools for smooth transition?
> No one is deprecating unique and shared pointer, but users of other
> languages, which want to use C++, should have the option to use a model,
> familiar to them.
>
> "Don't pay for what you don't use", ok, but what if I the user *wants* to
> pay? Where are his potions?!? "Fake it" using shared_ptr?
> Besides, it is not like CoW objects don't have intrinsic value on their
> own like never-null, value semantics and cheap copy.
>
> *Sidenote*, funny how* even Rust* could not get away without a
> std::borrow::Cow, and that, after they tried to reinvent lifetime
> management.
> This leaves C++ arguably the only high level language without this kind o=
f
> lifetime management in its toolbox. This is not a win.
>
> --
> 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/afc40ef9-278=
9-4e5a-b191-d02eb92807a6%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/afc40ef9-27=
89-4e5a-b191-d02eb92807a6%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/CAOG9n2HPgKLcdrwbmuQVNx9L2P%2B6iBfZ_2oKr9upHOva6=
1B7%2BQ%40mail.gmail.com.

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

<div dir=3D"auto">Lifetime management on c++ is the job for RAII enabled ty=
pe.=C2=A0</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le ven. 20 j=
uil. 2018 14:38,  &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">mihailnaj=
denov@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><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"><br><br>On Friday, July 20, 2018 at 1:28:02 PM UT=
C+3, j c wrote:<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"><br=
><div><br><div class=3D"gmail_quote">On Fri, Jul 20, 2018 at 8:27 AM,  <spa=
n dir=3D"ltr">&lt;<a rel=3D"nofollow noreferrer">mihailn...@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><d=
iv><br><br>On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, July =
19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wro=
te:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</div></div></blockquote><div><br=
></div></div></div><div>CoW is the most user friendly memory management - i=
t is the bridge that can (and does) bring b/w CG and (A)RC languages and C+=
+ closer together.<br></div></div></blockquote><div><br></div><div>People d=
on&#39;t use C++ for its user friendliness. C++ doesn&#39;t need to be brou=
ght closer to GC languages, what it does need is a similarly rich set of li=
braries</div><div>so that users can get up and running far more quickly.</d=
iv><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"><div></=
div><div>I am NOT saying std should be CoW, but it will be great to finally=
 acknowledge the most popular memory management on the planet and provide t=
ools for the users to CoW their objects.</div><div><br></div><div>Intrusive=
 Pointers was a step in the right direction, but way, way too small one - i=
t still needs an expert to build a CoW-managed object.=C2=A0<br></div><div>=
That should not be the case, if C++ tries to be competitive - the user shou=
ld have full spectrum of options on his disposal, and CoW is one of the maj=
or ones.</div><div><br></div><div>Care for the=C2=A0<span style=3D"display:=
inline!important;float:none;background-color:transparent;color:rgb(34,34,34=
);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:=
13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:n=
ormal;text-align:left;text-decoration:none;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px">low-latency crowd should not be on=
 the expense of mainstream high-level programming, otherwise C++ will corne=
r itself into a niche for absolutely no good reason.=C2=A0</span></div></di=
v></blockquote><div><br></div><div>There&#39;s already little reason to use=
 C++ for anything &#39;mainstream&#39;. You&#39;re likely to be far more pr=
oductive and stress-free with other languages, and this isn&#39;t because o=
f memory management. People only choose C++ for something only if they trul=
y need it. If you want Java, use Java.</div></div></div></div></blockquote>=
<div><br></div><div>Why should developers be forced into another languages =
when C++ can cover their needs with some additional tools?</div><div>Why sh=
ould developers, coming from GC/RC languages be force into cultural shock i=
nstead offering tools for smooth transition?=C2=A0</div><div>No one is depr=
ecating unique and shared pointer, but users of other languages, which want=
 to use C++, should have the option to use a model, familiar to them.</div>=
<div><br></div><div>&quot;D<span style=3D"display:inline!important;float:no=
ne;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial=
&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;fo=
nt-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;tex=
t-decoration:none;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px">on&#39;t pay for what you don&#39;t use</span>&quot;, ok, b=
ut what if I the user <i>wants</i> to pay? Where are his potions?!? &quot;F=
ake it&quot; using shared_ptr?</div><div><div>Besides, it is not like CoW o=
bjects don&#39;t have intrinsic value on their own like never-null, value s=
emantics and cheap copy. =C2=A0<br></div></div><div><b></b><i></i><u></u><s=
ub></sub><sup></sup><strike></strike><br></div><div><b>Sidenote</b>, funny =
how<i> even Rust</i> could not get away without a=C2=A0<font face=3D"courie=
r new,monospace">std::borrow::Cow</font>, and that, after they tried to rei=
nvent lifetime management.</div><div>This leaves C++ arguably the only high=
 level language without this kind of lifetime management in its toolbox. Th=
is is not a win.</div><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" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/afc40ef9-2789-4e5a-b191-d02eb92807a6%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/afc40ef9-2789-4e5a-b191-d02eb92807a6%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/CAOG9n2HPgKLcdrwbmuQVNx9L2P%2B6iBfZ_2=
oKr9upHOva61B7%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOG9n2HPgKLc=
drwbmuQVNx9L2P%2B6iBfZ_2oKr9upHOva61B7%2BQ%40mail.gmail.com</a>.<br />

--000000000000efba7405716d9db7--

.

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

On Fri, Jul 20, 2018 at 1:38 PM, <mihailnajdenov@gmail.com> wrote:

>
>
> On Friday, July 20, 2018 at 1:28:02 PM UTC+3, j c wrote:
>
>>
>>
>> On Fri, Jul 20, 2018 at 8:27 AM, <mihailn...@gmail.com> wrote:
>>
>>>
>>>
>>> On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>>>>>
>>>>> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
>>>>> > CoW is very much "out of vogue". Various folk these days claim that
>>>>> the
>>>>> > cost of an atomic pointer increment is extremely high (which is
>>>>> mostly
>>>>> > true) while the cost of making deep copies of things is much lower
>>>>> than
>>>>> > it used to be, if indeed it was ever high to begin with.
>>>>>
>>>>> The problem was when you compared the two. For example, a function
>>>>> that
>>>>> returns a container by value was forced to make a copy before C++11,
>>>>> then
>>>>> destroy the original. The pair of atomic operation is usually cheaper
>>>>> than the
>>>>> memory allocation alone, not even counting the actual element copy.
>>>>>
>>>>> But since C++11 and move semantics, the return by value uses the move
>>>>> constructor of the type in question and those can be faster than the
>>>>> pair of
>>>>> atomics. Then again, CoW containers also get move constructors and
>>>>> then are
>>>>> just as efficient.
>>>>>
>>>>> The problem for non-CoW is that all programmers are not created equal.
>>>>> There
>>>>> are quite a few who do not write efficient C++ code and often trip
>>>>> into
>>>>> causing copies of containers. The use of CoW allows the container not
>>>>> to deep-
>>>>> copy unless there's a need to.
>>>>>
>>>>> On the other hand, the other problem for CoW is the unexpected memory
>>>>> allocation: any non-const function can cause the shared container to
>>>>> stop
>>>>> sharing, which means all non-const operations (including operator[])
>>>>> can
>>>>> potentially throw. Now, Qt doesn't care about exceptions, so this
>>>>> isn't a
>>>>> problem, but in terms of code expansion and timing consistency, it can
>>>>> be
>>>>> surprising.
>>>>>
>>>>
>>>> Throwing isn't necessarily the biggest issue with regard to CoW's
>>>> allocations. Unexpected memory allocation is basically unacceptable if you
>>>> want to have some reasonable guarantee of an APIs latency. SG14 is debating
>>>> adding insertion functions to `vector` that *can't* allocate memory.
>>>> This would allow users to be able to have APIs with static guarantees that
>>>> "unexpected memory allocation" will never occur.
>>>>
>>>> From a low-latency perspective, CoW is a *bad* idea.
>>>>
>>>
>>> CoW is the most user friendly memory management - it is the bridge that
>>> can (and does) bring b/w CG and (A)RC languages and C++ closer together.
>>>
>>
>> People don't use C++ for its user friendliness. C++ doesn't need to be
>> brought closer to GC languages, what it does need is a similarly rich set
>> of libraries
>> so that users can get up and running far more quickly.
>>
>>
>>> I am NOT saying std should be CoW, but it will be great to finally
>>> acknowledge the most popular memory management on the planet and provide
>>> tools for the users to CoW their objects.
>>>
>>> Intrusive Pointers was a step in the right direction, but way, way too
>>> small one - it still needs an expert to build a CoW-managed object.
>>> That should not be the case, if C++ tries to be competitive - the user
>>> should have full spectrum of options on his disposal, and CoW is one of the
>>> major ones.
>>>
>>> Care for the low-latency crowd should not be on the expense of
>>> mainstream high-level programming, otherwise C++ will corner itself into a
>>> niche for absolutely no good reason.
>>>
>>
>> There's already little reason to use C++ for anything 'mainstream'.
>> You're likely to be far more productive and stress-free with other
>> languages, and this isn't because of memory management. People only choose
>> C++ for something only if they truly need it. If you want Java, use Java.
>>
>
> Why should developers be forced into another languages when C++ can cover
> their needs with some additional tools?
> Why should developers, coming from GC/RC languages be force into cultural
> shock instead offering tools for smooth transition?
> No one is deprecating unique and shared pointer, but users of other
> languages, which want to use C++, should have the option to use a model,
> familiar to them.
>
> "Don't pay for what you don't use", ok, but what if I the user *wants* to
> pay? Where are his potions?!? "Fake it" using shared_ptr?
> Besides, it is not like CoW objects don't have intrinsic value on their
> own like never-null, value semantics and cheap copy.
>
> *Sidenote*, funny how* even Rust* could not get away without a
> std::borrow::Cow, and that, after they tried to reinvent lifetime
> management.
> This leaves C++ arguably the only high level language without this kind of
> lifetime management in its toolbox. This is not a win.
>
>
Teach them Rust then.
Hopefully the cultural shock won't be too much when they find out it isn't
the same as $FAVOURITE_LANGUAGE.

--
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/CAFQaeCAaQteSVGrd5L4dwf4tn%2BitEO9bUiUt9dUJk%3D17d6YXFw%40mail.gmail.com.

--00000000000033e15a05716e17c2
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 Fri, Jul 20, 2018 at 1:38 PM,  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:mihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@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"><br><=
br>On Friday, July 20, 2018 at 1:28:02 PM UTC+3, j c wrote:<div><div class=
=3D"h5"><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"><br><div><=
br><div class=3D"gmail_quote">On Fri, Jul 20, 2018 at 8:27 AM,  <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">mihailn...@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br><br>On Fr=
iday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:<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">On Thursday, July 19, 2018 at 9:46=
:45 PM UTC-4, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</div></div></blockquote><div><br=
></div></div></div><div>CoW is the most user friendly memory management - i=
t is the bridge that can (and does) bring b/w CG and (A)RC languages and C+=
+ closer together.<br></div></div></blockquote><div><br></div><div>People d=
on&#39;t use C++ for its user friendliness. C++ doesn&#39;t need to be brou=
ght closer to GC languages, what it does need is a similarly rich set of li=
braries</div><div>so that users can get up and running far more quickly.</d=
iv><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"><div></=
div><div>I am NOT saying std should be CoW, but it will be great to finally=
 acknowledge the most popular memory management on the planet and provide t=
ools for the users to CoW their objects.</div><div><br></div><div>Intrusive=
 Pointers was a step in the right direction, but way, way too small one - i=
t still needs an expert to build a CoW-managed object.=C2=A0<br></div><div>=
That should not be the case, if C++ tries to be competitive - the user shou=
ld have full spectrum of options on his disposal, and CoW is one of the maj=
or ones.</div><div><br></div><div>Care for the=C2=A0<span style=3D"display:=
inline!important;float:none;background-color:transparent;color:rgb(34,34,34=
);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:=
13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:n=
ormal;text-align:left;text-decoration:none;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px">low-latency crowd should not be on=
 the expense of mainstream high-level programming, otherwise C++ will corne=
r itself into a niche for absolutely no good reason.=C2=A0</span></div></di=
v></blockquote><div><br></div><div>There&#39;s already little reason to use=
 C++ for anything &#39;mainstream&#39;. You&#39;re likely to be far more pr=
oductive and stress-free with other languages, and this isn&#39;t because o=
f memory management. People only choose C++ for something only if they trul=
y need it. If you want Java, use Java.</div></div></div></div></blockquote>=
<div><br></div></div></div><div>Why should developers be forced into anothe=
r languages when C++ can cover their needs with some additional tools?</div=
><div>Why should developers, coming from GC/RC languages be force into cult=
ural shock instead offering tools for smooth transition?=C2=A0</div><div>No=
 one is deprecating unique and shared pointer, but users of other languages=
, which want to use C++, should have the option to use a model, familiar to=
 them.</div><div><br></div><div>&quot;D<span style=3D"display:inline!import=
ant;float:none;background-color:transparent;color:rgb(34,34,34);font-family=
:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-sty=
le:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-al=
ign:left;text-decoration:none;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px">on&#39;t pay for what you don&#39;t use</span>&=
quot;, ok, but what if I the user <i>wants</i> to pay? Where are his potion=
s?!? &quot;Fake it&quot; using shared_ptr?</div><div><div>Besides, it is no=
t like CoW objects don&#39;t have intrinsic value on their own like never-n=
ull, value semantics and cheap copy. =C2=A0<br></div></div><div><b></b><i><=
/i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><b>Sidenote=
</b>, funny how<i> even Rust</i> could not get away without a=C2=A0<font fa=
ce=3D"courier new,monospace">std::borrow::Cow</font>, and that, after they =
tried to reinvent lifetime management.</div><div>This leaves C++ arguably t=
he only high level language without this kind of lifetime management in its=
 toolbox. This is not a win.</div><div><br></div></div></blockquote><div>=
=C2=A0</div><div>Teach them Rust then.</div><div>Hopefully the cultural sho=
ck won&#39;t be too much when they find out it isn&#39;t the same as $FAVOU=
RITE_LANGUAGE.</div></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/CAFQaeCAaQteSVGrd5L4dwf4tn%2BitEO9bUi=
Ut9dUJk%3D17d6YXFw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAaQteS=
VGrd5L4dwf4tn%2BitEO9bUiUt9dUJk%3D17d6YXFw%40mail.gmail.com</a>.<br />

--00000000000033e15a05716e17c2--

.

------=_Part_5457_1319685563.1532093774140
Content-Type: multipart/alternative;
 boundary="----=_Part_5458_297338193.1532093774140"

------=_Part_5458_297338193.1532093774140
Content-Type: text/plain; charset="UTF-8"

On Friday, July 20, 2018 at 8:38:41 AM UTC-4, mihailn...@gmail.com wrote:
>
> On Friday, July 20, 2018 at 1:28:02 PM UTC+3, j c wrote:
>>
>> On Fri, Jul 20, 2018 at 8:27 AM, <mihailn...@gmail.com> wrote:
>>
>>> On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:
>>>>>
>>>>> On Thursday, 19 July 2018 13:04:43 PDT Matthew Woehlke wrote:
>>>>> > CoW is very much "out of vogue". Various folk these days claim that
>>>>> the
>>>>> > cost of an atomic pointer increment is extremely high (which is
>>>>> mostly
>>>>> > true) while the cost of making deep copies of things is much lower
>>>>> than
>>>>> > it used to be, if indeed it was ever high to begin with.
>>>>>
>>>>> The problem was when you compared the two. For example, a function
>>>>> that
>>>>> returns a container by value was forced to make a copy before C++11,
>>>>> then
>>>>> destroy the original. The pair of atomic operation is usually cheaper
>>>>> than the
>>>>> memory allocation alone, not even counting the actual element copy.
>>>>>
>>>>> But since C++11 and move semantics, the return by value uses the move
>>>>> constructor of the type in question and those can be faster than the
>>>>> pair of
>>>>> atomics. Then again, CoW containers also get move constructors and
>>>>> then are
>>>>> just as efficient.
>>>>>
>>>>> The problem for non-CoW is that all programmers are not created equal.
>>>>> There
>>>>> are quite a few who do not write efficient C++ code and often trip
>>>>> into
>>>>> causing copies of containers. The use of CoW allows the container not
>>>>> to deep-
>>>>> copy unless there's a need to.
>>>>>
>>>>> On the other hand, the other problem for CoW is the unexpected memory
>>>>> allocation: any non-const function can cause the shared container to
>>>>> stop
>>>>> sharing, which means all non-const operations (including operator[])
>>>>> can
>>>>> potentially throw. Now, Qt doesn't care about exceptions, so this
>>>>> isn't a
>>>>> problem, but in terms of code expansion and timing consistency, it can
>>>>> be
>>>>> surprising.
>>>>>
>>>>
>>>> Throwing isn't necessarily the biggest issue with regard to CoW's
>>>> allocations. Unexpected memory allocation is basically unacceptable if you
>>>> want to have some reasonable guarantee of an APIs latency. SG14 is debating
>>>> adding insertion functions to `vector` that *can't* allocate memory.
>>>> This would allow users to be able to have APIs with static guarantees that
>>>> "unexpected memory allocation" will never occur.
>>>>
>>>> From a low-latency perspective, CoW is a *bad* idea.
>>>>
>>>
>>> CoW is the most user friendly memory management - it is the bridge that
>>> can (and does) bring b/w CG and (A)RC languages and C++ closer together.
>>>
>>
>> People don't use C++ for its user friendliness. C++ doesn't need to be
>> brought closer to GC languages, what it does need is a similarly rich set
>> of libraries
>> so that users can get up and running far more quickly.
>>
>>
>>> I am NOT saying std should be CoW, but it will be great to finally
>>> acknowledge the most popular memory management on the planet and provide
>>> tools for the users to CoW their objects.
>>>
>>> Intrusive Pointers was a step in the right direction, but way, way too
>>> small one - it still needs an expert to build a CoW-managed object.
>>> That should not be the case, if C++ tries to be competitive - the user
>>> should have full spectrum of options on his disposal, and CoW is one of the
>>> major ones.
>>>
>>> Care for the low-latency crowd should not be on the expense of
>>> mainstream high-level programming, otherwise C++ will corner itself into a
>>> niche for absolutely no good reason.
>>>
>>
>> There's already little reason to use C++ for anything 'mainstream'.
>> You're likely to be far more productive and stress-free with other
>> languages, and this isn't because of memory management. People only choose
>> C++ for something only if they truly need it. If you want Java, use Java.
>>
>
> Why should developers be forced into another languages when C++ can cover
> their needs with some additional tools?
> Why should developers, coming from GC/RC languages be force into cultural
> shock instead offering tools for smooth transition?
>

Culture shock is actually helpful in this case. I find that learning a
language that is *very* different from what I know to be much easier than
learning a language that is *deceptively similar* to what I know. If I
think the idioms from my old language work the same way in my new one, then
I'm going to put myself in autopilot and ignore the places where they're
different. But if the new language is significantly different, then I know
I have to start my thinking from scratch.

--
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/227e7e9e-b8e6-4baa-a2da-f1f11e650b7a%40isocpp.org.

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

<div dir=3D"ltr">On Friday, July 20, 2018 at 8:38:41 AM UTC-4, mihailn...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Friday, July 20, 2018 at 1:28:02 PM UTC+3, j c 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"><div><div class=3D"gmail_quote">On =
Fri, Jul 20, 2018 at 8:27 AM,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">mi=
hailn...@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"ltr"><div><div>On Friday, July 20, 2018 at 6:17:17 AM UTC+3, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On=
 Thursday, July 19, 2018 at 9:46:45 PM UTC-4, Thiago Macieira wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">On Thursday, 19 July 2018 13:04:43 PDT Mat=
thew Woehlke wrote:
<br>&gt; CoW is very much &quot;out of vogue&quot;. Various folk these days=
 claim that the
<br>&gt; cost of an atomic pointer increment is extremely high (which is mo=
stly
<br>&gt; true) while the cost of making deep copies of things is much lower=
 than
<br>&gt; it used to be, if indeed it was ever high to begin with.
<br>
<br>The problem was when you compared the two. For example, a function that=
=20
<br>returns a container by value was forced to make a copy before C++11, th=
en=20
<br>destroy the original. The pair of atomic operation is usually cheaper t=
han the=20
<br>memory allocation alone, not even counting the actual element copy.
<br>
<br>But since C++11 and move semantics, the return by value uses the move=
=20
<br>constructor of the type in question and those can be faster than the pa=
ir of=20
<br>atomics. Then again, CoW containers also get move constructors and then=
 are=20
<br>just as efficient.
<br>
<br>The problem for non-CoW is that all programmers are not created equal. =
There=20
<br>are quite a few who do not write efficient C++ code and often trip into=
=20
<br>causing copies of containers. The use of CoW allows the container not t=
o deep-
<br>copy unless there&#39;s a need to.
<br>
<br>On the other hand, the other problem for CoW is the unexpected memory=
=20
<br>allocation: any non-const function can cause the shared container to st=
op=20
<br>sharing, which means all non-const operations (including operator[]) ca=
n=20
<br>potentially throw. Now, Qt doesn&#39;t care about exceptions, so this i=
sn&#39;t a=20
<br>problem, but in terms of code expansion and timing consistency, it can =
be=20
<br>surprising.
<br></blockquote><div><br></div><div>Throwing isn&#39;t necessarily the big=
gest issue with regard to CoW&#39;s allocations. Unexpected memory allocati=
on is basically unacceptable if you want to have some reasonable guarantee =
of an APIs latency. SG14 is debating adding insertion functions to `vector`=
 that <i>can&#39;t</i> allocate memory. This would allow users to be able t=
o have APIs with static guarantees that &quot;unexpected memory allocation&=
quot; will never occur.</div><div><br></div><div></div><div>From a low-late=
ncy perspective, CoW is a <i>bad</i> idea.</div></div></blockquote><div><br=
></div></div></div><div>CoW is the most user friendly memory management - i=
t is the bridge that can (and does) bring b/w CG and (A)RC languages and C+=
+ closer together.<br></div></div></blockquote><div><br></div><div>People d=
on&#39;t use C++ for its user friendliness. C++ doesn&#39;t need to be brou=
ght closer to GC languages, what it does need is a similarly rich set of li=
braries</div><div>so that users can get up and running far more quickly.</d=
iv><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"><div></=
div><div>I am NOT saying std should be CoW, but it will be great to finally=
 acknowledge the most popular memory management on the planet and provide t=
ools for the users to CoW their objects.</div><div><br></div><div>Intrusive=
 Pointers was a step in the right direction, but way, way too small one - i=
t still needs an expert to build a CoW-managed object.=C2=A0<br></div><div>=
That should not be the case, if C++ tries to be competitive - the user shou=
ld have full spectrum of options on his disposal, and CoW is one of the maj=
or ones.</div><div><br></div><div>Care for the=C2=A0<span style=3D"display:=
inline!important;float:none;background-color:transparent;color:rgb(34,34,34=
);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:=
13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:n=
ormal;text-align:left;text-decoration:none;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px">low-latency crowd should not be on=
 the expense of mainstream high-level programming, otherwise C++ will corne=
r itself into a niche for absolutely no good reason.=C2=A0</span></div></di=
v></blockquote><div><br></div><div>There&#39;s already little reason to use=
 C++ for anything &#39;mainstream&#39;. You&#39;re likely to be far more pr=
oductive and stress-free with other languages, and this isn&#39;t because o=
f memory management. People only choose C++ for something only if they trul=
y need it. If you want Java, use Java.</div></div></div></div></blockquote>=
<div><br></div><div>Why should developers be forced into another languages =
when C++ can cover their needs with some additional tools?</div><div>Why sh=
ould developers, coming from GC/RC languages be force into cultural shock i=
nstead offering tools for smooth transition?</div></div></blockquote><div><=
br></div><div>Culture shock is actually helpful in this case. I find that l=
earning a language that is <i>very</i> different from what I know to be muc=
h easier than learning a language that is <i>deceptively similar</i> to wha=
t I know. If I think the idioms from my old language work the same way in m=
y new one, then I&#39;m going to put myself in autopilot and ignore the pla=
ces where they&#39;re different. But if the new language is significantly d=
ifferent, then I know I have to start my thinking from scratch.<br></div><b=
r></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/227e7e9e-b8e6-4baa-a2da-f1f11e650b7a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/227e7e9e-b8e6-4baa-a2da-f1f11e650b7a=
%40isocpp.org</a>.<br />

------=_Part_5458_297338193.1532093774140--

------=_Part_5457_1319685563.1532093774140--

.