Topic: Allow .data() to be called on reserved, but
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 21 Jul 2017 20:32:46 -0700 (PDT)
Raw View
------=_Part_1980_1227676693.1500694367062
Content-Type: multipart/alternative;
boundary="----=_Part_1981_807415194.1500694367062"
------=_Part_1981_807415194.1500694367062
Content-Type: text/plain; charset="UTF-8"
On Friday, July 21, 2017 at 10:40:25 PM UTC-4, stevem...@gmail.com wrote:
>
> Sometimes when using vectors in low-level embedded land it is nice to know
> where the underlying buffer of a vector is before any data exists in the
> vector. As it stands it is not possible to do this, even if first calling
> reserve.
>
> ....
>
> This will allow people to grab a pointer to the underlying buffer of a
> vector if and only if they have reserved space first. I suspect many people
> incorrectly expect one of the above methods I have listed to work as
> intended (though they do not).
>
To what end?
OK, let's say that we allow you to get a pointer to that buffer. What are
you going to do with it? Nothing that's legal in C++, that's for sure.
After all, the standard specifically states that the return from `data` is:
> A pointer such that [data(), data() + size()) is a valid range.
Since `size` is zero, that will be an empty range.
But let's pretend that we allowed you to access up to `capacity` rather
than `size`. What good is that? First, there are no `T`'s past the end of
the sequence. So pointer arithmetic in that region is dubious, and you
can't just write to objects that don't exist.
But equally importantly, there's this:
vector<int> v;
v.reserve(10);
memcpy(v.data(), ..., 10 * sizeof(int));
v.resize(10);
OK, pop-quiz: what values does `v` contain? Here's a hint: it's *not* what
was copied into the reserved space.
`vector::resize`, will copy/move a value if you provide it. And if you
don't, then it will value-initialize the inserted elements. And therefore,
`v.resize(10)` will overwrite everything the `memcpy` wrote.
`vector` has no way to resize itself without overwriting what was in the
reserved space.
What you *really* want is a way to default-initialize the members of a
`vector`, then fill them in at your leisure:
vector<int> v(10, std::default_init);
memcpy(v.data(), ..., 10 * sizeof(int));
It'd be much better to introduce a way to default-initialize members of
containers. And objects of all types.
--
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/1b85330d-9504-4ac5-9c94-aeb34cbc5e3c%40isocpp.org.
------=_Part_1981_807415194.1500694367062
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, July 21, 2017 at 10:40:25 PM UTC-4, ste=
vem...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">Sometimes when using vectors in low-level embedded land it is nic=
e to know where the underlying buffer of a vector is before any data exists=
in the vector. As it stands it is not possible to do this, even if first c=
alling reserve.<div><br></div>....<br><div><span style=3D"font-family:"=
;Open Sans",SegoeUI,sans-serif;font-size:12.8px"><br></span></div><div=
><span style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-s=
ize:12.8px">This will allow people to grab a pointer to the underlying buff=
er of a vector if and only if they have reserved space first. I suspect man=
y people incorrectly expect one of the above methods I have listed to work =
as intended (though they do not).</span></div></div></blockquote><div><br>T=
o what end?<br><br>OK, let's say that we allow you to get a pointer to =
that buffer. What are you going to do with it? Nothing that's legal in =
C++, that's for sure.<br><br>After all, the standard specifically state=
s that the return from `data` is:<br><br>>=C2=A0 A pointer such that [da=
ta(), data() + size()) is a valid range.<br><br>Since `size` is zero, that =
will be an empty range.<br><br>But let's pretend that we allowed you to=
access up to `capacity` rather than `size`. What good is that? First, ther=
e are no `T`'s past the end of the sequence. So pointer arithmetic in t=
hat region is dubious, and you can't just write to objects that don'=
;t exist.<br><br>But equally importantly, there's this:<br><br><div sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; overflow-wrap: break-word;" clas=
s=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify"><int></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>v</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">reserve</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">10</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>memcpy</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">data</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">...,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">10</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">));</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>v</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">resize</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">10<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></=
div></code></div><br>OK, pop-quiz: what values does `v` contain? Here's=
a hint: it's <i>not</i> what was copied into the reserved space.<br><b=
r>`vector::resize`, will copy/move a value if you provide it. And if you do=
n't, then it will value-initialize the inserted elements. And therefore=
, `v.resize(10)` will overwrite everything the `memcpy` wrote.<br><br>`vect=
or` has no way to resize itself without overwriting what was in the reserve=
d space.<br><br>What you <i>really</i> want is a way to default-initialize =
the members of a `vector`, then fill them in at your leisure:<br><br><div s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; overflow-wrap: break-word;" cl=
ass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><=
span style=3D"color: #080;" class=3D"styled-by-prettify"><int></span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">10</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">default_init</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>memcpy</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">data</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">...,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">10</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">));</span></div></code></div><br>It'=
;d be much better to introduce a way to default-initialize members of conta=
iners. And objects of all types.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1b85330d-9504-4ac5-9c94-aeb34cbc5e3c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1b85330d-9504-4ac5-9c94-aeb34cbc5e3c=
%40isocpp.org</a>.<br />
------=_Part_1981_807415194.1500694367062--
------=_Part_1980_1227676693.1500694367062--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 20:45:19 -0700 (PDT)
Raw View
------=_Part_1765_925332468.1500695119932
Content-Type: multipart/alternative;
boundary="----=_Part_1766_365281344.1500695119932"
------=_Part_1766_365281344.1500695119932
Content-Type: text/plain; charset="UTF-8"
I really do want to get a pointer to that buffer. And for good reason. If i
can get a pointer to that buffer then i can use std::uninitiallized_copy to
fill it in at my leisure. There really are cases where I need to know the
memory address that my buffer lives at before I put anything into it.
Adding a default-initialization to all standard types would be cool, but I
hardly think that's the easiest solution to this issue. There's also cases
where I don't want to pay for this default initialization, if you give me a
way to fill that buffer myself and then tell vector it's change in size()
then there's no reason to pay for default initialization.
--
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/5832f567-f1da-43a4-b026-42997ebf40f2%40isocpp.org.
------=_Part_1766_365281344.1500695119932
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I really do want to get a pointer to that buffer. And for =
good reason. If i can get a pointer to that buffer then i can use std::unin=
itiallized_copy to fill it in at my leisure. There really are cases where I=
need to know the memory address that my buffer lives at before I put anyth=
ing into it. Adding a default-initialization to all standard types would be=
cool, but I hardly think that's the easiest solution to this issue. =
=C2=A0There's also cases where I don't want to pay for this default=
initialization, if you give me a way to fill that buffer myself and then t=
ell vector it's change in size() then there's no reason to pay for =
default initialization.</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5832f567-f1da-43a4-b026-42997ebf40f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5832f567-f1da-43a4-b026-42997ebf40f2=
%40isocpp.org</a>.<br />
------=_Part_1766_365281344.1500695119932--
------=_Part_1765_925332468.1500695119932--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jul 2017 22:45:27 -0500
Raw View
--001a114274ba726f960554dfd283
Content-Type: text/plain; charset="UTF-8"
On Fri, Jul 21, 2017 at 10:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Friday, July 21, 2017 at 10:40:25 PM UTC-4, stevem...@gmail.com wrote:
>>
>> Sometimes when using vectors in low-level embedded land it is nice to
>> know where the underlying buffer of a vector is before any data exists in
>> the vector. As it stands it is not possible to do this, even if first
>> calling reserve.
>>
>> ....
>>
>> This will allow people to grab a pointer to the underlying buffer of a
>> vector if and only if they have reserved space first. I suspect many people
>> incorrectly expect one of the above methods I have listed to work as
>> intended (though they do not).
>>
>
> To what end?
>
Um, you deleted his use case:
Assume now that i want to use the vector to hold assembly instructions.
> Various instructions' encoding are relative to their location in memory, so
> in order to encode them properly one must know where they are about to live
> inside the vector.
> OK, let's say that we allow you to get a pointer to that buffer. What are
> you going to do with it? Nothing that's legal in C++, that's for sure.
>
He wants to calculate future addresses, such as a branch forward. That
isn't unreasonable. Of course, I have no idea how he plans on executing
such code.
However, there is a fairly trivial workaround; namely, make the first
element of the vector a dummy element. Given that we want to discourage
people from filling in an empty vector by means other than
push_back/emplace_back/insert/emplace, it doesn't seem likely such a
proposal would get very far.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOiHRag1BAOKcTfGm8zXLdLi8CYnmVxMDM3ekS4WY0z5g%40mail.gmail.com.
--001a114274ba726f960554dfd283
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 21, 2017 at 10:32 PM, Nicol Bolas <span dir=3D=
"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-"><=
br><br>On Friday, July 21, 2017 at 10:40:25 PM UTC-4, <a href=3D"mailto:ste=
vem...@gmail.com" target=3D"_blank">stevem...@gmail.com</a> wrote:</span><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-">Sometimes when using=
vectors in low-level embedded land it is nice to know where the underlying=
buffer of a vector is before any data exists in the vector. As it stands i=
t is not possible to do this, even if first calling reserve.<div><br></div>=
</span>....<span class=3D"gmail-"><br><div><span style=3D"font-family:'=
Open Sans',SegoeUI,sans-serif;font-size:12.8px"><br></span></div><div><=
span style=3D"font-family:'Open Sans',SegoeUI,sans-serif;font-size:=
12.8px">This will allow people to grab a pointer to the underlying buffer o=
f a vector if and only if they have reserved space first. I suspect many pe=
ople incorrectly expect one of the above methods I have listed to work as i=
ntended (though they do not).</span></div></span></div></blockquote><div><b=
r>To what end?<br></div></div></blockquote><div><br></div><div>Um, you dele=
ted his use case:</div><div><br></div></div></div><blockquote style=3D"marg=
in:0px 0px 0px 40px;border:none;padding:0px"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><span style=3D"font-size:12.800000=
190734863px">Assume now that i want to use the vector to hold assembly inst=
ructions. Various instructions' encoding are relative to their location=
in memory, so in order to encode them properly one must know where they ar=
e about to live inside the vector.=C2=A0</span></blockquote></div></div></b=
lockquote><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div>OK, let's say that we =
allow you to get a pointer to that buffer. What are you going to do with it=
? Nothing that's legal in C++, that's for sure.<br></div></div></bl=
ockquote><div><br></div><div>He wants to calculate future addresses, such a=
s a branch forward.=C2=A0 That isn't unreasonable.=C2=A0 Of course, I h=
ave no idea how he plans on executing such code. =C2=A0</div><div><br></div=
><div>However, there is a fairly trivial workaround; namely, make the first=
element of the vector a dummy element.=C2=A0 Given that we want to discour=
age people from filling in an empty vector by means other than push_back/em=
place_back/insert/emplace, it doesn't seem likely such a proposal would=
get very far.</div></div>-- <br><div class=3D"gmail_signature"><div dir=3D=
"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 &l=
t;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@=
eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BOiHRag1BAOKcTfGm8zXLdLi8CYnm=
VxMDM3ekS4WY0z5g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOiHRag=
1BAOKcTfGm8zXLdLi8CYnmVxMDM3ekS4WY0z5g%40mail.gmail.com</a>.<br />
--001a114274ba726f960554dfd283--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 20:50:33 -0700 (PDT)
Raw View
------=_Part_1881_1293277235.1500695433454
Content-Type: multipart/alternative;
boundary="----=_Part_1882_1850727736.1500695433454"
------=_Part_1882_1850727736.1500695433454
Content-Type: text/plain; charset="UTF-8"
This is what i currently do but it's stupid. Vector's reserve already does
a 'real' allocation, there should be some way for me to query where this
buffer is. I just need an address so i know how to encode things, if you
return an int64_t that's cool too. But really there should be a way to know
where the buffer lives.
On Friday, July 21, 2017 at 11:46:10 PM UTC-4, Nevin ":-)" Liber wrote:
>
>
> However, there is a fairly trivial workaround; namely, make the first
> element of the vector a dummy element. Given that we want to discourage
> people from filling in an empty vector by means other than
> push_back/emplace_back/insert/emplace, it doesn't seem likely such a
> proposal would get very far.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>
> +1-847-691-1404
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc62f1d1-0612-4fb2-bf83-f344cbd101ea%40isocpp.org.
------=_Part_1882_1850727736.1500695433454
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is what i currently do but it's stupid. Vector=
9;s reserve already does a 'real' allocation, there should be some =
way for me to query where this buffer is. I just need an address so i know =
how to encode things, if you return an int64_t that's cool too. But rea=
lly there should be a way to know where the buffer lives.<br>On Friday, Jul=
y 21, 2017 at 11:46:10 PM UTC-4, Nevin ":-)" Liber wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote"><div><br></div><div>However, there is a fairly trivial workaroun=
d; namely, make the first element of the vector a dummy element.=C2=A0 Give=
n that we want to discourage people from filling in an empty vector by mean=
s other than push_back/emplace_back/insert/<wbr>emplace, it doesn't see=
m likely such a proposal would get very far.</div></div>-- <br><div><div di=
r=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"Ygjmttu6AwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">ne...@eviloverlord.com</a><wbr>> =C2=A0+1-847-691-1404</div></=
div></div></div></div>
</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/cc62f1d1-0612-4fb2-bf83-f344cbd101ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cc62f1d1-0612-4fb2-bf83-f344cbd101ea=
%40isocpp.org</a>.<br />
------=_Part_1882_1850727736.1500695433454--
------=_Part_1881_1293277235.1500695433454--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jul 2017 22:50:49 -0500
Raw View
--94eb2c07720e9ef9e00554dfe55b
Content-Type: text/plain; charset="UTF-8"
On Fri, Jul 21, 2017 at 10:45 PM, <stevemk14ebr@gmail.com> wrote:
> I really do want to get a pointer to that buffer. And for good reason. If
> i can get a pointer to that buffer then i can use std::uninitiallized_copy
> to fill it in at my leisure. There really are cases where I need to know
> the memory address that my buffer lives at before I put anything into it.
> Adding a default-initialization to all standard types would be cool, but I
> hardly think that's the easiest solution to this issue. There's also cases
> where I don't want to pay for this default initialization, if you give me a
> way to fill that buffer myself and then tell vector it's change in size()
> then there's no reason to pay for default initialization.
>
Oh, you wish to break vector's invariants. I am now strongly against this.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN9tMA09YiR22-rdqG%3D3zpRZ%3D0qdFt1%2BM21MRpcy%3D%2BEZg%40mail.gmail.com.
--94eb2c07720e9ef9e00554dfe55b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 21, 2017 at 10:45 PM, <span dir=3D"ltr"><<=
a href=3D"mailto:stevemk14ebr@gmail.com" target=3D"_blank">stevemk14ebr@gma=
il.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I really do want=
to get a pointer to that buffer. And for good reason. If i can get a point=
er to that buffer then i can use std::uninitiallized_copy to fill it in at =
my leisure. There really are cases where I need to know the memory address =
that my buffer lives at before I put anything into it. Adding a default-ini=
tialization to all standard types would be cool, but I hardly think that=
9;s the easiest solution to this issue.=C2=A0 There's also cases where =
I don't want to pay for this default initialization, if you give me a w=
ay to fill that buffer myself and then tell vector it's change in size(=
) then there's no reason to pay for default initialization.</div></bloc=
kquote><div><br></div><div>Oh, you wish to break vector's invariants.=
=C2=A0 I am now strongly against this.</div></div>-- <br><div class=3D"gmai=
l_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div =
dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>> =C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BN9tMA09YiR22-rdqG%3D3zpRZ%3D=
0qdFt1%2BM21MRpcy%3D%2BEZg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAG=
g_6%2BN9tMA09YiR22-rdqG%3D3zpRZ%3D0qdFt1%2BM21MRpcy%3D%2BEZg%40mail.gmail.c=
om</a>.<br />
--94eb2c07720e9ef9e00554dfe55b--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 20:53:55 -0700 (PDT)
Raw View
------=_Part_1918_1290764096.1500695635087
Content-Type: multipart/alternative;
boundary="----=_Part_1919_2106604045.1500695635087"
------=_Part_1919_2106604045.1500695635087
Content-Type: text/plain; charset="UTF-8"
This is all well and good from a puritan standpoint. But at the end of the
day people use the STL for real world things and from embedded land I can
tell you that I need to know where my buffer is.
On Friday, July 21, 2017 at 11:51:32 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On Fri, Jul 21, 2017 at 10:45 PM, <stevem...@gmail.com <javascript:>>
> wrote:
>
>> I really do want to get a pointer to that buffer. And for good reason. If
>> i can get a pointer to that buffer then i can use std::uninitiallized_copy
>> to fill it in at my leisure. There really are cases where I need to know
>> the memory address that my buffer lives at before I put anything into it.
>> Adding a default-initialization to all standard types would be cool, but I
>> hardly think that's the easiest solution to this issue. There's also cases
>> where I don't want to pay for this default initialization, if you give me a
>> way to fill that buffer myself and then tell vector it's change in size()
>> then there's no reason to pay for default initialization.
>>
>
> Oh, you wish to break vector's invariants. I am now strongly against this.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>
> +1-847-691-1404
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bc976586-ba03-4236-9cfa-d10dbff047ce%40isocpp.org.
------=_Part_1919_2106604045.1500695635087
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is all well and good from a puritan=C2=A0standpoint. =
But at the end of the day people use the STL for real world things and from=
embedded land I can tell you that I need to know where my buffer is.=C2=A0=
<br><br>On Friday, July 21, 2017 at 11:51:32 PM UTC-4, Nevin ":-)"=
; Liber 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 Fri, Jul 21, 2017 at 10:45 PM, <span dir=3D"ltr"><<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"VPiutSa7AwAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">stevem...@gmail.com</a=
>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">I really do want to get a pointer to that buffe=
r. And for good reason. If i can get a pointer to that buffer then i can us=
e std::uninitiallized_copy to fill it in at my leisure. There really are ca=
ses where I need to know the memory address that my buffer lives at before =
I put anything into it. Adding a default-initialization to all standard typ=
es would be cool, but I hardly think that's the easiest solution to thi=
s issue.=C2=A0 There's also cases where I don't want to pay for thi=
s default initialization, if you give me a way to fill that buffer myself a=
nd then tell vector it's change in size() then there's no reason to=
pay for default initialization.</div></blockquote><div><br></div><div>Oh, =
you wish to break vector's invariants.=C2=A0 I am now strongly against =
this.</div></div>-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=
=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"VPiutSa7AwAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">ne...@eviloverlord.com</a><wb=
r>> =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/bc976586-ba03-4236-9cfa-d10dbff047ce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bc976586-ba03-4236-9cfa-d10dbff047ce=
%40isocpp.org</a>.<br />
------=_Part_1919_2106604045.1500695635087--
------=_Part_1918_1290764096.1500695635087--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 21 Jul 2017 20:57:29 -0700 (PDT)
Raw View
------=_Part_1876_16971796.1500695849657
Content-Type: multipart/alternative;
boundary="----=_Part_1877_1261731034.1500695849657"
------=_Part_1877_1261731034.1500695849657
Content-Type: text/plain; charset="UTF-8"
On Friday, July 21, 2017 at 11:53:55 PM UTC-4, stevem...@gmail.com wrote:
>
> This is all well and good from a puritan standpoint. But at the end of the
> day people use the STL for real world things and from embedded land I can
> tell you that I need to know where my buffer is.
>
But we can get the *exact same thing* without breaking those invariants. So
why do it the anti-puritan way when you can get it done and still be
puritan?
Does it really matter that much that it be done exactly the way you want it
done? What matters is that it has the desired performance.
--
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/ba7d89c4-2da0-40fc-8ec7-3e6f1f2a2bc1%40isocpp.org.
------=_Part_1877_1261731034.1500695849657
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, July 21, 2017 at 11:53:55 PM UTC-4, stevem...@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=
">This is all well and good from a puritan=C2=A0standpoint. But at the end =
of the day people use the STL for real world things and from embedded land =
I can tell you that I need to know where my buffer is.=C2=A0<br></div></blo=
ckquote><div><br>But we can get the <i>exact same thing</i> without breakin=
g those invariants. So why do it the anti-puritan way when you can get it d=
one and still be puritan?<br><br>Does it really matter that much that it be=
done exactly the way you want it done? What matters is that it has the des=
ired performance.</div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ba7d89c4-2da0-40fc-8ec7-3e6f1f2a2bc1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba7d89c4-2da0-40fc-8ec7-3e6f1f2a2bc1=
%40isocpp.org</a>.<br />
------=_Part_1877_1261731034.1500695849657--
------=_Part_1876_16971796.1500695849657--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 21:00:19 -0700 (PDT)
Raw View
------=_Part_1924_994750057.1500696019613
Content-Type: multipart/alternative;
boundary="----=_Part_1925_1793029069.1500696019613"
------=_Part_1925_1793029069.1500696019613
Content-Type: text/plain; charset="UTF-8"
If adding default initialization to all the types actually happens then i'm
totally for it. I'm weighing the probability of this actually happening. It
seems like doing something like that would come around in C++ 30, while
this could be done tomorrow.
On Friday, July 21, 2017 at 11:57:29 PM UTC-4, Nicol Bolas wrote:
>
> On Friday, July 21, 2017 at 11:53:55 PM UTC-4, stevem...@gmail.com wrote:
>>
>> This is all well and good from a puritan standpoint. But at the end of
>> the day people use the STL for real world things and from embedded land I
>> can tell you that I need to know where my buffer is.
>>
>
> But we can get the *exact same thing* without breaking those invariants.
> So why do it the anti-puritan way when you can get it done and still be
> puritan?
>
> Does it really matter that much that it be done exactly the way you want
> it done? What matters is that it has the desired performance.
>
>
--
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/8e14b9ae-097c-4b0c-8814-eea44f2c6c6a%40isocpp.org.
------=_Part_1925_1793029069.1500696019613
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If adding default initialization to all the types actually=
happens then i'm totally for it. I'm weighing the probability of t=
his actually happening. It seems like doing something like that would come =
around in C++ 30, while this could be done tomorrow.<br><br>On Friday, July=
21, 2017 at 11:57:29 PM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr">On Friday, July 21, 2017 at 11:53:55 P=
M UTC-4, <a>stevem...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">This is all well and good from a puritan=C2=A0stand=
point. But at the end of the day people use the STL for real world things a=
nd from embedded land I can tell you that I need to know where my buffer is=
..=C2=A0<br></div></blockquote><div><br>But we can get the <i>exact same thi=
ng</i> without breaking those invariants. So why do it the anti-puritan way=
when you can get it done and still be puritan?<br><br>Does it really matte=
r that much that it be done exactly the way you want it done? What matters =
is that it has the desired performance.</div><br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/8e14b9ae-097c-4b0c-8814-eea44f2c6c6a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8e14b9ae-097c-4b0c-8814-eea44f2c6c6a=
%40isocpp.org</a>.<br />
------=_Part_1925_1793029069.1500696019613--
------=_Part_1924_994750057.1500696019613--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jul 2017 23:01:47 -0500
Raw View
--001a11441afacf327e0554e00c76
Content-Type: text/plain; charset="UTF-8"
On Fri, Jul 21, 2017 at 10:53 PM, <stevemk14ebr@gmail.com> wrote:
> This is all well and good from a puritan standpoint.
>
It has nothing to do with a puritan standpoint.
If you, for instance, copy the vector, copy will not do the right thing.
Heck, every querying function in vector (size(), empty(), at(), etc.)
except for data() would do the wrong thing. What a horrible library design
that would be.
> But at the end of the day people use the STL for real world things and
> from embedded land I can tell you that I need to know where my buffer is.
>
It isn't hard to write your own class which holds a unique_ptr and a
length. No need to abuse vector for this.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPL-%2BKp_BVST1vnaQd5qWZQK8_59L8bDXeDLQSO%2Bp-qtA%40mail.gmail.com.
--001a11441afacf327e0554e00c76
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 21, 2017 at 10:53 PM, <span dir=3D"ltr"><<=
a href=3D"mailto:stevemk14ebr@gmail.com" target=3D"_blank">stevemk14ebr@gma=
il.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr">This is all well and good from=
a puritan=C2=A0standpoint. </div></blockquote><div><br></div><div>It has n=
othing to do with a puritan standpoint.</div><div><br></div><div>If you, fo=
r instance, copy the vector, copy will not do the right thing.=C2=A0 Heck, =
every querying function in vector (size(), empty(), at(), etc.) except for =
data() would do the wrong thing.=C2=A0 What a horrible library design that =
would be.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">But at th=
e end of the day people use the STL for real world things and from embedded=
land I can tell you that I need to know where my buffer is.=C2=A0<br></div=
></blockquote><div><br></div><div>It isn't hard to write your own class=
which holds a unique_ptr and a length.=C2=A0 No need to abuse vector for t=
his.</div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<=
a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlo=
rd.com</a>> =C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BPL-%2BKp_BVST1vnaQd5qWZQK8_5=
9L8bDXeDLQSO%2Bp-qtA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPL=
-%2BKp_BVST1vnaQd5qWZQK8_59L8bDXeDLQSO%2Bp-qtA%40mail.gmail.com</a>.<br />
--001a11441afacf327e0554e00c76--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 21 Jul 2017 21:05:26 -0700 (PDT)
Raw View
------=_Part_1754_1731511577.1500696326696
Content-Type: multipart/alternative;
boundary="----=_Part_1755_550601265.1500696326697"
------=_Part_1755_550601265.1500696326697
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 22, 2017 at 12:00:19 AM UTC-4, stevem...@gmail.com wrote:
>
> If adding default initialization to all the types actually happens then
> i'm totally for it. I'm weighing the probability of this actually
> happening. It seems like doing something like that would come around in C++
> 30, while this could be done tomorrow.
>
I *really* hate when people do that. When people say, "Oh, I know we *ought*
to fix the problem directly, but I believe that the standards committee
would never go for that, so instead let's do a pre-compromised half-measure
that only works for a select few things."
Start with what you actually want, *then* compromise down if it becomes
necessary. Assuming that something will fail before trying it doesn't help
anyone.
It's also not actually true. The standards committee doesn't usually take a
long time to decide if they want a feature or not. If they don't see it as
acceptable at all, that tends to be decided rather quickly.
Also, please don't top-post.
>
> On Friday, July 21, 2017 at 11:57:29 PM UTC-4, Nicol Bolas wrote:
>>
>> On Friday, July 21, 2017 at 11:53:55 PM UTC-4, stevem...@gmail.com wrote:
>>>
>>> This is all well and good from a puritan standpoint. But at the end of
>>> the day people use the STL for real world things and from embedded land I
>>> can tell you that I need to know where my buffer is.
>>>
>>
>> But we can get the *exact same thing* without breaking those invariants.
>> So why do it the anti-puritan way when you can get it done and still be
>> puritan?
>>
>> Does it really matter that much that it be done exactly the way you want
>> it done? What matters is that it has the desired performance.
>>
>>
--
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/5d2c573d-7a74-4ccc-a3e0-0204e3f7b161%40isocpp.org.
------=_Part_1755_550601265.1500696326697
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, July 22, 2017 at 12:00:19 AM UTC-4, stevem...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">If adding default initialization to all the types actually happens then=
i'm totally for it. I'm weighing the probability of this actually =
happening. It seems like doing something like that would come around in C++=
30, while this could be done tomorrow.<br></div></blockquote><div><br>I <i=
>really</i> hate when people do that. When people say, "Oh, I know we =
<i>ought</i> to fix the problem directly, but I believe that the standards =
committee would never go for that, so instead let's do a pre-compromise=
d half-measure that only works for a select few things."<br><br>Start =
with what you actually want, <i>then</i> compromise down if it becomes nece=
ssary. Assuming that something will fail before trying it doesn't help =
anyone.<br><br>It's also not actually true. The standards committee doe=
sn't usually take a long time to decide if they want a feature or not. =
If they don't see it as acceptable at all, that tends to be decided rat=
her quickly.<br><br>Also, please don't top-post.<br>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>On Friday, July =
21, 2017 at 11:57:29 PM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Friday, July 21, 2017 at 11:53:55 PM UTC-=
4, <a>stevem...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">This is all well and good from a puritan=C2=A0standpoint.=
But at the end of the day people use the STL for real world things and fro=
m embedded land I can tell you that I need to know where my buffer is.=C2=
=A0<br></div></blockquote><div><br>But we can get the <i>exact same thing</=
i> without breaking those invariants. So why do it the anti-puritan way whe=
n you can get it done and still be puritan?<br><br>Does it really matter th=
at much that it be done exactly the way you want it done? What matters is t=
hat it has the desired performance.</div><br></div></blockquote></div></blo=
ckquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d2c573d-7a74-4ccc-a3e0-0204e3f7b161%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d2c573d-7a74-4ccc-a3e0-0204e3f7b161=
%40isocpp.org</a>.<br />
------=_Part_1755_550601265.1500696326697--
------=_Part_1754_1731511577.1500696326696--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 21:05:58 -0700 (PDT)
Raw View
------=_Part_1882_1809943866.1500696358245
Content-Type: multipart/alternative;
boundary="----=_Part_1883_1132999719.1500696358245"
------=_Part_1883_1132999719.1500696358245
Content-Type: text/plain; charset="UTF-8"
I'm more than aware this is currently not safe that is *WHY* i made this
thread, so that this vectors can morph into a thing that can finally
replace C style arrays. As it is I am forced to use C style arrays, memcpy
into them, and then construct a vector from that. STL vectors already do
99% of anything a C style array can do, if we add just a tiny bit more then
C style arrays will finally have no real use case. I don't care AT ALL how
that happens, just let me memcpy into a vector by calling reserve and i'll
be a happy man.
On Saturday, July 22, 2017 at 12:02:29 AM UTC-4, Nevin ":-)" Liber wrote:
>
> On Fri, Jul 21, 2017 at 10:53 PM, <stevem...@gmail.com <javascript:>>
> wrote:
>
>> This is all well and good from a puritan standpoint.
>>
>
> It has nothing to do with a puritan standpoint.
>
> If you, for instance, copy the vector, copy will not do the right thing.
> Heck, every querying function in vector (size(), empty(), at(), etc.)
> except for data() would do the wrong thing. What a horrible library design
> that would be.
>
>
>> But at the end of the day people use the STL for real world things and
>> from embedded land I can tell you that I need to know where my buffer is.
>>
>
> It isn't hard to write your own class which holds a unique_ptr and a
> length. No need to abuse vector for this.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>
> +1-847-691-1404
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dc4823ef-122a-4f97-bb64-2dc8bb8521b0%40isocpp.org.
------=_Part_1883_1132999719.1500696358245
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm more than aware this is currently not safe that is=
<i>WHY</i>=C2=A0i made this thread, so that this vectors can morph into a =
thing that can finally replace C style arrays. As it is I am forced to use =
C style arrays, memcpy into them, and then construct a vector from that. ST=
L vectors already do 99% of anything a C style array can do, if we add just=
a tiny bit more then C style arrays will finally have no real use case. I =
don't care AT ALL how that happens, just let me memcpy into a vector by=
calling reserve and i'll be a happy man. =C2=A0<br><br>On Saturday, Ju=
ly 22, 2017 at 12:02:29 AM UTC-4, Nevin ":-)" Liber wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Fri, Jul 21, 2017=
at 10:53 PM, <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"4EnAqb-7AwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">stevem...@gmail.com</a>></span> wrote:<b=
r><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">This =
is all well and good from a puritan=C2=A0standpoint. </div></blockquote><di=
v><br></div><div>It has nothing to do with a puritan standpoint.</div><div>=
<br></div><div>If you, for instance, copy the vector, copy will not do the =
right thing.=C2=A0 Heck, every querying function in vector (size(), empty()=
, at(), etc.) except for data() would do the wrong thing.=C2=A0 What a horr=
ible library design that would be.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr">But at the end of the day people use the STL for real worl=
d things and from embedded land I can tell you that I need to know where my=
buffer is.=C2=A0<br></div></blockquote><div><br></div><div>It isn't ha=
rd to write your own class which holds a unique_ptr and a length.=C2=A0 No =
need to abuse vector for this.</div></div>-- <br><div><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"4EnAqb-7A=
wAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retu=
rn true;" onclick=3D"this.href=3D'javascript:';return true;">ne...@=
eviloverlord.com</a><wbr>> =C2=A0+1-847-691-1404</div></div></div></div>=
</div>
</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/dc4823ef-122a-4f97-bb64-2dc8bb8521b0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dc4823ef-122a-4f97-bb64-2dc8bb8521b0=
%40isocpp.org</a>.<br />
------=_Part_1883_1132999719.1500696358245--
------=_Part_1882_1809943866.1500696358245--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 21 Jul 2017 21:08:06 -0700 (PDT)
Raw View
------=_Part_1910_522933869.1500696486730
Content-Type: multipart/alternative;
boundary="----=_Part_1911_1247271420.1500696486730"
------=_Part_1911_1247271420.1500696486730
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 22, 2017 at 12:05:58 AM UTC-4, stevem...@gmail.com wrote:
>
> I'm more than aware this is currently not safe that is *WHY* i made this
> thread, so that this vectors can morph into a thing that can finally
> replace C style arrays. As it is I am forced to use C style arrays, memcpy
> into them, and then construct a vector from that. STL vectors already do
> 99% of anything a C style array can do, if we add just a tiny bit more then
> C style arrays will finally have no real use case. I don't care AT ALL how
> that happens, just let me memcpy into a vector by calling reserve and i'll
> be a happy man.
>
But that's not what you want. What you want is to create a vector without
initializing its contents (for contents which can go uninitialized).
--
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/897eb062-f3ec-4afa-9bd7-49bef42a69a0%40isocpp.org.
------=_Part_1911_1247271420.1500696486730
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, July 22, 2017 at 12:05:58 AM UTC-4, stevem...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">I'm more than aware this is currently not safe that is <i>WHY</i>=
=C2=A0i made this thread, so that this vectors can morph into a thing that =
can finally replace C style arrays. As it is I am forced to use C style arr=
ays, memcpy into them, and then construct a vector from that. STL vectors a=
lready do 99% of anything a C style array can do, if we add just a tiny bit=
more then C style arrays will finally have no real use case. I don't c=
are AT ALL how that happens, just let me memcpy into a vector by calling re=
serve and i'll be a happy man.<br></div></blockquote><div><br>But that&=
#39;s not what you want. What you want is to create a vector without initia=
lizing its contents (for contents which can go uninitialized).</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/897eb062-f3ec-4afa-9bd7-49bef42a69a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/897eb062-f3ec-4afa-9bd7-49bef42a69a0=
%40isocpp.org</a>.<br />
------=_Part_1911_1247271420.1500696486730--
------=_Part_1910_522933869.1500696486730--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 21:11:02 -0700 (PDT)
Raw View
------=_Part_645_803320022.1500696662306
Content-Type: multipart/alternative;
boundary="----=_Part_646_1485455103.1500696662306"
------=_Part_646_1485455103.1500696662306
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 22, 2017 at 12:08:06 AM UTC-4, Nicol Bolas wrote:
>
> On Saturday, July 22, 2017 at 12:05:58 AM UTC-4, stevem...@gmail.com
> wrote:
>>
>> I'm more than aware this is currently not safe that is *WHY* i made this
>> thread, so that this vectors can morph into a thing that can finally
>> replace C style arrays. As it is I am forced to use C style arrays, memcpy
>> into them, and then construct a vector from that. STL vectors already do
>> 99% of anything a C style array can do, if we add just a tiny bit more then
>> C style arrays will finally have no real use case. I don't care AT ALL how
>> that happens, just let me memcpy into a vector by calling reserve and i'll
>> be a happy man.
>>
>
> But that's not what you want. What you want is to create a vector without
> initializing its contents (for contents which can go uninitialized).
>
In an ideal world yes, filling the vector directly would be the fastest. As
you say that is not nice since the vector can't know if someone changed it
buffer out from under it. I can live with a default initialization syntax,
as long as once i do this default initialization that i can fill the vector
via memcpy safely.
--
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/7817d9a9-84cf-49f1-a9c4-2c7bb837d5b6%40isocpp.org.
------=_Part_646_1485455103.1500696662306
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 22, 2017 at 12:08:06 AM UTC-4, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Saturday, July 22, 2017 at 12:05:58 AM UTC-4, <a>stevem...@gmail.com=
</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I'm=
more than aware this is currently not safe that is <i>WHY</i>=C2=A0i made =
this thread, so that this vectors can morph into a thing that can finally r=
eplace C style arrays. As it is I am forced to use C style arrays, memcpy i=
nto them, and then construct a vector from that. STL vectors already do 99%=
of anything a C style array can do, if we add just a tiny bit more then C =
style arrays will finally have no real use case. I don't care AT ALL ho=
w that happens, just let me memcpy into a vector by calling reserve and i&#=
39;ll be a happy man.<br></div></blockquote><div><br>But that's not wha=
t you want. What you want is to create a vector without initializing its co=
ntents (for contents which can go uninitialized).</div></div></blockquote><=
div><br></div><div>In an ideal world yes, filling the vector directly would=
be the fastest. As you say that is not nice since the vector can't kno=
w if someone changed it buffer out from under it. I can live with a default=
initialization syntax, as long as once i do this default initialization th=
at i can fill the vector via memcpy safely.=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7817d9a9-84cf-49f1-a9c4-2c7bb837d5b6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7817d9a9-84cf-49f1-a9c4-2c7bb837d5b6=
%40isocpp.org</a>.<br />
------=_Part_646_1485455103.1500696662306--
------=_Part_645_803320022.1500696662306--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jul 2017 23:14:42 -0500
Raw View
--94eb2c07720e01c4090554e03bbc
Content-Type: text/plain; charset="UTF-8"
On Fri, Jul 21, 2017 at 11:05 PM, <stevemk14ebr@gmail.com> wrote:
> I'm more than aware this is currently not safe that is *WHY* i made this
> thread, so that this vectors can morph into a thing that can finally
> replace C style arrays. As it is I am forced to use C style arrays, memcpy
> into them, and then construct a vector from that.
>
You haven't addressed my strong objection in that your use case breaks
almost the entire interface of vector. If you can't call size(), can't
copy it correctly, etc., why do you need vector at all? Please explain why
it is difficult to write a class that just manages one heap allocation and
a length?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BO827-rHoxq6RPy%2BE9VH_DkME8TTyc3vhc%3DO584KGSuCw%40mail.gmail.com.
--94eb2c07720e01c4090554e03bbc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 21, 2017 at 11:05 PM, <span dir=3D"ltr"><<=
a href=3D"mailto:stevemk14ebr@gmail.com" target=3D"_blank">stevemk14ebr@gma=
il.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I'm more tha=
n aware this is currently not safe that is <i>WHY</i>=C2=A0i made this thre=
ad, so that this vectors can morph into a thing that can finally replace C =
style arrays. As it is I am forced to use C style arrays, memcpy into them,=
and then construct a vector from that.</div></blockquote><div><br></div><d=
iv>You haven't addressed my strong objection in that your use case brea=
ks almost the entire interface of vector.=C2=A0 If you can't call size(=
), can't copy it correctly, etc., why do you need vector at all?=C2=A0 =
Please explain why it is difficult to write a class that just manages one h=
eap allocation and a length?</div></div>-- <br><div class=3D"gmail_signatur=
e" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr=
"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =
=C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BO827-rHoxq6RPy%2BE9VH_DkME8T=
Tyc3vhc%3DO584KGSuCw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BO8=
27-rHoxq6RPy%2BE9VH_DkME8TTyc3vhc%3DO584KGSuCw%40mail.gmail.com</a>.<br />
--94eb2c07720e01c4090554e03bbc--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 21 Jul 2017 21:17:29 -0700
Raw View
On Friday, 21 July 2017 19:40:25 PDT stevemk14ebr@gmail.com wrote:
> Sometimes when using vectors in low-level embedded land it is nice to know
> where the underlying buffer of a vector is before any data exists in the
> vector. As it stands it is not possible to do this, even if first calling
> reserve.
Call resize(), not reserve(). The reserve call may be ignored, if for any
reason the container does not wish to comply. So the moment you add your
instructions, the container could relocate.
--
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/3698268.FNhVtt8vov%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 21 Jul 2017 21:18:29 -0700
Raw View
On Friday, 21 July 2017 21:05:26 PDT Nicol Bolas wrote:
> I *really* hate when people do that. When people say, "Oh, I know we *ought*
> to fix the problem directly, but I believe that the standards committee
> would never go for that, so instead let's do a pre-compromised half-measure
> that only works for a select few things."
"Can you fix the horn in my car? The brakes aren't working"
--
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/2629944.CNB0yeUUEz%40tjmaciei-mobl1.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jul 2017 23:20:15 -0500
Raw View
--94eb2c07720edceece0554e04e9a
Content-Type: text/plain; charset="UTF-8"
On Fri, Jul 21, 2017 at 11:14 PM, Nevin Liber <nevin@eviloverlord.com>
wrote:
> Please explain why it is difficult to write a class that just manages one
> heap allocation and a length?
>
I'm sorry; that is over-engineering. You were not proposing that vector
keep track of the length.
Simpler question: why isn't unique_ptr<T[]> the solution to your problem?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNA2saPjAP6atL-ha%2BwhugOxP7gwYW-dqed3%2BaXNVOrxA%40mail.gmail.com.
--94eb2c07720edceece0554e04e9a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 21, 2017 at 11:14 PM, Nevin Liber <span dir=3D=
"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin=
@eviloverlord.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><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 =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Please explain why it=
is difficult to write a class that just manages one heap allocation and a =
length?</div></div></div></div></blockquote><div><br></div><div>I'm sor=
ry; that is over-engineering.=C2=A0 You were not proposing that vector keep=
track of the length.</div><div><br></div><div>Simpler question: =C2=A0why =
isn't unique_ptr<T[]> the solution to your problem?</div></div>--=
<br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div=
dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=
=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></=
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" 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/CAGg_6%2BNA2saPjAP6atL-ha%2BwhugOxP7g=
wYW-dqed3%2BaXNVOrxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNA=
2saPjAP6atL-ha%2BwhugOxP7gwYW-dqed3%2BaXNVOrxA%40mail.gmail.com</a>.<br />
--94eb2c07720edceece0554e04e9a--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jul 2017 23:26:40 -0500
Raw View
--001a11440e44d385eb0554e06515
Content-Type: text/plain; charset="UTF-8"
On Fri, Jul 21, 2017 at 11:17 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> Call resize(), not reserve(). The reserve call may be ignored, if for any
> reason the container does not wish to comply.
That is incorrect. reserve() may not be ignored. The parameter passed to
reserve is the minimum amount of space allocated to the vector (and in all
known implementations, if an allocation happens, the exact amount is
reserved, but the committee does not wish to standardize that) or an
exception is thrown. See [vector.capacity] for more details.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNtfVARsgGGF78M8_bw76A1EoU%3DmfJFnoWJKS9g%3D2SaLw%40mail.gmail.com.
--001a11440e44d385eb0554e06515
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 21, 2017 at 11:17 PM, Thiago Macieira <span di=
r=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thia=
go@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">Call resize(), not reser=
ve(). The reserve call may be ignored, if for any<br>
reason the container does not wish to comply.</blockquote><div><br></div><d=
iv>That is incorrect. =C2=A0reserve() may not be ignored.=C2=A0 The paramet=
er passed to reserve is the minimum amount of space allocated to the vector=
(and in all known implementations, if an allocation happens, the exact amo=
unt is reserved, but the committee does not wish to standardize that) or an=
exception is thrown.=C2=A0 See [vector.capacity] for more details.</div></=
div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature=
"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" L=
iber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_=
blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></di=
v></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" 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/CAGg_6%2BNtfVARsgGGF78M8_bw76A1EoU%3D=
mfJFnoWJKS9g%3D2SaLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNt=
fVARsgGGF78M8_bw76A1EoU%3DmfJFnoWJKS9g%3D2SaLw%40mail.gmail.com</a>.<br />
--001a11440e44d385eb0554e06515--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 21:27:50 -0700 (PDT)
Raw View
------=_Part_890_838647415.1500697670166
Content-Type: multipart/alternative;
boundary="----=_Part_891_1193076308.1500697670167"
------=_Part_891_1193076308.1500697670167
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 22, 2017 at 12:20:57 AM UTC-4, Nevin ":-)" Liber wrote:
>
> On Fri, Jul 21, 2017 at 11:14 PM, Nevin Liber <ne...@eviloverlord.com
> <javascript:>> wrote:
>
>> Please explain why it is difficult to write a class that just manages one
>> heap allocation and a length?
>>
>
> I'm sorry; that is over-engineering. You were not proposing that vector
> keep track of the length.
>
> Simpler question: why isn't unique_ptr<T[]> the solution to your problem?
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>
> +1-847-691-1404
>
Re-implementing my custom vector class that lets me memcpy into it is
totally a possibility, but i'd be re-implementing exactly what the STL does
+ making .data() return a valid pointer, no reason to do that and it'd be a
horrible waste of time. I could totally use a C style array wrapped in a
unique_ptr but what happens when i want to add more instructions to my
array, oh i have to resize, copy, do all that logic. It's the same question
"why did C++ invent the vector", C style arrays do the exact same thing,
but vectors do it in a nicer wrapper.
I want to use a vector like a buffer for embedded applications. I am
telling you what i face everyday. C style fits, C++ does not. I like C++
alot, lets fix it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b1ad297f-0ed0-4a18-b445-914b9f297ac0%40isocpp.org.
------=_Part_891_1193076308.1500697670167
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 22, 2017 at 12:20:57 AM UTC-4, N=
evin ":-)" Liber 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 Fri, Jul 21, 2017 at 11:14 PM, Nevin Liber <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"6Lp6u8G8AwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">ne...@eviloverlord.com</a>></span> wrote:<br><div><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote"><div>Please explain why it is difficult to write a class =
that just manages one heap allocation and a length?</div></div></div></div>=
</blockquote><div><br></div><div>I'm sorry; that is over-engineering.=
=C2=A0 You were not proposing that vector keep track of the length.</div><d=
iv><br></div><div>Simpler question: =C2=A0why isn't unique_ptr<T[]&g=
t; the solution to your problem?</div></div>-- <br><div><div dir=3D"ltr"><d=
iv><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto=
:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6Lp6u8G=
8AwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">ne..=
..@eviloverlord.com</a><wbr>> =C2=A0+1-847-691-1404</div></div></div></di=
v></div></div></div></blockquote><div><br></div><div>Re-implementing my cus=
tom vector class that lets me memcpy into it is totally a possibility, but =
i'd be re-implementing exactly what the STL does + making .data() retur=
n a valid pointer, no reason to do that and it'd be a horrible waste of=
time. I could totally use a C style array wrapped in a unique_ptr but what=
happens when i want to add more instructions to my array, oh i have to res=
ize, copy, do all that logic. It's the same question "why did C++ =
invent the vector", C style arrays do the exact same thing, but vector=
s do it in a nicer wrapper.=C2=A0</div><div><br></div><div>I want to use a =
vector like a buffer for embedded applications. I am telling you what i fac=
e everyday. C style fits, C++ does not. I like C++ alot, lets fix it.</div>=
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b1ad297f-0ed0-4a18-b445-914b9f297ac0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1ad297f-0ed0-4a18-b445-914b9f297ac0=
%40isocpp.org</a>.<br />
------=_Part_891_1193076308.1500697670167--
------=_Part_890_838647415.1500697670166--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 21:31:59 -0700 (PDT)
Raw View
------=_Part_1874_265146590.1500697919091
Content-Type: multipart/alternative;
boundary="----=_Part_1875_1449251632.1500697919091"
------=_Part_1875_1449251632.1500697919091
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 22, 2017 at 12:17:36 AM UTC-4, Thiago Macieira wrote:
>
> On Friday, 21 July 2017 19:40:25 PDT stevem...@gmail.com <javascript:>
> wrote:
> > Sometimes when using vectors in low-level embedded land it is nice to
> know
> > where the underlying buffer of a vector is before any data exists in the
> > vector. As it stands it is not possible to do this, even if first
> calling
> > reserve.
>
> Call resize(), not reserve(). The reserve call may be ignored, if for any
> reason the container does not wish to comply. So the moment you add your
> instructions, the container could relocate.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
The vector only reallocates if the capacity is < current size(). That's the
whole point of me calling reserve first. Inserting, push_back, all safe as
long as the capacity is there
--
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/43b24dca-7400-4cae-8b57-a676d27d88f0%40isocpp.org.
------=_Part_1875_1449251632.1500697919091
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 22, 2017 at 12:17:36 AM UTC-4, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday=
, 21 July 2017 19:40:25 PDT <a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"loRXzJK8AwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">stevem...@gmail.com</a> wrote:
<br>> Sometimes when using vectors in low-level embedded land it is nice=
to know
<br>> where the underlying buffer of a vector is before any data exists =
in the
<br>> vector. As it stands it is not possible to do this, even if first =
calling
<br>> reserve.
<br>
<br>Call resize(), not reserve(). The reserve call may be ignored, if for a=
ny=20
<br>reason the container does not wish to comply. So the moment you add you=
r=20
<br>instructions, the container could relocate.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br></blockquote><div><br></div><div>The vector only reallocates if the cap=
acity is < current size(). That's the whole point of me calling rese=
rve first. Inserting, push_back, all safe as long as the capacity is there<=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/43b24dca-7400-4cae-8b57-a676d27d88f0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43b24dca-7400-4cae-8b57-a676d27d88f0=
%40isocpp.org</a>.<br />
------=_Part_1875_1449251632.1500697919091--
------=_Part_1874_265146590.1500697919091--
.
Author: stevemk14ebr@gmail.com
Date: Fri, 21 Jul 2017 21:32:34 -0700 (PDT)
Raw View
------=_Part_1854_1971442098.1500697954191
Content-Type: multipart/alternative;
boundary="----=_Part_1855_1465082164.1500697954191"
------=_Part_1855_1465082164.1500697954191
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 22, 2017 at 12:31:59 AM UTC-4, stevem...@gmail.com wrote:
>
>
>
> On Saturday, July 22, 2017 at 12:17:36 AM UTC-4, Thiago Macieira wrote:
>>
>> On Friday, 21 July 2017 19:40:25 PDT stevem...@gmail.com wrote:
>> > Sometimes when using vectors in low-level embedded land it is nice to
>> know
>> > where the underlying buffer of a vector is before any data exists in
>> the
>> > vector. As it stands it is not possible to do this, even if first
>> calling
>> > reserve.
>>
>> Call resize(), not reserve(). The reserve call may be ignored, if for any
>> reason the container does not wish to comply. So the moment you add your
>> instructions, the container could relocate.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>>
>
> The vector only reallocates if the capacity is < current size(). That's
> the whole point of me calling reserve first. Inserting, push_back, all safe
> as long as the capacity is there
>
*capacity < needed size
--
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/4c24ba6b-761e-4c2d-9eff-89f989d461d0%40isocpp.org.
------=_Part_1855_1465082164.1500697954191
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 22, 2017 at 12:31:59 AM UTC-4, s=
tevem...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><br>On Saturday, July 22, 2017 at 12:17:36 AM 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 Friday, 21 July =
2017 19:40:25 PDT <a rel=3D"nofollow">stevem...@gmail.com</a> wrote:
<br>> Sometimes when using vectors in low-level embedded land it is nice=
to know
<br>> where the underlying buffer of a vector is before any data exists =
in the
<br>> vector. As it stands it is not possible to do this, even if first =
calling
<br>> reserve.
<br>
<br>Call resize(), not reserve(). The reserve call may be ignored, if for a=
ny=20
<br>reason the container does not wish to comply. So the moment you add you=
r=20
<br>instructions, the container could relocate.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br></blockquote><div><br></div><div>The vector only reallocates if the cap=
acity is < current size(). That's the whole point of me calling rese=
rve first. Inserting, push_back, all safe as long as the capacity is there<=
/div></div></blockquote><div>*capacity < needed size=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4c24ba6b-761e-4c2d-9eff-89f989d461d0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4c24ba6b-761e-4c2d-9eff-89f989d461d0=
%40isocpp.org</a>.<br />
------=_Part_1855_1465082164.1500697954191--
------=_Part_1854_1971442098.1500697954191--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jul 2017 23:37:25 -0500
Raw View
--001a11441b5c4014720554e08c37
Content-Type: text/plain; charset="UTF-8"
On Fri, Jul 21, 2017 at 11:27 PM, <stevemk14ebr@gmail.com> wrote:
> Re-implementing my custom vector class that lets me memcpy into it is
> totally a possibility, but i'd be re-implementing exactly what the STL does
> + making .data() return a valid pointer, no reason to do that and it'd be a
> horrible waste of time. I could totally use a C style array wrapped in a
> unique_ptr but what happens when i want to add more instructions to my
> array, oh i have to resize, copy, do all that logic.
>
I don't see how that just works by having data() always return a pointer to
the internal buffer. If you resize the vector, your original data will
*not* be copied.
Please post code where resize and copy work correctly with a vector whose
only change is that data() always returns a pointer to the internal
buffer. Also show us code for making your motivating case of doing codegen
work with resize and copy.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
<(847)%20691-1404>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOV5AUAi-beY%3D2xLsyhP-ZX-ZYZxhEfROPzhuEmz5eV7A%40mail.gmail.com.
--001a11441b5c4014720554e08c37
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 21, 2017 at 11:27 PM, <span dir=3D"ltr"><<=
a href=3D"mailto:stevemk14ebr@gmail.com" target=3D"_blank">stevemk14ebr@gma=
il.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Re-implementing =
my custom vector class that lets me memcpy into it is totally a possibility=
, but i'd be re-implementing exactly what the STL does + making .data()=
return a valid pointer, no reason to do that and it'd be a horrible wa=
ste of time. I could totally use a C style array wrapped in a unique_ptr bu=
t what happens when i want to add more instructions to my array, oh i have =
to resize, copy, do all that logic.<br></div></blockquote><div><br></div><d=
iv>I don't see how that just works by having data() always return a poi=
nter to the internal buffer.=C2=A0 If you resize the vector, your original =
data will=C2=A0<i>not</i>=C2=A0be copied.</div><div><br></div><div>Please p=
ost code where resize and copy work correctly with a vector whose only chan=
ge is that data() always returns a pointer to the internal buffer.=C2=A0 Al=
so show us code for making your motivating case of doing codegen work with =
resize and copy.</div></div>-- <br><div class=3D"m_7434127890265155356gmail=
_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div d=
ir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a><wbr>> =C2=A0<a href=3D"tel:(847)%20691-1404" value=3D"+18476911404"=
target=3D"_blank">+1-847-691-1404</a></div></div></div></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" 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/CAGg_6%2BOV5AUAi-beY%3D2xLsyhP-ZX-ZYZ=
xhEfROPzhuEmz5eV7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOV5A=
UAi-beY%3D2xLsyhP-ZX-ZYZxhEfROPzhuEmz5eV7A%40mail.gmail.com</a>.<br />
--001a11441b5c4014720554e08c37--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 21 Jul 2017 21:39:31 -0700 (PDT)
Raw View
------=_Part_1954_2043633217.1500698371602
Content-Type: multipart/alternative;
boundary="----=_Part_1955_1849491624.1500698371603"
------=_Part_1955_1849491624.1500698371603
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 22, 2017 at 12:27:50 AM UTC-4, stevem...@gmail.com wrote:
>
>
>
> On Saturday, July 22, 2017 at 12:20:57 AM UTC-4, Nevin ":-)" Liber wrote:
>>
>> On Fri, Jul 21, 2017 at 11:14 PM, Nevin Liber <ne...@eviloverlord.com>
>> wrote:
>>
>>> Please explain why it is difficult to write a class that just manages
>>> one heap allocation and a length?
>>>
>>
>> I'm sorry; that is over-engineering. You were not proposing that vector
>> keep track of the length.
>>
>> Simpler question: why isn't unique_ptr<T[]> the solution to your problem?
>> --
>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> +1-847-691-1404
>>
>
> Re-implementing my custom vector class that lets me memcpy into it is
> totally a possibility, but i'd be re-implementing exactly what the STL does
> + making .data() return a valid pointer, no reason to do that and it'd be a
> horrible waste of time.
>
The part you're not understanding is that your request is not just "making
..data() return a valid pointer". There's more to `vector`'s interface that
you aren't aware of, and your implementation would either not conform to
the rest of `vector` or invoke UB.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01a59ac8-0e1a-4280-87f9-8922011bb001%40isocpp.org.
------=_Part_1955_1849491624.1500698371603
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 22, 2017 at 12:27:50 AM UTC-4, s=
tevem...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><br>On Saturday, July 22, 2017 at 12:20:57 AM UTC-4, Nevin =
":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">On Fri, Jul 21, 2017 at 11:14 PM, Nevin Liber <span dir=3D"ltr">&=
lt;<a rel=3D"nofollow">ne...@eviloverlord.com</a>></span> wrote:<br><div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><div>Please explain why it is difficult to=
write a class that just manages one heap allocation and a length?</div></d=
iv></div></div></blockquote><div><br></div><div>I'm sorry; that is over=
-engineering.=C2=A0 You were not proposing that vector keep track of the le=
ngth.</div><div><br></div><div>Simpler question: =C2=A0why isn't unique=
_ptr<T[]> the solution to your problem?</div></div>-- <br><div><div d=
ir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a rel=3D"nofollow">ne...@eviloverlord.com</a><wbr>> =C2=
=A0+1-847-691-1404</div></div></div></div></div></div></div></blockquote><d=
iv><br></div><div>Re-implementing my custom vector class that lets me memcp=
y into it is totally a possibility, but i'd be re-implementing exactly =
what the STL does + making .data() return a valid pointer, no reason to do =
that and it'd be a horrible waste of time.</div></div></blockquote><div=
><br>The part you're not understanding is that your request is not just=
"making .data() return a valid pointer". There's more to `ve=
ctor`'s interface that you aren't aware of, and your implementation=
would either not conform to the rest of `vector` or invoke UB.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/01a59ac8-0e1a-4280-87f9-8922011bb001%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/01a59ac8-0e1a-4280-87f9-8922011bb001=
%40isocpp.org</a>.<br />
------=_Part_1955_1849491624.1500698371603--
------=_Part_1954_2043633217.1500698371602--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 21 Jul 2017 23:20:19 -0700
Raw View
On Friday, 21 July 2017 21:26:40 PDT Nevin Liber wrote:
> On Fri, Jul 21, 2017 at 11:17 PM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > Call resize(), not reserve(). The reserve call may be ignored, if for any
> > reason the container does not wish to comply.
>
> That is incorrect. reserve() may not be ignored. The parameter passed to
> reserve is the minimum amount of space allocated to the vector (and in all
> known implementations, if an allocation happens, the exact amount is
> reserved, but the committee does not wish to standardize that) or an
> exception is thrown. See [vector.capacity] for more details.
That's true for std::vector and the Standard Library containers, but it is not
a general rule for all containers. Reserving space is a hint that you're going
to need at least that amount. The keyword is "hint".
Besides, is there any wording that resize() with the same size on a space-
reserved container must NOT relocate? What happens if you shrunk the
container, is it allowed to relocate?
--
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/2285781.sJq2cSsSlF%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 21 Jul 2017 23:20:48 -0700
Raw View
On Friday, 21 July 2017 21:31:59 PDT stevemk14ebr@gmail.com wrote:
> The vector only reallocates if the capacity is < current size(). That's the
> whole point of me calling reserve first. Inserting, push_back, all safe as
> long as the capacity is there
So why don't you call resize() instead of reserve() ?
--
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/2971640.uOa5RolS4P%40tjmaciei-mobl1.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sat, 22 Jul 2017 02:06:53 -0500
Raw View
--001a11441b5cd313310554e2a2b1
Content-Type: text/plain; charset="UTF-8"
On Sat, Jul 22, 2017 at 1:20 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> That's true for std::vector and the Standard Library containers, but it is
> not
> a general rule for all containers.
There are no general rules for all containers that might exist in the world
in the past, present or future. Seems a bit irrelevant, though.
Reserving space is a hint that you're going
> to need at least that amount. The keyword is "hint".
>
If that is how you choose to design your own private containers, who am I
to argue? But I don't see how it is relevant to how std::vector works.
> Besides, is there any wording that resize() with the same size on a space-
> reserved container must NOT relocate?
For vector (I've not looked at basic_string), resize(n) cannot relocate
when n <= capacity().
> What happens if you shrunk the
> container, is it allowed to relocate?
>
shrink_to_fit() can relocate, but that call is just a non-binding hint.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOHKQYHY%2BUzqixXG8btqwsAbGcOxtrD_%3DAwAKaYJ8RkVQ%40mail.gmail.com.
--001a11441b5cd313310554e2a2b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sat, Jul 22, 2017 at 1:20 AM, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">That's true for std::=
vector and the Standard Library containers, but it is not<br>
a general rule for all containers.</blockquote><div><br></div><div>There ar=
e no general rules for all containers that might exist in the world in the =
past, present or future.=C2=A0 Seems a bit irrelevant, though.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"> Reserving space is a hint that you&=
#39;re going<br>
to need at least that amount. The keyword is "hint".<br></blockqu=
ote><div><br></div><div>If that is how you choose to design your own privat=
e containers, who am I to argue?=C2=A0 But I don't see how it is releva=
nt to how std::vector works.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">Besides, is there any wording that resize() with the same size on a =
space-<br>
reserved container must NOT relocate?</blockquote><div><br></div><div>For v=
ector (I've not looked at basic_string), resize(n) cannot relocate when=
n <=3D capacity().</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
> What happens if you shrunk the<br>
container, is it allowed to relocate?<br></blockquote><div><br></div><div>s=
hrink_to_fit() can relocate, but that call is just a non-binding hint.</div=
><div>--=C2=A0<br></div></div><div class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevi=
n ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlo=
rd.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1=
404</div></div></div></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" 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/CAGg_6%2BOHKQYHY%2BUzqixXG8btqwsAbGcO=
xtrD_%3DAwAKaYJ8RkVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOH=
KQYHY%2BUzqixXG8btqwsAbGcOxtrD_%3DAwAKaYJ8RkVQ%40mail.gmail.com</a>.<br />
--001a11441b5cd313310554e2a2b1--
.
Author: Vishal Oza <vickoza@gmail.com>
Date: Sat, 22 Jul 2017 03:32:09 -0700 (PDT)
Raw View
------=_Part_2170_416814304.1500719529591
Content-Type: text/plain; charset="UTF-8"
There seems like a lot of discussion about std::vector and using it as a raw buffer for types but could we introduce a new class that could work with raw memory rather then change std::vector to become like a raw buffer.
--
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/dfbf7de2-47fb-4f0e-90b5-08a7980b55d8%40isocpp.org.
------=_Part_2170_416814304.1500719529591--
.
Author: inkwizytoryankes@gmail.com
Date: Sat, 22 Jul 2017 03:50:50 -0700 (PDT)
Raw View
------=_Part_2122_2013240357.1500720650659
Content-Type: multipart/alternative;
boundary="----=_Part_2123_1001202131.1500720650659"
------=_Part_2123_1001202131.1500720650659
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 22, 2017 at 5:32:47 AM UTC+2, Nicol Bolas wrote:
>
>
>
> On Friday, July 21, 2017 at 10:40:25 PM UTC-4, stevem...@gmail.com wrote:
>>
>> Sometimes when using vectors in low-level embedded land it is nice to
>> know where the underlying buffer of a vector is before any data exists in
>> the vector. As it stands it is not possible to do this, even if first
>> calling reserve.
>>
>> ....
>>
>> This will allow people to grab a pointer to the underlying buffer of a
>> vector if and only if they have reserved space first. I suspect many people
>> incorrectly expect one of the above methods I have listed to work as
>> intended (though they do not).
>>
>
> To what end?
>
> OK, let's say that we allow you to get a pointer to that buffer. What are
> you going to do with it? Nothing that's legal in C++, that's for sure.
>
> After all, the standard specifically states that the return from `data` is:
>
> > A pointer such that [data(), data() + size()) is a valid range.
>
> Since `size` is zero, that will be an empty range.
>
> But let's pretend that we allowed you to access up to `capacity` rather
> than `size`. What good is that? First, there are no `T`'s past the end of
> the sequence. So pointer arithmetic in that region is dubious, and you
> can't just write to objects that don't exist.
>
>
But `size` can change over time. I think basic idea that `data` return
valid pointer is useful. Of corse not for manually filing vector but for
sharing same memory with different components.
Image something like this:
int id = 13;
std::vector<std::byte> v;
v.reserve(1024);
message_buffer(id, v.data());
//some time after
v.clear();
v.push_back(1);
v.push_back(2);
v.push_back(3);
v.push_back(0); //or `memcpy` of some struct to `v.data()` with correct size
message_notyfy(id);
With this you will have stable memory region that can be shared with C code
or simply in high performance code you could skip one indirection.
--
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/f254cebe-54ac-4cd0-acee-71916dd55eab%40isocpp.org.
------=_Part_2123_1001202131.1500720650659
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 22, 2017 at 5:32:47 AM UTC+2, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br><br>On Friday, July 21, 2017 at 10:40:25 PM UTC-4, <a>stevem...@gmai=
l.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So=
metimes when using vectors in low-level embedded land it is nice to know wh=
ere the underlying buffer of a vector is before any data exists in the vect=
or. As it stands it is not possible to do this, even if first calling reser=
ve.<div><br></div>....<br><div><span style=3D"font-family:"Open Sans&q=
uot;,SegoeUI,sans-serif;font-size:12.8px"><br></span></div><div><span style=
=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12.8px">=
This will allow people to grab a pointer to the underlying buffer of a vect=
or if and only if they have reserved space first. I suspect many people inc=
orrectly expect one of the above methods I have listed to work as intended =
(though they do not).</span></div></div></blockquote><div><br>To what end?<=
br><br>OK, let's say that we allow you to get a pointer to that buffer.=
What are you going to do with it? Nothing that's legal in C++, that=
9;s for sure.<br><br>After all, the standard specifically states that the r=
eturn from `data` is:<br><br>>=C2=A0 A pointer such that [data(), data()=
+ size()) is a valid range.<br><br>Since `size` is zero, that will be an e=
mpty range.<br><br>But let's pretend that we allowed you to access up t=
o `capacity` rather than `size`. What good is that? First, there are no `T`=
's past the end of the sequence. So pointer arithmetic in that region i=
s dubious, and you can't just write to objects that don't exist.<br=
><br></div></div></blockquote><div>=C2=A0<br>But `size` can change over tim=
e. I think basic idea that `data` return valid pointer is useful. Of corse =
not for manually filing vector but for sharing same memory with different c=
omponents.<br>Image something like this:<br><br><div style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> id </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">13</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">byte</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">reserve</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #066;" class=3D"styled-by-prettify">1024</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>message_buffer</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">id</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//some tim=
e after</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">clear</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>v</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">push_back</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>v</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">push_ba=
ck</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>v</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">push_back</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">3</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">push_back</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">//or `memcpy` of some struct to `v.data()` with co=
rrect size</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>message_notyfy</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div>=
</code></div><br>With this you will have stable memory region that can be s=
hared with C code or simply in high performance code you could skip one ind=
irection.<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f254cebe-54ac-4cd0-acee-71916dd55eab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f254cebe-54ac-4cd0-acee-71916dd55eab=
%40isocpp.org</a>.<br />
------=_Part_2123_1001202131.1500720650659--
------=_Part_2122_2013240357.1500720650659--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Mon, 24 Jul 2017 01:53:06 -0700 (PDT)
Raw View
------=_Part_3145_1327767152.1500886387046
Content-Type: multipart/alternative;
boundary="----=_Part_3146_1683279870.1500886387047"
------=_Part_3146_1683279870.1500886387047
Content-Type: text/plain; charset="UTF-8"
May be it's time to reanimate std::dynarray
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html>
proposal? We can't both have hi-level invariants for std::vector and
low-level full access to internal implementation of it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/45345877-5618-4ecf-a69f-f42e1d9d8458%40isocpp.org.
------=_Part_3146_1683279870.1500886387047
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">May be it's time to reanimate <a href=3D"http://www.op=
en-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html">std::dynarray</a> pr=
oposal? We can't both have hi-level invariants for std::vector and low-=
level full access to internal implementation of it.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/45345877-5618-4ecf-a69f-f42e1d9d8458%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45345877-5618-4ecf-a69f-f42e1d9d8458=
%40isocpp.org</a>.<br />
------=_Part_3146_1683279870.1500886387047--
------=_Part_3145_1327767152.1500886387046--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Mon, 24 Jul 2017 01:56:31 -0700 (PDT)
Raw View
------=_Part_1091_216072901.1500886591188
Content-Type: multipart/alternative;
boundary="----=_Part_1092_443087187.1500886591189"
------=_Part_1092_443087187.1500886591189
Content-Type: text/plain; charset="UTF-8"
On Monday, July 24, 2017 at 11:53:07 AM UTC+3, Victor Dyachenko wrote:
>
> May be it's time to reanimate std::dynarray
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html>
> proposal?
>
without "magic" on-stack allocation which killed the OP
--
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/c3b992eb-66cd-4360-9c7b-a4f153fc7b7a%40isocpp.org.
------=_Part_1092_443087187.1500886591189
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 24, 2017 at 11:53:07 AM UTC+3, Victor Dyac=
henko wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">M=
ay be it's time to reanimate <a href=3D"http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2013/n3662.html" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fww=
w.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3662.html\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGKKAUKEqRRvEIIT8-F3dS7BQ6u4A';retu=
rn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3=
A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3662=
..html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGKKAUKEqRRvEIIT8-F3dS7BQ6u4A&=
#39;;return true;">std::dynarray</a> proposal?<br></div></blockquote><div>w=
ithout "magic" on-stack allocation which killed the OP<br></div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c3b992eb-66cd-4360-9c7b-a4f153fc7b7a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c3b992eb-66cd-4360-9c7b-a4f153fc7b7a=
%40isocpp.org</a>.<br />
------=_Part_1092_443087187.1500886591189--
------=_Part_1091_216072901.1500886591188--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 24 Jul 2017 09:58:41 -0700 (PDT)
Raw View
------=_Part_1211_1745139449.1500915521441
Content-Type: multipart/alternative;
boundary="----=_Part_1212_1672618800.1500915521442"
------=_Part_1212_1672618800.1500915521442
Content-Type: text/plain; charset="UTF-8"
On Monday, July 24, 2017 at 4:56:31 AM UTC-4, Victor Dyachenko wrote:
>
> On Monday, July 24, 2017 at 11:53:07 AM UTC+3, Victor Dyachenko wrote:
>>
>> May be it's time to reanimate std::dynarray
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html>
>> proposal?
>>
> without "magic" on-stack allocation which killed the OP
>
But without that, `dynarray` is nothing more than a `vector` that you can't
resize. And thus, the only substantive difference will be that
`sizeof(dynarray<T>)` will be smaller than `sizeof(vector<T>)`. I don't
think that's a good enough reason to standardize such a type.
That's not to say that I like the "magic on-stack allocation" of the
original. But you have to admit, without that, there just isn't much need
for the type. And it still wouldn't be able to do what the OP of this
thread wants.
--
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/a0fab17c-d168-4093-9952-466c9c172d33%40isocpp.org.
------=_Part_1212_1672618800.1500915521442
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 24, 2017 at 4:56:31 AM UTC-4, Victor Dyach=
enko 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=
Monday, July 24, 2017 at 11:53:07 AM UTC+3, Victor Dyachenko wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">May be it's time to r=
eanimate <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013=
/n3662.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D=
'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2F=
sc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3662.html\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNGKKAUKEqRRvEIIT8-F3dS7BQ6u4A';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3662.html\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNGKKAUKEqRRvEIIT8-F3dS7BQ6u4A';return true;">std::=
dynarray</a> proposal?<br></div></blockquote><div>without "magic"=
on-stack allocation which killed the OP<br></div></div></blockquote><div><=
br>But without that, `dynarray` is nothing more than a `vector` that you ca=
n't resize. And thus, the only substantive difference will be that `siz=
eof(dynarray<T>)` will be smaller than `sizeof(vector<T>)`. I d=
on't think that's a good enough reason to standardize such a type.<=
br><br>That's not to say that I like the "magic on-stack allocatio=
n" of the original. But you have to admit, without that, there just is=
n't much need for the type. And it still wouldn't be able to do wha=
t the OP of this thread wants.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a0fab17c-d168-4093-9952-466c9c172d33%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a0fab17c-d168-4093-9952-466c9c172d33=
%40isocpp.org</a>.<br />
------=_Part_1212_1672618800.1500915521442--
------=_Part_1211_1745139449.1500915521441--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 24 Jul 2017 15:49:48 -0700 (PDT)
Raw View
------=_Part_3805_1171552008.1500936588541
Content-Type: multipart/alternative;
boundary="----=_Part_3806_1793141406.1500936588541"
------=_Part_3806_1793141406.1500936588541
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Friday, July 21, 2017 at 9:05:58 PM UTC-7, stevem...@gmail.com wrote:
>
> I'm more than aware this is currently not safe that is *WHY* i made this=
=20
> thread, so that this vectors can morph into a thing that can finally=20
> replace C style arrays. As it is I am forced to use C style arrays, memcp=
y=20
> into them, and then construct a vector from that. STL vectors already do=
=20
> 99% of anything a C style array can do, if we add just a tiny bit more th=
en=20
> C style arrays will finally have no real use case. I don't care AT ALL ho=
w=20
> that happens, just let me memcpy into a vector by calling reserve and i'l=
l=20
> be a happy man. =20
>
Your thread started off great =E2=80=94 let's have v.data() do the intuitiv=
e thing=20
for reserved vectors! =E2=80=94 but then devolved into this kind of thing, =
which is=20
problematic.
What you seem to actually *want* is .resize():
std::vector<char> v;
v.resize(10);
memcpy(v.data(), "some data", 10); // excellent, works fine
Notice that calling .resize() on your average vector<char> will=20
zero-initialize the contents. If you want default-initialization, you'll=20
have to use a default-constructing allocator type, such as this=20
<https://wandbox.org/permlink/WS6x1g1rdSI6Iri7>.
However, I do think that what you originally asked for is useful in obscure=
=20
cases, and doesn't cost us anything to standardize:
std::vector<char> v;
v.reserve(10);
char *p =3D v.data(); // currently UB; you proposed making this OK
v.resize(5);
assert(p =3D=3D v.data()); // assert that the vector should not have=
=20
reallocated
I have an example implementation here=20
<https://github.com/Quuxplusone/from-scratch/blob/master/include/scratch/bi=
ts/containers/vector.h#L218-L219>.=20
(The example implementation is not surprising and matches all existing=20
implementations I'm aware of; what you originally asked for was basically=
=20
just a change in the wording to match what vendors already do.)
HTH,
Arthur
>
--=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/784bfc77-b071-4b84-9731-cc10884a88e4%40isocpp.or=
g.
------=_Part_3806_1793141406.1500936588541
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, July 21, 2017 at 9:05:58 PM UTC-7, stevem...@gm=
ail.com 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"=
>I'm more than aware this is currently not safe that is <i>WHY</i>=C2=
=A0i made this thread, so that this vectors can morph into a thing that can=
finally replace C style arrays. As it is I am forced to use C style arrays=
, memcpy into them, and then construct a vector from that. STL vectors alre=
ady do 99% of anything a C style array can do, if we add just a tiny bit mo=
re then C style arrays will finally have no real use case. I don't care=
AT ALL how that happens, just let me memcpy into a vector by calling reser=
ve and i'll be a happy man. =C2=A0<br></div></blockquote><div><br></div=
><div>Your thread started off great =E2=80=94 let's have v.data() do th=
e intuitive thing for reserved vectors! =E2=80=94 but then devolved into th=
is kind of thing, which is problematic.</div><div>What you seem to actually=
<i>want</i> is .resize():</div><div><br></div><div>=C2=A0 =C2=A0 std::vect=
or<char> v;</div><div>=C2=A0 =C2=A0 v.resize(10);</div><div>=C2=A0 =
=C2=A0 memcpy(v.data(), "some data", 10); =C2=A0// excellent, wor=
ks fine</div><div><br></div><div>Notice that calling .resize() on your aver=
age vector<char> will zero-initialize the contents. If you want defau=
lt-initialization, you'll have to use a default-constructing allocator =
type, such as <a href=3D"https://wandbox.org/permlink/WS6x1g1rdSI6Iri7">thi=
s</a>.</div><div><br></div><div>However, I do think that what you originall=
y asked for is useful in obscure cases, and doesn't cost us anything to=
standardize:</div><div><br></div><div>=C2=A0 =C2=A0 std::vector<char>=
; v;</div><div>=C2=A0 =C2=A0 v.reserve(10);</div><div>=C2=A0 =C2=A0 char *p=
=3D v.data(); =C2=A0// currently UB; you proposed making this OK</div><div=
>=C2=A0 =C2=A0 v.resize(5);</div><div>=C2=A0 =C2=A0 assert(p =3D=3D v.data(=
)); =C2=A0// assert that the vector should not have reallocated</div><div><=
br></div><div>I have an example implementation <a href=3D"https://github.co=
m/Quuxplusone/from-scratch/blob/master/include/scratch/bits/containers/vect=
or.h#L218-L219">here</a>. (The example implementation is not surprising and=
matches all existing implementations I'm aware of; what you originally=
asked for was basically just a change in the wording to match what vendors=
already do.)</div><div><br></div><div>HTH,</div><div>Arthur</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>
</div></div>
</blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/784bfc77-b071-4b84-9731-cc10884a88e4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/784bfc77-b071-4b84-9731-cc10884a88e4=
%40isocpp.org</a>.<br />
------=_Part_3806_1793141406.1500936588541--
------=_Part_3805_1171552008.1500936588541--
.
Author: stevemk14ebr@gmail.com
Date: Mon, 24 Jul 2017 17:23:55 -0700 (PDT)
Raw View
------=_Part_1359_684228696.1500942235858
Content-Type: multipart/alternative;
boundary="----=_Part_1360_1874220149.1500942235858"
------=_Part_1360_1874220149.1500942235858
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Friday, July 21, 2017 at 9:05:58 PM UTC-7, stevem...@gmail.com wrote:
>>
>> I'm more than aware this is currently not safe that is *WHY* i made this=
=20
>> thread, so that this vectors can morph into a thing that can finally=20
>> replace C style arrays. As it is I am forced to use C style arrays, memc=
py=20
>> into them, and then construct a vector from that. STL vectors already do=
=20
>> 99% of anything a C style array can do, if we add just a tiny bit more t=
hen=20
>> C style arrays will finally have no real use case. I don't care AT ALL h=
ow=20
>> that happens, just let me memcpy into a vector by calling reserve and i'=
ll=20
>> be a happy man. =20
>>
>
> Your thread started off great =E2=80=94 let's have v.data() do the intuit=
ive thing=20
> for reserved vectors! =E2=80=94 but then devolved into this kind of thing=
, which is=20
> problematic.
> What you seem to actually *want* is .resize():
>
> std::vector<char> v;
> v.resize(10);
> memcpy(v.data(), "some data", 10); // excellent, works fine
>
> Notice that calling .resize() on your average vector<char> will=20
> zero-initialize the contents. If you want default-initialization, you'll=
=20
> have to use a default-constructing allocator type, such as this=20
> <https://wandbox.org/permlink/WS6x1g1rdSI6Iri7>.
>
> However, I do think that what you originally asked for is useful in=20
> obscure cases, and doesn't cost us anything to standardize:
>
> std::vector<char> v;
> v.reserve(10);
> char *p =3D v.data(); // currently UB; you proposed making this OK
> v.resize(5);
> assert(p =3D=3D v.data()); // assert that the vector should not have=
=20
> reallocated
>
> I have an example implementation here=20
> <https://github.com/Quuxplusone/from-scratch/blob/master/include/scratch/=
bits/containers/vector.h#L218-L219>.=20
> (The example implementation is not surprising and matches all existing=20
> implementations I'm aware of; what you originally asked for was basically=
=20
> just a change in the wording to match what vendors already do.)
>
> HTH,
> Arthur
>
Yes i'll admit i conflated a few of my wishes for vectors, looking back it=
=20
was clearly not wise. I do agree though very much though that .data()=20
should be re-worded. I know i was very surprised to learn it was U.B to=20
call even on a reserved vector and i do agree it can be useful in a=20
(limited) but important set of cases.=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8935d043-90a8-4306-8f88-9434e1aebd77%40isocpp.or=
g.
------=_Part_1360_1874220149.1500942235858
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arth=
ur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Friday, July 21, 2017 at 9:05:58 PM UTC-7, <a>stevem...@gmail.c=
om</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I'=
;m more than aware this is currently not safe that is <i>WHY</i>=C2=A0i mad=
e this thread, so that this vectors can morph into a thing that can finally=
replace C style arrays. As it is I am forced to use C style arrays, memcpy=
into them, and then construct a vector from that. STL vectors already do 9=
9% of anything a C style array can do, if we add just a tiny bit more then =
C style arrays will finally have no real use case. I don't care AT ALL =
how that happens, just let me memcpy into a vector by calling reserve and i=
'll be a happy man. =C2=A0<br></div></blockquote><div><br></div><div>Yo=
ur thread started off great =E2=80=94 let's have v.data() do the intuit=
ive thing for reserved vectors! =E2=80=94 but then devolved into this kind =
of thing, which is problematic.</div><div>What you seem to actually <i>want=
</i> is .resize():</div><div><br></div><div>=C2=A0 =C2=A0 std::vector<ch=
ar> v;</div><div>=C2=A0 =C2=A0 v.resize(10);</div><div>=C2=A0 =C2=A0 mem=
cpy(v.data(), "some data", 10); =C2=A0// excellent, works fine</d=
iv><div><br></div><div>Notice that calling .resize() on your average vector=
<char> will zero-initialize the contents. If you want default-initial=
ization, you'll have to use a default-constructing allocator type, such=
as <a href=3D"https://wandbox.org/permlink/WS6x1g1rdSI6Iri7" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.co=
m/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FWS6x1g1rdSI6Iri7\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNFEbMx15844gLd-Bwnog0x-CMkkLg';return tr=
ue;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2=
F%2Fwandbox.org%2Fpermlink%2FWS6x1g1rdSI6Iri7\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNFEbMx15844gLd-Bwnog0x-CMkkLg';return true;">this</a>.</div><=
div><br></div><div>However, I do think that what you originally asked for i=
s useful in obscure cases, and doesn't cost us anything to standardize:=
</div><div><br></div><div>=C2=A0 =C2=A0 std::vector<char> v;</div><di=
v>=C2=A0 =C2=A0 v.reserve(10);</div><div>=C2=A0 =C2=A0 char *p =3D v.data()=
; =C2=A0// currently UB; you proposed making this OK</div><div>=C2=A0 =C2=
=A0 v.resize(5);</div><div>=C2=A0 =C2=A0 assert(p =3D=3D v.data()); =C2=A0/=
/ assert that the vector should not have reallocated</div><div><br></div><d=
iv>I have an example implementation <a href=3D"https://github.com/Quuxpluso=
ne/from-scratch/blob/master/include/scratch/bits/containers/vector.h#L218-L=
219" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FQuuxplusone%2Ffrom-=
scratch%2Fblob%2Fmaster%2Finclude%2Fscratch%2Fbits%2Fcontainers%2Fvector.h%=
23L218-L219\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHDsYxqfxJuRI1h6rZO9kil8=
vzXLg';return true;" onclick=3D"this.href=3D'https://www.google.com=
/url?q\x3dhttps%3A%2F%2Fgithub.com%2FQuuxplusone%2Ffrom-scratch%2Fblob%2Fma=
ster%2Finclude%2Fscratch%2Fbits%2Fcontainers%2Fvector.h%23L218-L219\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHDsYxqfxJuRI1h6rZO9kil8vzXLg';return t=
rue;">here</a>. (The example implementation is not surprising and matches a=
ll existing implementations I'm aware of; what you originally asked for=
was basically just a change in the wording to match what vendors already d=
o.)</div><div><br></div><div>HTH,</div><div>Arthur</div></div></blockquote>=
<div><br></div><div>Yes i'll=C2=A0admit i conflated a few of my wishes =
for vectors, looking back it was clearly not wise. I do agree though very m=
uch though that .data() should be re-worded. I know i was very surprised=C2=
=A0to learn it was U.B to call even on a reserved vector and i do agree it =
can be useful in a (limited) but important set of cases.=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8935d043-90a8-4306-8f88-9434e1aebd77%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8935d043-90a8-4306-8f88-9434e1aebd77=
%40isocpp.org</a>.<br />
------=_Part_1360_1874220149.1500942235858--
------=_Part_1359_684228696.1500942235858--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 24 Jul 2017 17:34:45 -0700 (PDT)
Raw View
------=_Part_4014_640120480.1500942885540
Content-Type: multipart/alternative;
boundary="----=_Part_4015_832659274.1500942885540"
------=_Part_4015_832659274.1500942885540
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Friday, July 21, 2017 at 9:05:58 PM UTC-7, stevem...@gmail.com wrote:
>>
>> I'm more than aware this is currently not safe that is *WHY* i made this=
=20
>> thread, so that this vectors can morph into a thing that can finally=20
>> replace C style arrays. As it is I am forced to use C style arrays, memc=
py=20
>> into them, and then construct a vector from that. STL vectors already do=
=20
>> 99% of anything a C style array can do, if we add just a tiny bit more t=
hen=20
>> C style arrays will finally have no real use case. I don't care AT ALL h=
ow=20
>> that happens, just let me memcpy into a vector by calling reserve and i'=
ll=20
>> be a happy man. =20
>>
>
> Your thread started off great =E2=80=94 let's have v.data() do the intuit=
ive thing=20
> for reserved vectors! =E2=80=94 but then devolved into this kind of thing=
, which is=20
> problematic.
> What you seem to actually *want* is .resize():
>
> std::vector<char> v;
> v.resize(10);
> memcpy(v.data(), "some data", 10); // excellent, works fine
>
> Notice that calling .resize() on your average vector<char> will=20
> zero-initialize the contents. If you want default-initialization, you'll=
=20
> have to use a default-constructing allocator type, such as this=20
> <https://wandbox.org/permlink/WS6x1g1rdSI6Iri7>.
>
> However, I do think that what you originally asked for is useful in=20
> obscure cases, and doesn't cost us anything to standardize:
>
> std::vector<char> v;
> v.reserve(10);
> char *p =3D v.data(); // currently UB; you proposed making this OK
> v.resize(5);
> assert(p =3D=3D v.data()); // assert that the vector should not have=
=20
> reallocated
>
> I have an example implementation here=20
> <https://github.com/Quuxplusone/from-scratch/blob/master/include/scratch/=
bits/containers/vector.h#L218-L219>.=20
> (The example implementation is not surprising and matches all existing=20
> implementations I'm aware of; what you originally asked for was basically=
=20
> just a change in the wording to match what vendors already do.)=20
>
OK, so... what exactly would you change the wording to? The current wording=
=20
is:
> A pointer such that `[data(), data() + size())` is a valid range. For a=
=20
non-empty vector, `data() =3D=3D addressof(front())`.
If the `vector` is empty, what does the pointer point to? What are you=20
guaranteeing about that pointer? You can't guarantee that it points to a=20
valid range, since there isn't one. And you can't just say that it points=
=20
to something that *will* be a valid range, since... what exactly does that=
=20
even mean?
So what is it pointing to? The internal allocation, cast to a `T*`?
--=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/2b49c4ab-ee60-4026-9fc9-4e002cfd9399%40isocpp.or=
g.
------=_Part_4015_832659274.1500942885540
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'=
;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>On Friday, J=
uly 21, 2017 at 9:05:58 PM UTC-7, <a>stevem...@gmail.com</a> wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I'm more than aware th=
is is currently not safe that is <i>WHY</i>=C2=A0i made this thread, so tha=
t this vectors can morph into a thing that can finally replace C style arra=
ys. As it is I am forced to use C style arrays, memcpy into them, and then =
construct a vector from that. STL vectors already do 99% of anything a C st=
yle array can do, if we add just a tiny bit more then C style arrays will f=
inally have no real use case. I don't care AT ALL how that happens, jus=
t let me memcpy into a vector by calling reserve and i'll be a happy ma=
n. =C2=A0<br></div></blockquote><div><br></div><div>Your thread started off=
great =E2=80=94 let's have v.data() do the intuitive thing for reserve=
d vectors! =E2=80=94 but then devolved into this kind of thing, which is pr=
oblematic.</div><div>What you seem to actually <i>want</i> is .resize():</d=
iv><div><br></div><div>=C2=A0 =C2=A0 std::vector<char> v;</div><div>=
=C2=A0 =C2=A0 v.resize(10);</div><div>=C2=A0 =C2=A0 memcpy(v.data(), "=
some data", 10); =C2=A0// excellent, works fine</div><div><br></div><d=
iv>Notice that calling .resize() on your average vector<char> will ze=
ro-initialize the contents. If you want default-initialization, you'll =
have to use a default-constructing allocator type, such as <a href=3D"https=
://wandbox.org/permlink/WS6x1g1rdSI6Iri7" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%=
2F%2Fwandbox.org%2Fpermlink%2FWS6x1g1rdSI6Iri7\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNFEbMx15844gLd-Bwnog0x-CMkkLg';return true;" onclick=3D"this=
..href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpe=
rmlink%2FWS6x1g1rdSI6Iri7\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFEbMx1584=
4gLd-Bwnog0x-CMkkLg';return true;">this</a>.</div><div><br></div><div>H=
owever, I do think that what you originally asked for is useful in obscure =
cases, and doesn't cost us anything to standardize:</div><div><br></div=
><div>=C2=A0 =C2=A0 std::vector<char> v;</div><div>=C2=A0 =C2=A0 v.re=
serve(10);</div><div>=C2=A0 =C2=A0 char *p =3D v.data(); =C2=A0// currently=
UB; you proposed making this OK</div><div>=C2=A0 =C2=A0 v.resize(5);</div>=
<div>=C2=A0 =C2=A0 assert(p =3D=3D v.data()); =C2=A0// assert that the vect=
or should not have reallocated</div><div><br></div><div>I have an example i=
mplementation <a href=3D"https://github.com/Quuxplusone/from-scratch/blob/m=
aster/include/scratch/bits/containers/vector.h#L218-L219" target=3D"_blank"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/ur=
l?q\x3dhttps%3A%2F%2Fgithub.com%2FQuuxplusone%2Ffrom-scratch%2Fblob%2Fmaste=
r%2Finclude%2Fscratch%2Fbits%2Fcontainers%2Fvector.h%23L218-L219\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHDsYxqfxJuRI1h6rZO9kil8vzXLg';return true=
;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2FQuuxplusone%2Ffrom-scratch%2Fblob%2Fmaster%2Finclude%2Fscrat=
ch%2Fbits%2Fcontainers%2Fvector.h%23L218-L219\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNHDsYxqfxJuRI1h6rZO9kil8vzXLg';return true;">here</a>. (The e=
xample implementation is not surprising and matches all existing implementa=
tions I'm aware of; what you originally asked for was basically just a =
change in the wording to match what vendors already do.)=C2=A0</div></div><=
/blockquote><div><br>OK, so... what exactly would you change the wording to=
? The current wording is:<br><br>>=C2=A0 A pointer such that `[data(), d=
ata() + size())` is a valid range. For a non-empty vector, `data() =3D=3D a=
ddressof(front())`.<br><br>If the `vector` is empty, what does the pointer =
point to? What are you guaranteeing about that pointer? You can't guara=
ntee that it points to a valid range, since there isn't one. And you ca=
n't just say that it points to something that <i>will</i> be a valid ra=
nge, since... what exactly does that even mean?<br><br>So what is it pointi=
ng to? The internal allocation, cast to a `T*`?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2b49c4ab-ee60-4026-9fc9-4e002cfd9399%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b49c4ab-ee60-4026-9fc9-4e002cfd9399=
%40isocpp.org</a>.<br />
------=_Part_4015_832659274.1500942885540--
------=_Part_4014_640120480.1500942885540--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 24 Jul 2017 17:47:36 -0700
Raw View
--089e082211ac856ee8055519adf4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Jul 24, 2017 at 5:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:
>>
>>
>> Your thread started off great =E2=80=94 let's have v.data() do the intui=
tive
>> thing for reserved vectors! [...]
>>
>> However, I do think that what you originally asked for is useful in
>> obscure cases, and doesn't cost us anything to standardize:
>>
>> std::vector<char> v;
>> v.reserve(10);
>> char *p =3D v.data(); // currently UB; you proposed making this OK
>> v.resize(5);
>> assert(p =3D=3D v.data()); // assert that the vector should not hav=
e
>> reallocated
>>
>> I have an example implementation here
>> <https://github.com/Quuxplusone/from-scratch/blob/master/include/scratch=
/bits/containers/vector.h#L218-L219>.
>> (The example implementation is not surprising and matches all existing
>> implementations I'm aware of; what you originally asked for was basicall=
y
>> just a change in the wording to match what vendors already do.)
>>
>
> OK, so... what exactly would you change the wording to? The current
> wording is:
>
> > A pointer such that `[data(), data() + size())` is a valid range. For =
a
> non-empty vector, `data() =3D=3D addressof(front())`.
>
> If the `vector` is empty, what does the pointer point to? What are you
> guaranteeing about that pointer? You can't guarantee that it points to a
> valid range, since there isn't one. And you can't just say that it points
> to something that *will* be a valid range, since... what exactly does
> that even mean?
>
> So what is it pointing to? The internal allocation, cast to a `T*`?
>
Yes, exactly; that's what it points to.
The only question is, how do we express that real-world requirement
opaquely and obscurely enough to satisfy the Committee? And that's a
question that would require a real proposal in order to answer. I may or
may not write one.
A strawman wording to start out with might be:
A pointer such that `[data(), data() + size())` is the range of data
elements assigned to the vector. For a non-empty vector, `data() =3D=3D
addressof(front())`. *Reallocation (such as by a call to `reserve()`)
invalidates the pointer returned by a previous call to `data()`; as long as
no reallocation happens, the pointer remains valid.*
By logical deduction on this newly added wording, we would be able to
conclude that the pointer returned from data() *prior* to a
non-reallocating push_back() must be the same pointer as would have been
returned *after* the push_back(), and thus that the pointer returned by
data() must necessarily point to the address of front() even when front()
hasn't yet been constructed. But we avoid saying so *explicitly*, and thus
preserve the sacred mystery of std::vector against those philistines who
would callously reduce it to a simple dynamically allocated array. :)
=E2=80=93Arthur
--=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/CADvuK0%2Bo237xRT8sAOJFqcYHtkZqgR%3DJrOJZKMkBdQc=
%3DmzusFg%40mail.gmail.com.
--089e082211ac856ee8055519adf4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Jul 24, 2017 at 5:34 PM, Nicol Bolas <span dir=3D"=
ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr">On Monday, July 24, 2017=
at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><=
br></div><div>Your thread started off great =E2=80=94 let's have v.data=
() do the intuitive thing for reserved vectors! [...]</div><div><br></div><=
div>However, I do think that what you originally asked for is useful in obs=
cure cases, and doesn't cost us anything to standardize:</div><div><br>=
</div><div>=C2=A0 =C2=A0 std::vector<char> v;</div><div>=C2=A0 =C2=A0=
v.reserve(10);</div><div>=C2=A0 =C2=A0 char *p =3D v.data(); =C2=A0// curr=
ently UB; you proposed making this OK</div><div>=C2=A0 =C2=A0 v.resize(5);<=
/div><div>=C2=A0 =C2=A0 assert(p =3D=3D v.data()); =C2=A0// assert that the=
vector should not have reallocated</div><div><br></div><div>I have an exam=
ple implementation <a href=3D"https://github.com/Quuxplusone/from-scratch/b=
lob/master/include/scratch/bits/containers/vector.h#L218-L219" rel=3D"nofol=
low" target=3D"_blank">here</a>. (The example implementation is not surpris=
ing and matches all existing implementations I'm aware of; what you ori=
ginally asked for was basically just a change in the wording to match what =
vendors already do.)=C2=A0</div></div></blockquote><div><br>OK, so... what =
exactly would you change the wording to? The current wording is:<br><br>>=
;=C2=A0 A pointer such that `[data(), data() + size())` is a valid range. F=
or a non-empty vector, `data() =3D=3D addressof(front())`.<br><br>If the `v=
ector` is empty, what does the pointer point to? What are you guaranteeing =
about that pointer? You can't guarantee that it points to a valid range=
, since there isn't one. And you can't just say that it points to s=
omething that <i>will</i> be a valid range, since... what exactly does that=
even mean?<br><br>So what is it pointing to? The internal allocation, cast=
to a `T*`?</div></div></blockquote><div><br></div><div>Yes, exactly; that&=
#39;s what it points to.</div><div>The only question is, how do we express =
that real-world requirement opaquely and obscurely enough to satisfy the Co=
mmittee? And that's a question that would require a real proposal in or=
der to answer. I may or may not write one.</div><div>A strawman wording to =
start out with might be:</div><div><br></div><div>A pointer such that `[dat=
a(), data() + size())` is the range of data elements assigned to the vector=
.. For a non-empty vector, `data() =3D=3D addressof(front())`. <b><i>Realloc=
ation (such as by a call to `reserve()`) invalidates the pointer returned b=
y a previous call to `data()`; as long as no reallocation happens, the poin=
ter remains valid.</i></b></div><div><br></div><div>By logical deduction on=
this newly added wording, we would be able to conclude that the pointer re=
turned from data() <i>prior</i> to a non-reallocating push_back() must be t=
he same pointer as would have been returned <i>after</i> the push_back(), a=
nd thus that the pointer returned by data() must necessarily point to the a=
ddress of front() even when front() hasn't yet been constructed. But we=
avoid saying so <i>explicitly</i>, and thus preserve the sacred mystery of=
std::vector against those philistines who would callously reduce it to a s=
imple dynamically allocated array. :)</div><div><br></div><div>=E2=80=93Art=
hur</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" 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/CADvuK0%2Bo237xRT8sAOJFqcYHtkZqgR%3DJ=
rOJZKMkBdQc%3DmzusFg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2Bo=
237xRT8sAOJFqcYHtkZqgR%3DJrOJZKMkBdQc%3DmzusFg%40mail.gmail.com</a>.<br />
--089e082211ac856ee8055519adf4--
.
Author: stevemk14ebr@gmail.com
Date: Mon, 24 Jul 2017 18:19:16 -0700 (PDT)
Raw View
------=_Part_4004_1931441786.1500945556545
Content-Type: multipart/alternative;
boundary="----=_Part_4005_514278541.1500945556545"
------=_Part_4005_514278541.1500945556545
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, July 24, 2017 at 8:47:40 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Mon, Jul 24, 2017 at 5:34 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>>
>>> Your thread started off great =E2=80=94 let's have v.data() do the intu=
itive=20
>>> thing for reserved vectors! [...]
>>>
>>> However, I do think that what you originally asked for is useful in=20
>>> obscure cases, and doesn't cost us anything to standardize:
>>>
>>> std::vector<char> v;
>>> v.reserve(10);
>>> char *p =3D v.data(); // currently UB; you proposed making this OK
>>> v.resize(5);
>>> assert(p =3D=3D v.data()); // assert that the vector should not ha=
ve=20
>>> reallocated
>>>
>>> I have an example implementation here=20
>>> <https://github.com/Quuxplusone/from-scratch/blob/master/include/scratc=
h/bits/containers/vector.h#L218-L219>.=20
>>> (The example implementation is not surprising and matches all existing=
=20
>>> implementations I'm aware of; what you originally asked for was basical=
ly=20
>>> just a change in the wording to match what vendors already do.)=20
>>>
>>
>> OK, so... what exactly would you change the wording to? The current=20
>> wording is:
>>
>> > A pointer such that `[data(), data() + size())` is a valid range. For=
=20
>> a non-empty vector, `data() =3D=3D addressof(front())`.
>>
>> If the `vector` is empty, what does the pointer point to? What are you=
=20
>> guaranteeing about that pointer? You can't guarantee that it points to a=
=20
>> valid range, since there isn't one. And you can't just say that it point=
s=20
>> to something that *will* be a valid range, since... what exactly does=20
>> that even mean?
>>
>> So what is it pointing to? The internal allocation, cast to a `T*`?
>>
>
> Yes, exactly; that's what it points to.
> The only question is, how do we express that real-world requirement=20
> opaquely and obscurely enough to satisfy the Committee? And that's a=20
> question that would require a real proposal in order to answer. I may or=
=20
> may not write one.
> A strawman wording to start out with might be:
>
> A pointer such that `[data(), data() + size())` is the range of data=20
> elements assigned to the vector. For a non-empty vector, `data() =3D=3D=
=20
> addressof(front())`. *Reallocation (such as by a call to `reserve()`)=20
> invalidates the pointer returned by a previous call to `data()`; as long =
as=20
> no reallocation happens, the pointer remains valid.*
>
> By logical deduction on this newly added wording, we would be able to=20
> conclude that the pointer returned from data() *prior* to a=20
> non-reallocating push_back() must be the same pointer as would have been=
=20
> returned *after* the push_back(), and thus that the pointer returned by=
=20
> data() must necessarily point to the address of front() even when front()=
=20
> hasn't yet been constructed. But we avoid saying so *explicitly*, and=20
> thus preserve the sacred mystery of std::vector against those philistines=
=20
> who would callously reduce it to a simple dynamically allocated array. :)
>
> =E2=80=93Arthur
>
I think this is a little too strongly worded. It doesn't let .data() return=
=20
an invalid pointer when the vector is empty() and it's capacity() is zero.=
=20
I think it should be something like this:=20
23.3.6.4 [vector.data]
| Returns: A pointer such that [data(),data() + size()) is a valid
| range. For a non-empty vector, data() =3D=3D &front().=20
To
23.3.6.4 [vector.data]
| Returns: A pointer such that [data(),data() + size()) is a valid
| range. For a non-empty vector, data() =3D=3D &front().* For a vector o=
f=20
capacity > 0 upon subsequent calls this pointer may not change unless a=20
reallocation occurs; if a reallocation occurs (such as by a call to=20
'reserve()') this pointer may be invalidated and a new one returned. It is=
=20
undefined what happens if this pointer is dereferenced until .size() > 0.*
This guarantees that when non-empty the pointer is to the front. And that=
=20
when someone has first called reserve but the vector is empty (capacity() >=
=20
0 && size() =3D=3D 0) that this pointer must point to the same place that t=
he=20
next push_back will. We also state that this pointer cannot be dereferenced=
=20
because it obviously doesn't make sense to allow someone to access possibly=
=20
garbage data. But this should be enough to do any pointer logic to check=20
for re-allocations, or store the pointer for use later until it's backed by=
=20
valid data.
We want to give freedom for implementations when the capacity() is =3D=3D 0=
;
--=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/25817291-f444-4665-91b1-64de0590a939%40isocpp.or=
g.
------=_Part_4005_514278541.1500945556545
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, July 24, 2017 at 8:47:40 PM UTC-4, Arth=
ur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Mon, Jul 24, 2017 at 5:34 PM, Nicol Bolas <span dir=3D"ltr"><=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"rq1Iztu=
cBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">jmck=
....@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr">On Monday, July 24, 2017 at 6:49:48 PM UTC-4,=
Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div><div><br></div><div>Your th=
read started off great =E2=80=94 let's have v.data() do the intuitive t=
hing for reserved vectors! [...]</div><div><br></div><div>However, I do thi=
nk that what you originally asked for is useful in obscure cases, and doesn=
't cost us anything to standardize:</div><div><br></div><div>=C2=A0 =C2=
=A0 std::vector<char> v;</div><div>=C2=A0 =C2=A0 v.reserve(10);</div>=
<div>=C2=A0 =C2=A0 char *p =3D v.data(); =C2=A0// currently UB; you propose=
d making this OK</div><div>=C2=A0 =C2=A0 v.resize(5);</div><div>=C2=A0 =C2=
=A0 assert(p =3D=3D v.data()); =C2=A0// assert that the vector should not h=
ave reallocated</div><div><br></div><div>I have an example implementation <=
a href=3D"https://github.com/Quuxplusone/from-scratch/blob/master/include/s=
cratch/bits/containers/vector.h#L218-L219" rel=3D"nofollow" target=3D"_blan=
k" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgithub.com%2FQuuxplusone%2Ffrom-scratch%2Fblob%2Fmaster%2Finclude%2Fs=
cratch%2Fbits%2Fcontainers%2Fvector.h%23L218-L219\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHDsYxqfxJuRI1h6rZO9kil8vzXLg';return true;" onclick=3D"t=
his.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2F=
Quuxplusone%2Ffrom-scratch%2Fblob%2Fmaster%2Finclude%2Fscratch%2Fbits%2Fcon=
tainers%2Fvector.h%23L218-L219\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHDsY=
xqfxJuRI1h6rZO9kil8vzXLg';return true;">here</a>. (The example implemen=
tation is not surprising and matches all existing implementations I'm a=
ware of; what you originally asked for was basically just a change in the w=
ording to match what vendors already do.)=C2=A0</div></div></blockquote><di=
v><br>OK, so... what exactly would you change the wording to? The current w=
ording is:<br><br>>=C2=A0 A pointer such that `[data(), data() + size())=
` is a valid range. For a non-empty vector, `data() =3D=3D addressof(front(=
))`.<br><br>If the `vector` is empty, what does the pointer point to? What =
are you guaranteeing about that pointer? You can't guarantee that it po=
ints to a valid range, since there isn't one. And you can't just sa=
y that it points to something that <i>will</i> be a valid range, since... w=
hat exactly does that even mean?<br><br>So what is it pointing to? The inte=
rnal allocation, cast to a `T*`?</div></div></blockquote><div><br></div><di=
v>Yes, exactly; that's what it points to.</div><div>The only question i=
s, how do we express that real-world requirement opaquely and obscurely eno=
ugh to satisfy the Committee? And that's a question that would require =
a real proposal in order to answer. I may or may not write one.</div><div>A=
strawman wording to start out with might be:</div><div><br></div><div>A po=
inter such that `[data(), data() + size())` is the range of data elements a=
ssigned to the vector. For a non-empty vector, `data() =3D=3D addressof(fro=
nt())`. <b><i>Reallocation (such as by a call to `reserve()`) invalidates t=
he pointer returned by a previous call to `data()`; as long as no reallocat=
ion happens, the pointer remains valid.</i></b></div><div><br></div><div>By=
logical deduction on this newly added wording, we would be able to conclud=
e that the pointer returned from data() <i>prior</i> to a non-reallocating =
push_back() must be the same pointer as would have been returned <i>after</=
i> the push_back(), and thus that the pointer returned by data() must neces=
sarily point to the address of front() even when front() hasn't yet bee=
n constructed. But we avoid saying so <i>explicitly</i>, and thus preserve =
the sacred mystery of std::vector against those philistines who would callo=
usly reduce it to a simple dynamically allocated array. :)</div><div><br></=
div><div>=E2=80=93Arthur</div></div></div></div></blockquote><div>I think t=
his is a little too strongly worded. It doesn't let .data() return an i=
nvalid pointer when the vector is empty() and it's capacity() is zero. =
I think it should be something like this:=C2=A0</div><div><br></div><div><d=
iv><span style=3D"font-family: "Open Sans", SegoeUI, sans-serif; =
font-size: 12.8px;">23.3.6.4 [vector.data]</span></div><div><span style=3D"=
font-family: "Open Sans", SegoeUI, sans-serif; font-size: 12.8px;=
">|=C2=A0 =C2=A0 Returns: A pointer such that [data(),data() + size()) is a=
valid</span><br style=3D"font-family: "Open Sans", SegoeUI, sans=
-serif; font-size: 12.8px;"><span style=3D"font-family: "Open Sans&quo=
t;, SegoeUI, sans-serif; font-size: 12.8px;">|=C2=A0 =C2=A0 range.=C2=A0For=
a non-empty vector, data() =3D=3D &front().=C2=A0</span></div></div><d=
iv><span style=3D"font-family: "Open Sans", SegoeUI, sans-serif; =
font-size: 12.8px;"><br></span></div><div><span style=3D"font-family: "=
;Open Sans", SegoeUI, sans-serif; font-size: 12.8px;">To</span></div><=
div><span style=3D"font-family: "Open Sans", SegoeUI, sans-serif;=
font-size: 12.8px;"><br></span></div><div><div><span style=3D"font-family:=
"Open Sans", SegoeUI, sans-serif; font-size: 12.8px;">23.3.6.4 [=
vector.data]</span></div><div><span style=3D"font-family: "Open Sans&q=
uot;, SegoeUI, sans-serif; font-size: 12.8px;">|=C2=A0 =C2=A0 Returns: A po=
inter such that [data(),data() + size()) is a valid</span><br style=3D"font=
-family: "Open Sans", SegoeUI, sans-serif; font-size: 12.8px;"><s=
pan style=3D"font-family: "Open Sans", SegoeUI, sans-serif; font-=
size: 12.8px;">|=C2=A0 =C2=A0 range.=C2=A0For a non-empty vector, data() =
=3D=3D &front().<b> For a vector of capacity > 0 upon subsequent cal=
ls this pointer may not change unless a reallocation occurs; if a reallocat=
ion occurs (such as by a call to 'reserve()') this pointer may be i=
nvalidated and a new one returned. It is undefined what happens if this poi=
nter is dereferenced until .size() > 0.</b></span></div></div><div><span=
style=3D"font-family: "Open Sans", SegoeUI, sans-serif; font-siz=
e: 12.8px;"><b><br></b></span></div><div><font face=3D"Open Sans, SegoeUI, =
sans-serif"><span style=3D"font-size: 12.8px;">This guarantees that when no=
n-empty the pointer is to the front. And that when someone has first called=
reserve but the vector is empty (capacity() > 0 && size() =3D=
=3D 0) that this pointer must point to the same place that the next push_ba=
ck will. We also state that this pointer cannot be dereferenced because it =
obviously doesn't make sense to allow someone to access possibly garbag=
e data. But this should be enough to do any pointer logic to check for re-a=
llocations, or store the pointer for use later until it's backed by val=
id data.</span></font></div><div><font face=3D"Open Sans, SegoeUI, sans-ser=
if"><span style=3D"font-size: 12.8px;"><br></span></font></div><div><font f=
ace=3D"Open Sans, SegoeUI, sans-serif"><span style=3D"font-size: 12.8px;">W=
e want to give freedom for implementations when the capacity() is =3D=3D 0;=
</span></font></div><div><span style=3D"font-family: "Open Sans",=
SegoeUI, sans-serif; font-size: 12.8px;"><br></span></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/25817291-f444-4665-91b1-64de0590a939%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25817291-f444-4665-91b1-64de0590a939=
%40isocpp.org</a>.<br />
------=_Part_4005_514278541.1500945556545--
------=_Part_4004_1931441786.1500945556545--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Tue, 25 Jul 2017 07:53:24 -0700 (PDT)
Raw View
------=_Part_4379_1927635524.1500994404654
Content-Type: multipart/alternative;
boundary="----=_Part_4380_1130893970.1500994404654"
------=_Part_4380_1130893970.1500994404654
Content-Type: text/plain; charset="UTF-8"
>
> So what is it pointing to? The internal allocation, cast to a `T*`?
>>
>
> Yes, exactly; that's what it points to.
> The only question is, how do we express that real-world requirement
> opaquely and obscurely enough to satisfy the Committee?
>
Honestly, what was the possible point of that phrasing?
> But we avoid saying so *explicitly*, and thus preserve the sacred mystery
> of std::vector against those philistines who would callously reduce it to a
> simple dynamically allocated array. :)
>
>
Charming.
--
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/70360cc8-cab1-455f-ad6e-567e8f3aedfe%40isocpp.org.
------=_Part_4380_1130893970.1500994404654
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
So what is it pointing to? The internal allocation, cast to a `T*`?</div></=
div></blockquote><div><br></div><div>Yes, exactly; that's what it point=
s to.</div><div>The only question is, how do we express that real-world req=
uirement opaquely and obscurely enough to satisfy the Committee? </div></di=
v></div></div></blockquote><div><br></div><div>Honestly, what was the possi=
ble point of that phrasing?=C2=A0</div><div><br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gma=
il_quote"><div>But we avoid saying so <i>explicitly</i>, and thus preserve =
the sacred mystery of std::vector against those philistines who would callo=
usly reduce it to a simple dynamically allocated array. :)<br></div><div><b=
r></div></div></div></blockquote><div><br></div><div>Charming.=C2=A0</div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/70360cc8-cab1-455f-ad6e-567e8f3aedfe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/70360cc8-cab1-455f-ad6e-567e8f3aedfe=
%40isocpp.org</a>.<br />
------=_Part_4380_1130893970.1500994404654--
------=_Part_4379_1927635524.1500994404654--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 25 Jul 2017 12:02:02 -0400
Raw View
--001a11473a8efed8570555267469
Content-Type: text/plain; charset="UTF-8"
On Tue, Jul 25, 2017 at 10:53 AM, Barry Revzin <barry.revzin@gmail.com>
wrote:
>
> Honestly, what was the possible point of that phrasing?
>
Part of the frustration of having the library in the Standard is the
attempt to specify behavior without reference to implementation.
--
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/CAHSYqdaS%2Bhw5uvWZ4mYy6xJi2_7F7vk0VL3m_nPF1Pq5%3Dbfrxg%40mail.gmail.com.
--001a11473a8efed8570555267469
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jul 25, 2017 at 10:53 AM, Barry Revzin <span dir=3D"ltr"><<a href=3D=
"mailto:barry.revzin@gmail.com" target=3D"_blank">barry.revzin@gmail.com</a=
>></span> wrote:<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>Hon=
estly, what was the possible point of that phrasing?</div></div></blockquot=
e><div><br>Part of the frustration of having the library in the Standard is=
the attempt to specify behavior without reference to implementation.</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" 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/CAHSYqdaS%2Bhw5uvWZ4mYy6xJi2_7F7vk0VL=
3m_nPF1Pq5%3Dbfrxg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaS%2Bh=
w5uvWZ4mYy6xJi2_7F7vk0VL3m_nPF1Pq5%3Dbfrxg%40mail.gmail.com</a>.<br />
--001a11473a8efed8570555267469--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Tue, 25 Jul 2017 16:27:41 -0700 (PDT)
Raw View
------=_Part_4629_1103567104.1501025261966
Content-Type: multipart/alternative;
boundary="----=_Part_4630_945427753.1501025261967"
------=_Part_4630_945427753.1501025261967
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, 25 July 2017 02:19:16 UTC+1, stevem...@gmail.com wrote:
>
>
>
> On Monday, July 24, 2017 at 8:47:40 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Mon, Jul 24, 2017 at 5:34 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:
>>>>
>>>>
>>>> Your thread started off great =E2=80=94 let's have v.data() do the int=
uitive=20
>>>> thing for reserved vectors! [...]
>>>>
>>>> However, I do think that what you originally asked for is useful in=20
>>>> obscure cases, and doesn't cost us anything to standardize:
>>>>
>>>> std::vector<char> v;
>>>> v.reserve(10);
>>>> char *p =3D v.data(); // currently UB; you proposed making this O=
K
>>>> v.resize(5);
>>>> assert(p =3D=3D v.data()); // assert that the vector should not h=
ave=20
>>>> reallocated
>>>>
>>>> I have an example implementation here=20
>>>> <https://github.com/Quuxplusone/from-scratch/blob/master/include/scrat=
ch/bits/containers/vector.h#L218-L219>.=20
>>>> (The example implementation is not surprising and matches all existing=
=20
>>>> implementations I'm aware of; what you originally asked for was basica=
lly=20
>>>> just a change in the wording to match what vendors already do.)=20
>>>>
>>>
>>> OK, so... what exactly would you change the wording to? The current=20
>>> wording is:
>>>
>>> > A pointer such that `[data(), data() + size())` is a valid range. Fo=
r=20
>>> a non-empty vector, `data() =3D=3D addressof(front())`.
>>>
>>> If the `vector` is empty, what does the pointer point to? What are you=
=20
>>> guaranteeing about that pointer? You can't guarantee that it points to =
a=20
>>> valid range, since there isn't one. And you can't just say that it poin=
ts=20
>>> to something that *will* be a valid range, since... what exactly does=
=20
>>> that even mean?
>>>
>>> So what is it pointing to? The internal allocation, cast to a `T*`?
>>>
>>
>> Yes, exactly; that's what it points to.
>> The only question is, how do we express that real-world requirement=20
>> opaquely and obscurely enough to satisfy the Committee? And that's a=20
>> question that would require a real proposal in order to answer. I may or=
=20
>> may not write one.
>> A strawman wording to start out with might be:
>>
>> A pointer such that `[data(), data() + size())` is the range of data=20
>> elements assigned to the vector. For a non-empty vector, `data() =3D=3D=
=20
>> addressof(front())`. *Reallocation (such as by a call to `reserve()`)=20
>> invalidates the pointer returned by a previous call to `data()`; as long=
as=20
>> no reallocation happens, the pointer remains valid.*
>>
>> By logical deduction on this newly added wording, we would be able to=20
>> conclude that the pointer returned from data() *prior* to a=20
>> non-reallocating push_back() must be the same pointer as would have been=
=20
>> returned *after* the push_back(), and thus that the pointer returned by=
=20
>> data() must necessarily point to the address of front() even when front(=
)=20
>> hasn't yet been constructed. But we avoid saying so *explicitly*, and=20
>> thus preserve the sacred mystery of std::vector against those philistine=
s=20
>> who would callously reduce it to a simple dynamically allocated array. :=
)
>>
>> =E2=80=93Arthur
>>
> I think this is a little too strongly worded. It doesn't let .data()=20
> return an invalid pointer when the vector is empty() and it's capacity() =
is=20
> zero. I think it should be something like this:=20
>
> 23.3.6.4 [vector.data]
> | Returns: A pointer such that [data(),data() + size()) is a valid
> | range. For a non-empty vector, data() =3D=3D &front().=20
>
> To
>
> 23.3.6.4 [vector.data]
> | Returns: A pointer such that [data(),data() + size()) is a valid
> | range. For a non-empty vector, data() =3D=3D &front().* For a vector=
of=20
> capacity > 0 upon subsequent calls this pointer may not change unless a=
=20
> reallocation occurs; if a reallocation occurs (such as by a call to=20
> 'reserve()') this pointer may be invalidated and a new one returned. It i=
s=20
> undefined what happens if this pointer is dereferenced until .size() > 0.=
*
>
> This guarantees that when non-empty the pointer is to the front. And that=
=20
> when someone has first called reserve but the vector is empty (capacity()=
>=20
> 0 && size() =3D=3D 0) that this pointer must point to the same place that=
the=20
> next push_back will. We also state that this pointer cannot be dereferenc=
ed=20
> because it obviously doesn't make sense to allow someone to access possib=
ly=20
> garbage data. But this should be enough to do any pointer logic to check=
=20
> for re-allocations, or store the pointer for use later until it's backed =
by=20
> valid data.
>
> We want to give freedom for implementations when the capacity() is =3D=3D=
0;
>
The pointer has to be valid when capacity() =3D=3D 0, in the sense that it =
can=20
participate in arithmetic operations with an offset of 0, since [data(),=20
data() + size()) is a valid range even when size() and capacity() are both=
=20
0. I agree though that it would be best to avoid the term "valid" as much=
=20
as possible, lest it give the impression that the pointer can be indirected=
=20
or used in a placement new expression. Experience notwithstanding, it is=20
surely unnecessary for the Standard to labor the point that the contiguous=
=20
range [data(), data() + size()) is all that can be formed.
To avoid a double negative, I would suggest "The value returned by data()=
=20
is changed only by operations that cause reallocation. [Note: operations=20
that insert and erase elements change the extent of the valid range=20
[data(), data() + size()) but not its start. -- end note]"
It would also be necessary to state that swap() exchanges data() along with=
=20
capacity() and the elements.=20
I see one possible change in behavior: currently it is permissible for an=
=20
implementation given a call to reserve() on an empty vector to defer any=20
allocation to the first insert (and then allocate the full amount required=
=20
by capacity()); this would no longer be possible (since data() is=20
noexcept).=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/da99ed9c-9d7d-4191-88ab-0497e1e82f08%40isocpp.or=
g.
------=_Part_4630_945427753.1501025261967
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, 25 July 2017 02:19:16 UTC+1, stevem...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><br>On Monday, July 24, 2017 at 8:47:40 PM UTC-4, Arthur O'Dwy=
er 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 Mon, J=
ul 24, 2017 at 5:34 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollo=
w">jmck...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr">On Monday, July 24, 2017 at 6:49:48 PM=
UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div><div><br></div><div>=
Your thread started off great =E2=80=94 let's have v.data() do the intu=
itive thing for reserved vectors! [...]</div><div><br></div><div>However, I=
do think that what you originally asked for is useful in obscure cases, an=
d doesn't cost us anything to standardize:</div><div><br></div><div>=C2=
=A0 =C2=A0 std::vector<char> v;</div><div>=C2=A0 =C2=A0 v.reserve(10)=
;</div><div>=C2=A0 =C2=A0 char *p =3D v.data(); =C2=A0// currently UB; you =
proposed making this OK</div><div>=C2=A0 =C2=A0 v.resize(5);</div><div>=C2=
=A0 =C2=A0 assert(p =3D=3D v.data()); =C2=A0// assert that the vector shoul=
d not have reallocated</div><div><br></div><div>I have an example implement=
ation <a href=3D"https://github.com/Quuxplusone/from-scratch/blob/master/in=
clude/scratch/bits/containers/vector.h#L218-L219" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3=
dhttps%3A%2F%2Fgithub.com%2FQuuxplusone%2Ffrom-scratch%2Fblob%2Fmaster%2Fin=
clude%2Fscratch%2Fbits%2Fcontainers%2Fvector.h%23L218-L219\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNHDsYxqfxJuRI1h6rZO9kil8vzXLg';return true;" onc=
lick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2FQuuxplusone%2Ffrom-scratch%2Fblob%2Fmaster%2Finclude%2Fscratch%2Fb=
its%2Fcontainers%2Fvector.h%23L218-L219\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNHDsYxqfxJuRI1h6rZO9kil8vzXLg';return true;">here</a>. (The example=
implementation is not surprising and matches all existing implementations =
I'm aware of; what you originally asked for was basically just a change=
in the wording to match what vendors already do.)=C2=A0</div></div></block=
quote><div><br>OK, so... what exactly would you change the wording to? The =
current wording is:<br><br>>=C2=A0 A pointer such that `[data(), data() =
+ size())` is a valid range. For a non-empty vector, `data() =3D=3D address=
of(front())`.<br><br>If the `vector` is empty, what does the pointer point =
to? What are you guaranteeing about that pointer? You can't guarantee t=
hat it points to a valid range, since there isn't one. And you can'=
t just say that it points to something that <i>will</i> be a valid range, s=
ince... what exactly does that even mean?<br><br>So what is it pointing to?=
The internal allocation, cast to a `T*`?</div></div></blockquote><div><br>=
</div><div>Yes, exactly; that's what it points to.</div><div>The only q=
uestion is, how do we express that real-world requirement opaquely and obsc=
urely enough to satisfy the Committee? And that's a question that would=
require a real proposal in order to answer. I may or may not write one.</d=
iv><div>A strawman wording to start out with might be:</div><div><br></div>=
<div>A pointer such that `[data(), data() + size())` is the range of data e=
lements assigned to the vector. For a non-empty vector, `data() =3D=3D addr=
essof(front())`. <b><i>Reallocation (such as by a call to `reserve()`) inva=
lidates the pointer returned by a previous call to `data()`; as long as no =
reallocation happens, the pointer remains valid.</i></b></div><div><br></di=
v><div>By logical deduction on this newly added wording, we would be able t=
o conclude that the pointer returned from data() <i>prior</i> to a non-real=
locating push_back() must be the same pointer as would have been returned <=
i>after</i> the push_back(), and thus that the pointer returned by data() m=
ust necessarily point to the address of front() even when front() hasn'=
t yet been constructed. But we avoid saying so <i>explicitly</i>, and thus =
preserve the sacred mystery of std::vector against those philistines who wo=
uld callously reduce it to a simple dynamically allocated array. :)</div><d=
iv><br></div><div>=E2=80=93Arthur</div></div></div></div></blockquote><div>=
I think this is a little too strongly worded. It doesn't let .data() re=
turn an invalid pointer when the vector is empty() and it's capacity() =
is zero. I think it should be something like this:=C2=A0</div><div><br></di=
v><div><div><span style=3D"font-family:"Open Sans",SegoeUI,sans-s=
erif;font-size:12.8px">23.3.6.4 [vector.data]</span></div><div><span style=
=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12.8px">=
|=C2=A0 =C2=A0 Returns: A pointer such that [data(),data() + size()) is a v=
alid</span><br style=3D"font-family:"Open Sans",SegoeUI,sans-seri=
f;font-size:12.8px"><span style=3D"font-family:"Open Sans",SegoeU=
I,sans-serif;font-size:12.8px">|=C2=A0 =C2=A0 range.=C2=A0For a non-empty v=
ector, data() =3D=3D &front().=C2=A0</span></div></div><div><span style=
=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12.8px">=
<br></span></div><div><span style=3D"font-family:"Open Sans",Sego=
eUI,sans-serif;font-size:12.8px">To</span></div><div><span style=3D"font-fa=
mily:"Open Sans",SegoeUI,sans-serif;font-size:12.8px"><br></span>=
</div><div><div><span style=3D"font-family:"Open Sans",SegoeUI,sa=
ns-serif;font-size:12.8px">23.3.6.4 [vector.data]</span></div><div><span st=
yle=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12.8p=
x">|=C2=A0 =C2=A0 Returns: A pointer such that [data(),data() + size()) is =
a valid</span><br style=3D"font-family:"Open Sans",SegoeUI,sans-s=
erif;font-size:12.8px"><span style=3D"font-family:"Open Sans",Seg=
oeUI,sans-serif;font-size:12.8px">|=C2=A0 =C2=A0 range.=C2=A0For a non-empt=
y vector, data() =3D=3D &front().<b> For a vector of capacity > 0 up=
on subsequent calls this pointer may not change unless a reallocation occur=
s; if a reallocation occurs (such as by a call to 'reserve()') this=
pointer may be invalidated and a new one returned. It is undefined what ha=
ppens if this pointer is dereferenced until .size() > 0.</b></span></div=
></div><div><span style=3D"font-family:"Open Sans",SegoeUI,sans-s=
erif;font-size:12.8px"><b><br></b></span></div><div><font face=3D"Open Sans=
, SegoeUI, sans-serif"><span style=3D"font-size:12.8px">This guarantees tha=
t when non-empty the pointer is to the front. And that when someone has fir=
st called reserve but the vector is empty (capacity() > 0 && siz=
e() =3D=3D 0) that this pointer must point to the same place that the next =
push_back will. We also state that this pointer cannot be dereferenced beca=
use it obviously doesn't make sense to allow someone to access possibly=
garbage data. But this should be enough to do any pointer logic to check f=
or re-allocations, or store the pointer for use later until it's backed=
by valid data.</span></font></div><div><font face=3D"Open Sans, SegoeUI, s=
ans-serif"><span style=3D"font-size:12.8px"><br></span></font></div><div><f=
ont face=3D"Open Sans, SegoeUI, sans-serif"><span style=3D"font-size:12.8px=
">We want to give freedom for implementations when the capacity() is =3D=3D=
0;</span></font></div></div></blockquote><div><br></div><div>The pointer h=
as to be valid when capacity() =3D=3D 0, in the sense that it can participa=
te in arithmetic operations with an offset of 0, since [data(), data() + si=
ze()) is a valid range even when size() and capacity() are both 0. I agree =
though that it would be best to avoid the term "valid" as much as=
possible, lest it give the impression that the pointer can be indirected o=
r used in a placement new expression. Experience notwithstanding, it is sur=
ely unnecessary for the Standard to labor the point that the contiguous ran=
ge [data(), data() + size()) is all that can be formed.</div><div><br></div=
><div>To avoid a double negative, I would suggest "The value returned =
by data() is changed only by operations that cause reallocation. [Note: ope=
rations that insert and erase elements change the extent of the valid range=
[data(), data() + size()) but not its start. -- end note]"</div><div>=
<br></div><div>It would also be necessary to state that swap() exchanges da=
ta() along with capacity() and the elements.=C2=A0</div><div><br></div><div=
>I see one possible change in behavior: currently it is permissible for an =
implementation given a call to reserve() on an empty vector to defer any al=
location to the first insert (and then allocate the full amount required by=
capacity()); this would no longer be possible (since data() is noexcept).=
=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/da99ed9c-9d7d-4191-88ab-0497e1e82f08%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/da99ed9c-9d7d-4191-88ab-0497e1e82f08=
%40isocpp.org</a>.<br />
------=_Part_4630_945427753.1501025261967--
------=_Part_4629_1103567104.1501025261966--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 25 Jul 2017 21:58:50 -0500
Raw View
--94eb2c07641e1a039405552fa3ec
Content-Type: text/plain; charset="UTF-8"
On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <ed@catmur.co.uk> wrote:
>
> I see one possible change in behavior: currently it is permissible for an
> implementation given a call to reserve() on an empty vector to defer any
> allocation to the first insert (and then allocate the full amount required
> by capacity()); this would no longer be possible (since data() is
> noexcept).
>
How exactly is that possible, given that the post condition for reserve(n)
is capacity() >= n? If you defer the allocation, how can vector guarantee
the allocation succeeds, especially since the allocation takes place in the
allocator and not by vector itself?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMOrH7%2BqsPYkScG3je3P1m%3Ds1Jw%3DVaxF9JEZWYp9Eyj1Q%40mail.gmail.com.
--94eb2c07641e1a039405552fa3ec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <span dir=
=3D"ltr"><<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur=
..co.uk</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"h5"><br><span style=3D"color:rgb(34,34,34)">I see one possible change i=
n behavior: currently it is permissible for an implementation given a call =
to reserve() on an empty vector to defer any allocation to the first insert=
(and then allocate the full amount required by capacity()); this would no =
longer be possible (since data() is noexcept).=C2=A0</span></div></div></di=
v></blockquote><div><br></div><div>How exactly is that possible, given that=
the post condition for reserve(n) is capacity() >=3D n?=C2=A0 If you de=
fer the allocation, how can vector guarantee the allocation succeeds, espec=
ially since the allocation takes place in the allocator and not by vector i=
tself?</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"g=
mail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &qu=
ot;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.co=
m" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</=
div></div></div></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" 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/CAGg_6%2BMOrH7%2BqsPYkScG3je3P1m%3Ds1=
Jw%3DVaxF9JEZWYp9Eyj1Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
MOrH7%2BqsPYkScG3je3P1m%3Ds1Jw%3DVaxF9JEZWYp9Eyj1Q%40mail.gmail.com</a>.<br=
/>
--94eb2c07641e1a039405552fa3ec--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 25 Jul 2017 20:30:20 -0700 (PDT)
Raw View
------=_Part_4947_278746209.1501039820127
Content-Type: multipart/alternative;
boundary="----=_Part_4948_1580077215.1501039820127"
------=_Part_4948_1580077215.1501039820127
Content-Type: text/plain; charset="UTF-8"
On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <e...@catmur.co.uk
> <javascript:>> wrote:
>
>>
>> I see one possible change in behavior: currently it is permissible for an
>> implementation given a call to reserve() on an empty vector to defer any
>> allocation to the first insert (and then allocate the full amount required
>> by capacity()); this would no longer be possible (since data() is
>> noexcept).
>>
>
> How exactly is that possible, given that the post condition for reserve(n)
> is capacity() >= n?
>
Simple: you return the new capacity, but you didn't allocate any of the
memory behind it yet.
> If you defer the allocation, how can vector guarantee the allocation
> succeeds, especially since the allocation takes place in the allocator and
> not by vector itself?
>
That's the sticking point. If there is unused capacity in a `vector`, if
`size()` < `capacity()`, then a vector is not allowed to fail due to
allocation errors. So it's unclear how an implementation could implement
this requirement and still not allocate upon `reserve` > `capacity`.
--
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/c8d546e7-8529-45f1-8ee6-4baed3539b2d%40isocpp.org.
------=_Part_4948_1580077215.1501039820127
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin &quo=
t;:-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <span dir=3D"ltr"=
><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"qNh=
79p1EAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;;return true;" onclick=3D"this.href=3D'javascript:';return true;">=
e...@catmur.co.uk</a>></span> wrote:<br><div><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br><span style=
=3D"color:rgb(34,34,34)">I see one possible change in behavior: currently i=
t is permissible for an implementation given a call to reserve() on an empt=
y vector to defer any allocation to the first insert (and then allocate the=
full amount required by capacity()); this would no longer be possible (sin=
ce data() is noexcept).=C2=A0</span></div></div></div></blockquote><div><br=
></div><div>How exactly is that possible, given that the post condition for=
reserve(n) is capacity() >=3D n?</div></div></div></div></blockquote><d=
iv><br>Simple: you return the new capacity, but you didn't allocate any=
of the memory behind it yet.<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>If you=
defer the allocation, how can vector guarantee the allocation succeeds, es=
pecially since the allocation takes place in the allocator and not by vecto=
r itself?</div></div></div></div></blockquote><div><br>That's the stick=
ing point. If there is unused capacity in a `vector`, if `size()` < `cap=
acity()`, then a vector is not allowed to fail due to allocation errors. So=
it's unclear how an implementation could implement this requirement an=
d still not allocate upon `reserve` > `capacity`.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c8d546e7-8529-45f1-8ee6-4baed3539b2d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c8d546e7-8529-45f1-8ee6-4baed3539b2d=
%40isocpp.org</a>.<br />
------=_Part_4948_1580077215.1501039820127--
------=_Part_4947_278746209.1501039820127--
.
Author: stevemk14ebr@gmail.com
Date: Wed, 26 Jul 2017 07:35:02 -0700 (PDT)
Raw View
------=_Part_5098_1046203460.1501079702612
Content-Type: multipart/alternative;
boundary="----=_Part_5099_1871138323.1501079702612"
------=_Part_5099_1871138323.1501079702612
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, July 25, 2017 at 7:27:42 PM UTC-4, Edward Catmur wrote:
>
>
>
> On Tuesday, 25 July 2017 02:19:16 UTC+1, stevem...@gmail.com wrote:
>>
>>
>>
>> On Monday, July 24, 2017 at 8:47:40 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>> On Mon, Jul 24, 2017 at 5:34 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:
>>>>>
>>>>>
>>>>> Your thread started off great =E2=80=94 let's have v.data() do the in=
tuitive=20
>>>>> thing for reserved vectors! [...]
>>>>>
>>>>> However, I do think that what you originally asked for is useful in=
=20
>>>>> obscure cases, and doesn't cost us anything to standardize:
>>>>>
>>>>> std::vector<char> v;
>>>>> v.reserve(10);
>>>>> char *p =3D v.data(); // currently UB; you proposed making this =
OK
>>>>> v.resize(5);
>>>>> assert(p =3D=3D v.data()); // assert that the vector should not =
have=20
>>>>> reallocated
>>>>>
>>>>> I have an example implementation here=20
>>>>> <https://github.com/Quuxplusone/from-scratch/blob/master/include/scra=
tch/bits/containers/vector.h#L218-L219>.=20
>>>>> (The example implementation is not surprising and matches all existin=
g=20
>>>>> implementations I'm aware of; what you originally asked for was basic=
ally=20
>>>>> just a change in the wording to match what vendors already do.)=20
>>>>>
>>>>
>>>> OK, so... what exactly would you change the wording to? The current=20
>>>> wording is:
>>>>
>>>> > A pointer such that `[data(), data() + size())` is a valid range.=
=20
>>>> For a non-empty vector, `data() =3D=3D addressof(front())`.
>>>>
>>>> If the `vector` is empty, what does the pointer point to? What are you=
=20
>>>> guaranteeing about that pointer? You can't guarantee that it points to=
a=20
>>>> valid range, since there isn't one. And you can't just say that it poi=
nts=20
>>>> to something that *will* be a valid range, since... what exactly does=
=20
>>>> that even mean?
>>>>
>>>> So what is it pointing to? The internal allocation, cast to a `T*`?
>>>>
>>>
>>> Yes, exactly; that's what it points to.
>>> The only question is, how do we express that real-world requirement=20
>>> opaquely and obscurely enough to satisfy the Committee? And that's a=20
>>> question that would require a real proposal in order to answer. I may o=
r=20
>>> may not write one.
>>> A strawman wording to start out with might be:
>>>
>>> A pointer such that `[data(), data() + size())` is the range of data=20
>>> elements assigned to the vector. For a non-empty vector, `data() =3D=3D=
=20
>>> addressof(front())`. *Reallocation (such as by a call to `reserve()`)=
=20
>>> invalidates the pointer returned by a previous call to `data()`; as lon=
g as=20
>>> no reallocation happens, the pointer remains valid.*
>>>
>>> By logical deduction on this newly added wording, we would be able to=
=20
>>> conclude that the pointer returned from data() *prior* to a=20
>>> non-reallocating push_back() must be the same pointer as would have bee=
n=20
>>> returned *after* the push_back(), and thus that the pointer returned by=
=20
>>> data() must necessarily point to the address of front() even when front=
()=20
>>> hasn't yet been constructed. But we avoid saying so *explicitly*, and=
=20
>>> thus preserve the sacred mystery of std::vector against those philistin=
es=20
>>> who would callously reduce it to a simple dynamically allocated array. =
:)
>>>
>>> =E2=80=93Arthur
>>>
>> I think this is a little too strongly worded. It doesn't let .data()=20
>> return an invalid pointer when the vector is empty() and it's capacity()=
is=20
>> zero. I think it should be something like this:=20
>>
>> 23.3.6.4 [vector.data]
>> | Returns: A pointer such that [data(),data() + size()) is a valid
>> | range. For a non-empty vector, data() =3D=3D &front().=20
>>
>> To
>>
>> 23.3.6.4 [vector.data]
>> | Returns: A pointer such that [data(),data() + size()) is a valid
>> | range. For a non-empty vector, data() =3D=3D &front().* For a vecto=
r of=20
>> capacity > 0 upon subsequent calls this pointer may not change unless a=
=20
>> reallocation occurs; if a reallocation occurs (such as by a call to=20
>> 'reserve()') this pointer may be invalidated and a new one returned. It =
is=20
>> undefined what happens if this pointer is dereferenced until .size() > 0=
..*
>>
>> This guarantees that when non-empty the pointer is to the front. And tha=
t=20
>> when someone has first called reserve but the vector is empty (capacity(=
) >=20
>> 0 && size() =3D=3D 0) that this pointer must point to the same place tha=
t the=20
>> next push_back will. We also state that this pointer cannot be dereferen=
ced=20
>> because it obviously doesn't make sense to allow someone to access possi=
bly=20
>> garbage data. But this should be enough to do any pointer logic to check=
=20
>> for re-allocations, or store the pointer for use later until it's backed=
by=20
>> valid data.
>>
>> We want to give freedom for implementations when the capacity() is =3D=
=3D 0;
>>
>
> The pointer has to be valid when capacity() =3D=3D 0, in the sense that i=
t can=20
> participate in arithmetic operations with an offset of 0, since [data(),=
=20
> data() + size()) is a valid range even when size() and capacity() are bot=
h=20
> 0. I agree though that it would be best to avoid the term "valid" as much=
=20
> as possible, lest it give the impression that the pointer can be indirect=
ed=20
> or used in a placement new expression. Experience notwithstanding, it is=
=20
> surely unnecessary for the Standard to labor the point that the contiguou=
s=20
> range [data(), data() + size()) is all that can be formed.
>
> To avoid a double negative, I would suggest "The value returned by data()=
=20
> is changed only by operations that cause reallocation. [Note: operations=
=20
> that insert and erase elements change the extent of the valid range=20
> [data(), data() + size()) but not its start. -- end note]"
>
> It would also be necessary to state that swap() exchanges data() along=20
> with capacity() and the elements.=20
>
> I see one possible change in behavior: currently it is permissible for an=
=20
> implementation given a call to reserve() on an empty vector to defer any=
=20
> allocation to the first insert (and then allocate the full amount require=
d=20
> by capacity()); this would no longer be possible (since data() is=20
> noexcept).=20
>
This pointer can be zero in the case where capacity is zero and still be=20
valid range. I think it best to require that when the capacity > 0 this=20
pointer must be a "real - non-zero" pointer that points to the same place=
=20
that the first element will be placed at (i.e to the buffer). This would=20
mean that allocations can no longer be deffered, but i don't see how that's=
=20
an issue, i'd rather expect it to be a perk. Someone using reserve likely=
=20
expects that to be the point where the allocation occurs. =20
My proposal of the wording still stands:
23.3.6.4 [vector.data]
| Returns: A pointer such that [data(),data() + size()) is a valid
| range. For a non-empty vector, data() =3D=3D &front().* For a vector o=
f=20
capacity > 0 upon subsequent calls this pointer may not change unless a=20
reallocation occurs; if a reallocation occurs (such as by a call to=20
'reserve()') this pointer may be invalidated and a new one returned. It is=
=20
undefined what happens if this pointer is dereferenced until .size() > 0.*
--=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/ac66a1c6-5aa8-4876-b3d3-e31d4199a183%40isocpp.or=
g.
------=_Part_5099_1871138323.1501079702612
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, July 25, 2017 at 7:27:42 PM UTC-4, Edward =
Catmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><br>On Tuesday, 25 July 2017 02:19:16 UTC+1, <a>stevem...@gmail.com</a>=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On=
Monday, July 24, 2017 at 8:47:40 PM UTC-4, Arthur O'Dwyer wrote:<block=
quote 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 Mon, Jul 24, 2017 at =
5:34 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmai=
l.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr">On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur =
O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div><div><br></div><div>Your thread sta=
rted off great =E2=80=94 let's have v.data() do the intuitive thing for=
reserved vectors! [...]</div><div><br></div><div>However, I do think that =
what you originally asked for is useful in obscure cases, and doesn't c=
ost us anything to standardize:</div><div><br></div><div>=C2=A0 =C2=A0 std:=
:vector<char> v;</div><div>=C2=A0 =C2=A0 v.reserve(10);</div><div>=C2=
=A0 =C2=A0 char *p =3D v.data(); =C2=A0// currently UB; you proposed making=
this OK</div><div>=C2=A0 =C2=A0 v.resize(5);</div><div>=C2=A0 =C2=A0 asser=
t(p =3D=3D v.data()); =C2=A0// assert that the vector should not have reall=
ocated</div><div><br></div><div>I have an example implementation <a href=3D=
"https://github.com/Quuxplusone/from-scratch/blob/master/include/scratch/bi=
ts/containers/vector.h#L218-L219" rel=3D"nofollow" target=3D"_blank" onmous=
edown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgit=
hub.com%2FQuuxplusone%2Ffrom-scratch%2Fblob%2Fmaster%2Finclude%2Fscratch%2F=
bits%2Fcontainers%2Fvector.h%23L218-L219\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNHDsYxqfxJuRI1h6rZO9kil8vzXLg';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FQuuxplus=
one%2Ffrom-scratch%2Fblob%2Fmaster%2Finclude%2Fscratch%2Fbits%2Fcontainers%=
2Fvector.h%23L218-L219\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHDsYxqfxJuRI=
1h6rZO9kil8vzXLg';return true;">here</a>. (The example implementation i=
s not surprising and matches all existing implementations I'm aware of;=
what you originally asked for was basically just a change in the wording t=
o match what vendors already do.)=C2=A0</div></div></blockquote><div><br>OK=
, so... what exactly would you change the wording to? The current wording i=
s:<br><br>>=C2=A0 A pointer such that `[data(), data() + size())` is a v=
alid range. For a non-empty vector, `data() =3D=3D addressof(front())`.<br>=
<br>If the `vector` is empty, what does the pointer point to? What are you =
guaranteeing about that pointer? You can't guarantee that it points to =
a valid range, since there isn't one. And you can't just say that i=
t points to something that <i>will</i> be a valid range, since... what exac=
tly does that even mean?<br><br>So what is it pointing to? The internal all=
ocation, cast to a `T*`?</div></div></blockquote><div><br></div><div>Yes, e=
xactly; that's what it points to.</div><div>The only question is, how d=
o we express that real-world requirement opaquely and obscurely enough to s=
atisfy the Committee? And that's a question that would require a real p=
roposal in order to answer. I may or may not write one.</div><div>A strawma=
n wording to start out with might be:</div><div><br></div><div>A pointer su=
ch that `[data(), data() + size())` is the range of data elements assigned =
to the vector. For a non-empty vector, `data() =3D=3D addressof(front())`. =
<b><i>Reallocation (such as by a call to `reserve()`) invalidates the point=
er returned by a previous call to `data()`; as long as no reallocation happ=
ens, the pointer remains valid.</i></b></div><div><br></div><div>By logical=
deduction on this newly added wording, we would be able to conclude that t=
he pointer returned from data() <i>prior</i> to a non-reallocating push_bac=
k() must be the same pointer as would have been returned <i>after</i> the p=
ush_back(), and thus that the pointer returned by data() must necessarily p=
oint to the address of front() even when front() hasn't yet been constr=
ucted. But we avoid saying so <i>explicitly</i>, and thus preserve the sacr=
ed mystery of std::vector against those philistines who would callously red=
uce it to a simple dynamically allocated array. :)</div><div><br></div><div=
>=E2=80=93Arthur</div></div></div></div></blockquote><div>I think this is a=
little too strongly worded. It doesn't let .data() return an invalid p=
ointer when the vector is empty() and it's capacity() is zero. I think =
it should be something like this:=C2=A0</div><div><br></div><div><div><span=
style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12=
..8px">23.3.6.4 [vector.data]</span></div><div><span style=3D"font-family:&q=
uot;Open Sans",SegoeUI,sans-serif;font-size:12.8px">|=C2=A0 =C2=A0 Ret=
urns: A pointer such that [data(),data() + size()) is a valid</span><br sty=
le=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12.8px=
"><span style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-=
size:12.8px">|=C2=A0 =C2=A0 range.=C2=A0For a non-empty vector, data() =3D=
=3D &front().=C2=A0</span></div></div><div><span style=3D"font-family:&=
quot;Open Sans",SegoeUI,sans-serif;font-size:12.8px"><br></span></div>=
<div><span style=3D"font-family:"Open Sans",SegoeUI,sans-serif;fo=
nt-size:12.8px">To</span></div><div><span style=3D"font-family:"Open S=
ans",SegoeUI,sans-serif;font-size:12.8px"><br></span></div><div><div><=
span style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-siz=
e:12.8px">23.3.6.4 [vector.data]</span></div><div><span style=3D"font-famil=
y:"Open Sans",SegoeUI,sans-serif;font-size:12.8px">|=C2=A0 =C2=A0=
Returns: A pointer such that [data(),data() + size()) is a valid</span><br=
style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12=
..8px"><span style=3D"font-family:"Open Sans",SegoeUI,sans-serif;f=
ont-size:12.8px">|=C2=A0 =C2=A0 range.=C2=A0For a non-empty vector, data() =
=3D=3D &front().<b> For a vector of capacity > 0 upon subsequent cal=
ls this pointer may not change unless a reallocation occurs; if a reallocat=
ion occurs (such as by a call to 'reserve()') this pointer may be i=
nvalidated and a new one returned. It is undefined what happens if this poi=
nter is dereferenced until .size() > 0.</b></span></div></div><div><span=
style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12=
..8px"><b><br></b></span></div><div><font face=3D"Open Sans, SegoeUI, sans-s=
erif"><span style=3D"font-size:12.8px">This guarantees that when non-empty =
the pointer is to the front. And that when someone has first called reserve=
but the vector is empty (capacity() > 0 && size() =3D=3D 0) tha=
t this pointer must point to the same place that the next push_back will. W=
e also state that this pointer cannot be dereferenced because it obviously =
doesn't make sense to allow someone to access possibly garbage data. Bu=
t this should be enough to do any pointer logic to check for re-allocations=
, or store the pointer for use later until it's backed by valid data.</=
span></font></div><div><font face=3D"Open Sans, SegoeUI, sans-serif"><span =
style=3D"font-size:12.8px"><br></span></font></div><div><font face=3D"Open =
Sans, SegoeUI, sans-serif"><span style=3D"font-size:12.8px">We want to give=
freedom for implementations when the capacity() is =3D=3D 0;</span></font>=
</div></div></blockquote><div><br></div><div>The pointer has to be valid wh=
en capacity() =3D=3D 0, in the sense that it can participate in arithmetic =
operations with an offset of 0, since [data(), data() + size()) is a valid =
range even when size() and capacity() are both 0. I agree though that it wo=
uld be best to avoid the term "valid" as much as possible, lest i=
t give the impression that the pointer can be indirected or used in a place=
ment new expression. Experience notwithstanding, it is surely unnecessary f=
or the Standard to labor the point that the contiguous range [data(), data(=
) + size()) is all that can be formed.</div><div><br></div><div>To avoid a =
double negative, I would suggest "The value returned by data() is chan=
ged only by operations that cause reallocation. [Note: operations that inse=
rt and erase elements change the extent of the valid range [data(), data() =
+ size()) but not its start. -- end note]"</div><div><br></div><div>It=
would also be necessary to state that swap() exchanges data() along with c=
apacity() and the elements.=C2=A0</div><div><br></div><div>I see one possib=
le change in behavior: currently it is permissible for an implementation gi=
ven a call to reserve() on an empty vector to defer any allocation to the f=
irst insert (and then allocate the full amount required by capacity()); thi=
s would no longer be possible (since data() is noexcept).=C2=A0</div></div>=
</blockquote><div><br></div><div>This pointer can be zero in the case where=
capacity is zero and still be valid range. I think it best to require that=
when the capacity > 0 this pointer must be a "real - non-zero"=
; pointer that points to the same place that the first element will be plac=
ed at (i.e to the buffer). This would mean that allocations can no longer b=
e deffered, but i don't see how that's an issue, i'd rather exp=
ect it to be a perk. Someone using reserve likely expects that to be the po=
int where the allocation occurs. =C2=A0</div><div><br></div><div>My proposa=
l of the wording still stands:</div><div><div><span style=3D"font-family: &=
quot;Open Sans", SegoeUI, sans-serif; font-size: 12.8px;">23.3.6.4 [ve=
ctor.data]</span></div><div><span style=3D"font-family: "Open Sans&quo=
t;, SegoeUI, sans-serif; font-size: 12.8px;">|=C2=A0 =C2=A0 Returns: A poin=
ter such that [data(),data() + size()) is a valid</span><br style=3D"font-f=
amily: "Open Sans", SegoeUI, sans-serif; font-size: 12.8px;"><spa=
n style=3D"font-family: "Open Sans", SegoeUI, sans-serif; font-si=
ze: 12.8px;">|=C2=A0 =C2=A0 range.=C2=A0For a non-empty vector, data() =3D=
=3D &front().<b>=C2=A0For a vector of capacity > 0 upon subsequent c=
alls this pointer may not change unless a reallocation occurs; if a realloc=
ation occurs (such as by a call to 'reserve()') this pointer may be=
invalidated and a new one returned. It is undefined what happens if this p=
ointer is dereferenced until .size() > 0.</b></span></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ac66a1c6-5aa8-4876-b3d3-e31d4199a183%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac66a1c6-5aa8-4876-b3d3-e31d4199a183=
%40isocpp.org</a>.<br />
------=_Part_5099_1871138323.1501079702612--
------=_Part_5098_1046203460.1501079702612--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 26 Jul 2017 18:19:41 +0100
Raw View
--001a11372cb452e26005553ba765
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-)" Liber wrote:
>>
>> On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <e...@catmur.co.uk> wrote:
>>
>>>
>>> I see one possible change in behavior: currently it is permissible for
>>> an implementation given a call to reserve() on an empty vector to defer any
>>> allocation to the first insert (and then allocate the full amount required
>>> by capacity()); this would no longer be possible (since data() is
>>> noexcept).
>>>
>>
>> How exactly is that possible, given that the post condition for
>> reserve(n) is capacity() >= n?
>>
>
> Simple: you return the new capacity, but you didn't allocate any of the
> memory behind it yet.
>
>
>> If you defer the allocation, how can vector guarantee the allocation
>> succeeds, especially since the allocation takes place in the allocator and
>> not by vector itself?
>>
>
> That's the sticking point. If there is unused capacity in a `vector`, if
> `size()` < `capacity()`, then a vector is not allowed to fail due to
> allocation errors. So it's unclear how an implementation could implement
> this requirement and still not allocate upon `reserve` > `capacity`.
>
Am I missing something? [vector.modifiers] just says that in case no
reallocation occurs on push_back() all pointers, iterators and references
to elements remain valid; an empty vector has no elements, so this is
trivially true. Is this somewhere within the overall library, container or
sequence container requirements?
--
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/CAJnLdOYpTifRWaWDURgOT4SAM5rACjpahPHN%3DDNnn%2BT%2BojP5ag%40mail.gmail.com.
--001a11372cb452e26005553ba765
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 Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On T=
uesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-)" Liber wro=
te:<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <span dir=3D"ltr"><<a r=
el=3D"nofollow">e...@catmur.co.uk</a>></span> wrote:<br><div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>=
<br><span style=3D"color:rgb(34,34,34)">I see one possible change in behavi=
or: currently it is permissible for an implementation given a call to reser=
ve() on an empty vector to defer any allocation to the first insert (and th=
en allocate the full amount required by capacity()); this would no longer b=
e possible (since data() is noexcept).=C2=A0</span></div></div></div></bloc=
kquote><div><br></div><div>How exactly is that possible, given that the pos=
t condition for reserve(n) is capacity() >=3D n?</div></div></div></div>=
</blockquote></span><div><br>Simple: you return the new capacity, but you d=
idn't allocate any of the memory behind it yet.<br>=C2=A0</div><span cl=
ass=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
class=3D"gmail_quote"><div>If you defer the allocation, how can vector gua=
rantee the allocation succeeds, especially since the allocation takes place=
in the allocator and not by vector itself?</div></div></div></div></blockq=
uote></span><div><br>That's the sticking point. If there is unused capa=
city in a `vector`, if `size()` < `capacity()`, then a vector is not all=
owed to fail due to allocation errors. So it's unclear how an implement=
ation could implement this requirement and still not allocate upon `reserve=
` > `capacity`.</div></div></blockquote><div><br></div><div>Am I missing=
something? [vector.modifiers] just says that in case no reallocation occur=
s on push_back() all pointers, iterators and references to elements remain =
valid; an empty vector has no elements, so this is trivially true. Is this =
somewhere within the overall library, container or sequence container requi=
rements?</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" 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/CAJnLdOYpTifRWaWDURgOT4SAM5rACjpahPHN=
%3DDNnn%2BT%2BojP5ag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYpTi=
fRWaWDURgOT4SAM5rACjpahPHN%3DDNnn%2BT%2BojP5ag%40mail.gmail.com</a>.<br />
--001a11372cb452e26005553ba765--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 26 Jul 2017 18:29:29 +0100
Raw View
--94eb2c0776125b306805553bca1a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 26, 2017 at 3:35 PM, <stevemk14ebr@gmail.com> wrote:
>
> On Tuesday, July 25, 2017 at 7:27:42 PM UTC-4, Edward Catmur wrote:
>>
>>
>>
>> On Tuesday, 25 July 2017 02:19:16 UTC+1, stevem...@gmail.com wrote:
>>>
>>>
>>>
>>> On Monday, July 24, 2017 at 8:47:40 PM UTC-4, Arthur O'Dwyer wrote:
>>>>
>>>> On Mon, Jul 24, 2017 at 5:34 PM, Nicol Bolas <jmck...@gmail.com> wrote=
:
>>>>
>>>>> On Monday, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:
>>>>>>
>>>>>>
>>>>>> Your thread started off great =E2=80=94 let's have v.data() do the i=
ntuitive
>>>>>> thing for reserved vectors! [...]
>>>>>>
>>>>>> However, I do think that what you originally asked for is useful in
>>>>>> obscure cases, and doesn't cost us anything to standardize:
>>>>>>
>>>>>> std::vector<char> v;
>>>>>> v.reserve(10);
>>>>>> char *p =3D v.data(); // currently UB; you proposed making this=
OK
>>>>>> v.resize(5);
>>>>>> assert(p =3D=3D v.data()); // assert that the vector should not=
have
>>>>>> reallocated
>>>>>>
>>>>>> I have an example implementation here
>>>>>> <https://github.com/Quuxplusone/from-scratch/blob/master/include/scr=
atch/bits/containers/vector.h#L218-L219>.
>>>>>> (The example implementation is not surprising and matches all existi=
ng
>>>>>> implementations I'm aware of; what you originally asked for was basi=
cally
>>>>>> just a change in the wording to match what vendors already do.)
>>>>>>
>>>>>
>>>>> OK, so... what exactly would you change the wording to? The current
>>>>> wording is:
>>>>>
>>>>> > A pointer such that `[data(), data() + size())` is a valid range.
>>>>> For a non-empty vector, `data() =3D=3D addressof(front())`.
>>>>>
>>>>> If the `vector` is empty, what does the pointer point to? What are yo=
u
>>>>> guaranteeing about that pointer? You can't guarantee that it points t=
o a
>>>>> valid range, since there isn't one. And you can't just say that it po=
ints
>>>>> to something that *will* be a valid range, since... what exactly does
>>>>> that even mean?
>>>>>
>>>>> So what is it pointing to? The internal allocation, cast to a `T*`?
>>>>>
>>>>
>>>> Yes, exactly; that's what it points to.
>>>> The only question is, how do we express that real-world requirement
>>>> opaquely and obscurely enough to satisfy the Committee? And that's a
>>>> question that would require a real proposal in order to answer. I may =
or
>>>> may not write one.
>>>> A strawman wording to start out with might be:
>>>>
>>>> A pointer such that `[data(), data() + size())` is the range of data
>>>> elements assigned to the vector. For a non-empty vector, `data() =3D=
=3D
>>>> addressof(front())`. *Reallocation (such as by a call to `reserve()`)
>>>> invalidates the pointer returned by a previous call to `data()`; as lo=
ng as
>>>> no reallocation happens, the pointer remains valid.*
>>>>
>>>> By logical deduction on this newly added wording, we would be able to
>>>> conclude that the pointer returned from data() *prior* to a
>>>> non-reallocating push_back() must be the same pointer as would have be=
en
>>>> returned *after* the push_back(), and thus that the pointer returned
>>>> by data() must necessarily point to the address of front() even when
>>>> front() hasn't yet been constructed. But we avoid saying so
>>>> *explicitly*, and thus preserve the sacred mystery of std::vector
>>>> against those philistines who would callously reduce it to a simple
>>>> dynamically allocated array. :)
>>>>
>>>> =E2=80=93Arthur
>>>>
>>> I think this is a little too strongly worded. It doesn't let .data()
>>> return an invalid pointer when the vector is empty() and it's capacity(=
) is
>>> zero. I think it should be something like this:
>>>
>>> 23.3.6.4 [vector.data]
>>> | Returns: A pointer such that [data(),data() + size()) is a valid
>>> | range. For a non-empty vector, data() =3D=3D &front().
>>>
>>> To
>>>
>>> 23.3.6.4 [vector.data]
>>> | Returns: A pointer such that [data(),data() + size()) is a valid
>>> | range. For a non-empty vector, data() =3D=3D &front().* For a vect=
or
>>> of capacity > 0 upon subsequent calls this pointer may not change unles=
s a
>>> reallocation occurs; if a reallocation occurs (such as by a call to
>>> 'reserve()') this pointer may be invalidated and a new one returned. It=
is
>>> undefined what happens if this pointer is dereferenced until .size() > =
0.*
>>>
>>> This guarantees that when non-empty the pointer is to the front. And
>>> that when someone has first called reserve but the vector is empty
>>> (capacity() > 0 && size() =3D=3D 0) that this pointer must point to the=
same
>>> place that the next push_back will. We also state that this pointer can=
not
>>> be dereferenced because it obviously doesn't make sense to allow someon=
e to
>>> access possibly garbage data. But this should be enough to do any point=
er
>>> logic to check for re-allocations, or store the pointer for use later u=
ntil
>>> it's backed by valid data.
>>>
>>> We want to give freedom for implementations when the capacity() is =3D=
=3D 0;
>>>
>>
>> The pointer has to be valid when capacity() =3D=3D 0, in the sense that =
it
>> can participate in arithmetic operations with an offset of 0, since
>> [data(), data() + size()) is a valid range even when size() and capacity=
()
>> are both 0. I agree though that it would be best to avoid the term "vali=
d"
>> as much as possible, lest it give the impression that the pointer can be
>> indirected or used in a placement new expression. Experience
>> notwithstanding, it is surely unnecessary for the Standard to labor the
>> point that the contiguous range [data(), data() + size()) is all that ca=
n
>> be formed.
>>
>> To avoid a double negative, I would suggest "The value returned by data(=
)
>> is changed only by operations that cause reallocation. [Note: operations
>> that insert and erase elements change the extent of the valid range
>> [data(), data() + size()) but not its start. -- end note]"
>>
>> It would also be necessary to state that swap() exchanges data() along
>> with capacity() and the elements.
>>
>> I see one possible change in behavior: currently it is permissible for a=
n
>> implementation given a call to reserve() on an empty vector to defer any
>> allocation to the first insert (and then allocate the full amount requir=
ed
>> by capacity()); this would no longer be possible (since data() is
>> noexcept).
>>
>
> This pointer can be zero in the case where capacity is zero and still be
> valid range.
>
Yes, certainly. That means there's no need to restrict a data() stability
clause to the case of nonzero capacity(). Your wording is equally workable
if you strike the "capacity > 0" precondition.
> I think it best to require that when the capacity > 0 this pointer must b=
e
> a "real - non-zero" pointer that points to the same place that the first
> element will be placed at (i.e to the buffer). This would mean that
> allocations can no longer be deffered, but i don't see how that's an issu=
e,
> i'd rather expect it to be a perk. Someone using reserve likely expects
> that to be the point where the allocation occurs.
>
From the point of view of a user, certainly; from the point of view of an
implementer it's an additional constraint. For example, they would be
precluded from deferring allocation to save resources if they have observed
users calling reserve() unnecessarily on vectors that they do not then use.
They would also be unable to diagnose such misuse of the API by checking on
destruction whether reserve()d capacity has been used. Remember that the
Standard is written for the benefit of implementers as much as for users.
> My proposal of the wording still stands:
> 23.3.6.4 [vector.data]
> | Returns: A pointer such that [data(),data() + size()) is a valid
> | range. For a non-empty vector, data() =3D=3D &front().* For a vector=
of
> capacity > 0 upon subsequent calls this pointer may not change unless a
> reallocation occurs; if a reallocation occurs (such as by a call to
> 'reserve()') this pointer may be invalidated and a new one returned. It i=
s
> undefined what happens if this pointer is dereferenced until .size() > 0.=
*
>
>
--=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/CAJnLdOaChxP8BkM0y_uEwek8_Qfx2CbBhnkxMSfS2H_Y9M4=
FEw%40mail.gmail.com.
--94eb2c0776125b306805553bca1a
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 Wed, Jul 26, 2017 at 3:35 PM, <span dir=3D"ltr"><<a href=3D"mail=
to:stevemk14ebr@gmail.com" target=3D"_blank">stevemk14ebr@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Tu=
esday, July 25, 2017 at 7:27:42 PM UTC-4, Edward Catmur wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Tuesday, 25 July 201=
7 02:19:16 UTC+1, <a>stevem...@gmail.com</a> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, July 24, 2017 at 8:47:=
40 PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">On Mon, Jul 24, 2017 at 5:34 PM, Nicol Bolas <span dir=
=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br=
><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Monda=
y, July 24, 2017 at 6:49:48 PM UTC-4, Arthur O'Dwyer wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div><div><br></div><div>Your thread started off great =E2=80=94 let&#=
39;s have v.data() do the intuitive thing for reserved vectors! [...]</div>=
<div><br></div><div>However, I do think that what you originally asked for =
is useful in obscure cases, and doesn't cost us anything to standardize=
:</div><div><br></div><div>=C2=A0 =C2=A0 std::vector<char> v;</div><d=
iv>=C2=A0 =C2=A0 v.reserve(10);</div><div>=C2=A0 =C2=A0 char *p =3D v.data(=
); =C2=A0// currently UB; you proposed making this OK</div><div>=C2=A0 =C2=
=A0 v.resize(5);</div><div>=C2=A0 =C2=A0 assert(p =3D=3D v.data()); =C2=A0/=
/ assert that the vector should not have reallocated</div><div><br></div><d=
iv>I have an example implementation <a href=3D"https://github.com/Quuxpluso=
ne/from-scratch/blob/master/include/scratch/bits/containers/vector.h#L218-L=
219" rel=3D"nofollow" target=3D"_blank">here</a>. (The example implementati=
on is not surprising and matches all existing implementations I'm aware=
of; what you originally asked for was basically just a change in the wordi=
ng to match what vendors already do.)=C2=A0</div></div></blockquote><div><b=
r>OK, so... what exactly would you change the wording to? The current wordi=
ng is:<br><br>>=C2=A0 A pointer such that `[data(), data() + size())` is=
a valid range. For a non-empty vector, `data() =3D=3D addressof(front())`.=
<br><br>If the `vector` is empty, what does the pointer point to? What are =
you guaranteeing about that pointer? You can't guarantee that it points=
to a valid range, since there isn't one. And you can't just say th=
at it points to something that <i>will</i> be a valid range, since... what =
exactly does that even mean?<br><br>So what is it pointing to? The internal=
allocation, cast to a `T*`?</div></div></blockquote><div><br></div><div>Ye=
s, exactly; that's what it points to.</div><div>The only question is, h=
ow do we express that real-world requirement opaquely and obscurely enough =
to satisfy the Committee? And that's a question that would require a re=
al proposal in order to answer. I may or may not write one.</div><div>A str=
awman wording to start out with might be:</div><div><br></div><div>A pointe=
r such that `[data(), data() + size())` is the range of data elements assig=
ned to the vector. For a non-empty vector, `data() =3D=3D addressof(front()=
)`. <b><i>Reallocation (such as by a call to `reserve()`) invalidates the p=
ointer returned by a previous call to `data()`; as long as no reallocation =
happens, the pointer remains valid.</i></b></div><div><br></div><div>By log=
ical deduction on this newly added wording, we would be able to conclude th=
at the pointer returned from data() <i>prior</i> to a non-reallocating push=
_back() must be the same pointer as would have been returned <i>after</i> t=
he push_back(), and thus that the pointer returned by data() must necessari=
ly point to the address of front() even when front() hasn't yet been co=
nstructed. But we avoid saying so <i>explicitly</i>, and thus preserve the =
sacred mystery of std::vector against those philistines who would callously=
reduce it to a simple dynamically allocated array. :)</div><div><br></div>=
<div>=E2=80=93Arthur</div></div></div></div></blockquote><div>I think this =
is a little too strongly worded. It doesn't let .data() return an inval=
id pointer when the vector is empty() and it's capacity() is zero. I th=
ink it should be something like this:=C2=A0</div><div><br></div><div><div><=
span style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-siz=
e:12.8px">23.3.6.4 [vector.data]</span></div><div><span style=3D"font-famil=
y:"Open Sans",SegoeUI,sans-serif;font-size:12.8px">|=C2=A0 =C2=A0=
Returns: A pointer such that [data(),data() + size()) is a valid</span><br=
style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12=
..8px"><span style=3D"font-family:"Open Sans",SegoeUI,sans-serif;f=
ont-size:12.8px">|=C2=A0 =C2=A0 range.=C2=A0For a non-empty vector, data() =
=3D=3D &front().=C2=A0</span></div></div><div><span style=3D"font-famil=
y:"Open Sans",SegoeUI,sans-serif;font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-family:"Open Sans",SegoeUI,sans-serif=
;font-size:12.8px">To</span></div><div><span style=3D"font-family:"Ope=
n Sans",SegoeUI,sans-serif;font-size:12.8px"><br></span></div><div><di=
v><span style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-=
size:12.8px">23.3.6.4 [vector.data]</span></div><div><span style=3D"font-fa=
mily:"Open Sans",SegoeUI,sans-serif;font-size:12.8px">|=C2=A0 =C2=
=A0 Returns: A pointer such that [data(),data() + size()) is a valid</span>=
<br style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size=
:12.8px"><span style=3D"font-family:"Open Sans",SegoeUI,sans-seri=
f;font-size:12.8px">|=C2=A0 =C2=A0 range.=C2=A0For a non-empty vector, data=
() =3D=3D &front().<b> For a vector of capacity > 0 upon subsequent =
calls this pointer may not change unless a reallocation occurs; if a reallo=
cation occurs (such as by a call to 'reserve()') this pointer may b=
e invalidated and a new one returned. It is undefined what happens if this =
pointer is dereferenced until .size() > 0.</b></span></div></div><div><s=
pan style=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size=
:12.8px"><b><br></b></span></div><div><font face=3D"Open Sans, SegoeUI, san=
s-serif"><span style=3D"font-size:12.8px">This guarantees that when non-emp=
ty the pointer is to the front. And that when someone has first called rese=
rve but the vector is empty (capacity() > 0 && size() =3D=3D 0) =
that this pointer must point to the same place that the next push_back will=
.. We also state that this pointer cannot be dereferenced because it obvious=
ly doesn't make sense to allow someone to access possibly garbage data.=
But this should be enough to do any pointer logic to check for re-allocati=
ons, or store the pointer for use later until it's backed by valid data=
..</span></font></div><div><font face=3D"Open Sans, SegoeUI, sans-serif"><sp=
an style=3D"font-size:12.8px"><br></span></font></div><div><font face=3D"Op=
en Sans, SegoeUI, sans-serif"><span style=3D"font-size:12.8px">We want to g=
ive freedom for implementations when the capacity() is =3D=3D 0;</span></fo=
nt></div></div></blockquote><div><br></div><div>The pointer has to be valid=
when capacity() =3D=3D 0, in the sense that it can participate in arithmet=
ic operations with an offset of 0, since [data(), data() + size()) is a val=
id range even when size() and capacity() are both 0. I agree though that it=
would be best to avoid the term "valid" as much as possible, les=
t it give the impression that the pointer can be indirected or used in a pl=
acement new expression. Experience notwithstanding, it is surely unnecessar=
y for the Standard to labor the point that the contiguous range [data(), da=
ta() + size()) is all that can be formed.</div><div><br></div><div>To avoid=
a double negative, I would suggest "The value returned by data() is c=
hanged only by operations that cause reallocation. [Note: operations that i=
nsert and erase elements change the extent of the valid range [data(), data=
() + size()) but not its start. -- end note]"</div><div><br></div><div=
>It would also be necessary to state that swap() exchanges data() along wit=
h capacity() and the elements.=C2=A0</div><span class=3D""><div><br></div><=
div>I see one possible change in behavior: currently it is permissible for =
an implementation given a call to reserve() on an empty vector to defer any=
allocation to the first insert (and then allocate the full amount required=
by capacity()); this would no longer be possible (since data() is noexcept=
).=C2=A0</div></span></div></blockquote><div><br></div><div>This pointer ca=
n be zero in the case where capacity is zero and still be valid range.</div=
></div></blockquote><div><br></div><div>Yes, certainly. That means there=
9;s no need to restrict a data() stability clause to the case of nonzero ca=
pacity(). Your wording is equally workable if you strike the "capacity=
> 0" precondition.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div> I think it best to require that when the capac=
ity > 0 this pointer must be a "real - non-zero" pointer that =
points to the same place that the first element will be placed at (i.e to t=
he buffer). This would mean that allocations can no longer be deffered, but=
i don't see how that's an issue, i'd rather expect it to be a =
perk. Someone using reserve likely expects that to be the point where the a=
llocation occurs. =C2=A0</div></div></blockquote><div><br></div><div>From t=
he point of view of a user, certainly; from the point of view of an impleme=
nter it's an additional constraint. For example, they would be preclude=
d from deferring allocation to save resources if they have observed users c=
alling reserve() unnecessarily on vectors that they do not then use. They w=
ould also be unable to diagnose such misuse of the API by checking on destr=
uction whether reserve()d capacity has been used. Remember that the Standar=
d is written for the benefit of implementers as much as for users.</div><di=
v>=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><d=
iv>My proposal of the wording still stands:</div><div><div><span style=3D"f=
ont-family:"Open Sans",SegoeUI,sans-serif;font-size:12.8px">23.3.=
6.4 [vector.data]</span></div><div><span style=3D"font-family:"Open Sa=
ns",SegoeUI,sans-serif;font-size:12.8px">|=C2=A0 =C2=A0 Returns: A poi=
nter such that [data(),data() + size()) is a valid</span><br style=3D"font-=
family:"Open Sans",SegoeUI,sans-serif;font-size:12.8px"><span sty=
le=3D"font-family:"Open Sans",SegoeUI,sans-serif;font-size:12.8px=
">|=C2=A0 =C2=A0 range.=C2=A0For a non-empty vector, data() =3D=3D &fro=
nt().<b>=C2=A0For a vector of capacity > 0 upon subsequent calls this po=
inter may not change unless a reallocation occurs; if a reallocation occurs=
(such as by a call to 'reserve()') this pointer may be invalidated=
and a new one returned. It is undefined what happens if this pointer is de=
referenced until .size() > 0.</b></span></div></div></div><span class=3D=
"">
<p></p></span></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOaChxP8BkM0y_uEwek8_Qfx2CbBhnkx=
MSfS2H_Y9M4FEw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaChxP8BkM0=
y_uEwek8_Qfx2CbBhnkxMSfS2H_Y9M4FEw%40mail.gmail.com</a>.<br />
--94eb2c0776125b306805553bca1a--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Wed, 26 Jul 2017 11:55:40 -0700
Raw View
--f403045c1d6e96d3a105553cfea7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-)" Liber wrote:
>>>
>>> On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <e...@catmur.co.uk>
>>> wrote:
>>>
>>>>
>>>> I see one possible change in behavior: currently it is permissible for
>>>> an implementation given a call to reserve() on an empty vector to defe=
r any
>>>> allocation to the first insert (and then allocate the full amount requ=
ired
>>>> by capacity()); this would no longer be possible (since data() is
>>>> noexcept).
>>>>
>>>
>>> How exactly is that possible, given that the post condition for
>>> reserve(n) is capacity() >=3D n?
>>>
>>
>> Simple: you return the new capacity, but you didn't allocate any of the
>> memory behind it yet.
>>
>>
>>> If you defer the allocation, how can vector guarantee the allocation
>>> succeeds, especially since the allocation takes place in the allocator =
and
>>> not by vector itself?
>>>
>>
>> That's the sticking point. If there is unused capacity in a `vector`, if
>> `size()` < `capacity()`, then a vector is not allowed to fail due to
>> allocation errors. So it's unclear how an implementation could implement
>> this requirement and still not allocate upon `reserve` > `capacity`.
>>
>
> Am I missing something? [vector.modifiers] just says that in case no
> reallocation occurs on push_back() all pointers, iterators and references
> to elements remain valid; an empty vector has no elements, so this is
> trivially true. Is this somewhere within the overall library, container o=
r
> sequence container requirements?
>
Under the wording for "reserve" itself, N4659 says: "*No reallocation shall
take place during insertions* that happen after a call to reserve() *until*
the time when an insertion would make the size of the vector greater than
the value of capacity()."
The Standard never exactly defines what it means by "reallocation" AFAIK,
but my interpretation is that "reallocation" means "potentially make a call
to std::allocator_traits<V::allocator_type>::allocate(...)." If allocate()
can throw an exception or produce any other observable side effect (such as
logging messages), then "reallocation" is the time when that exception or
side effect must take place. Under my interpretation of the word
"reallocation", it is strictly forbidden for that side effect to take place
later, e.g. during push_back(), since at that time "no reallocation shall
take place" according to N4659.
vector<int> v;
assert(v.size() =3D=3D 0);
v.reserve(100);
assert(100 <=3D v.capacity());
assert(v.size() < v.capacity()); // because 0 < 100
v.emplace_back(); // "no reallocation shall take place" here
Therefore (under the above interpretation) it is *not* "permissible for an
implementation given a call to reserve() on an empty vector to defer any
allocation to the first insert".
I *think* this applies to plain old std::vector<T, std::allocator<T>> even
on a sufficiently clever compiler, because std::allocator<T> is required to
defer to ::operator new, and ::operator new *might* be overridden by the
user (with a definition that produces observable side effects), and we
can't possibly know that until link time. However, I admit that a
reasonable person might take the wording in [allocator.members]/2 "the
storage is obtained by calling ::operator new, but it is unspecified when
or how often this function is called" to be evidence *in favor* of a
sufficiently clever compiler actually being able to defer allocations until
insert-time, for containers that use std::allocator<T>. For containers that
use MyCustomAllocator<T>, the wording in [allocator.members]/2 is
irrelevant and everything stands or falls on the interpretation of the word
"reallocation" above.
Doing my part for the sacred mysteries,
=E2=80=93Arthur
--=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/CADvuK0LUaq4eF7V7ShdzGaBST2N%3Dpk9BTS6RmORvwWg8k=
W_fpg%40mail.gmail.com.
--f403045c1d6e96d3a105553cfea7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur' =
via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
a>></span> wrote:<div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><span class=3D"gmail-">On Wed, Jul 26, 2017 at 4:30 AM, Nicol B=
olas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D=
"_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
dir=3D"ltr">On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-=
)" Liber wrote:<span><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Tue, Jul 25,=
2017 at 6:27 PM, Edward Catmur <span dir=3D"ltr"><<a rel=3D"nofollow">e=
....@catmur.co.uk</a>></span> wrote:<br><div><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><div><br><span style=3D"color:rgb(34,=
34,34)">I see one possible change in behavior: currently it is permissible =
for an implementation given a call to reserve() on an empty vector to defer=
any allocation to the first insert (and then allocate the full amount requ=
ired by capacity()); this would no longer be possible (since data() is noex=
cept).=C2=A0</span></div></div></div></blockquote><div><br></div><div>How e=
xactly is that possible, given that the post condition for reserve(n) is ca=
pacity() >=3D n?</div></div></div></div></blockquote></span><div><br>Sim=
ple: you return the new capacity, but you didn't allocate any of the me=
mory behind it yet.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>If you defer the allocation, how can v=
ector guarantee the allocation succeeds, especially since the allocation ta=
kes place in the allocator and not by vector itself?</div></div></div></div=
></blockquote></span><div><br>That's the sticking point. If there is un=
used capacity in a `vector`, if `size()` < `capacity()`, then a vector i=
s not allowed to fail due to allocation errors. So it's unclear how an =
implementation could implement this requirement and still not allocate upon=
`reserve` > `capacity`.</div></div></blockquote><div><br></div></span><=
div>Am I missing something? [vector.modifiers] just says that in case no re=
allocation occurs on push_back() all pointers, iterators and references to =
elements remain valid; an empty vector has no elements, so this is triviall=
y true. Is this somewhere within the overall library, container or sequence=
container requirements?</div></div></div></div></blockquote><div><br></div=
>Under the wording for "reserve" itself, N4659 says: "<b>No =
reallocation shall take place during insertions</b> that happen after a cal=
l to reserve() <b>until</b> the time when an insertion would make the size =
of the vector greater than the value of capacity()."<br><br>The Standa=
rd never exactly defines what it means by "reallocation" AFAIK, b=
ut my interpretation is that "reallocation" means "potential=
ly make a call to std::allocator_traits<V::allocator_type>::allocate(=
....)." =C2=A0If allocate() can throw an exception or produce any other=
observable side effect (such as logging messages), then "reallocation=
" is the time when that exception or side effect must take place. Unde=
r my interpretation of the word "reallocation", it is strictly fo=
rbidden for that side effect to take place later, e.g. during push_back(), =
since at that time "no reallocation shall take place" according t=
o N4659.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quot=
e">=C2=A0 =C2=A0 vector<int> v;</div><div class=3D"gmail_quote">=C2=
=A0 =C2=A0 assert(v.size() =3D=3D 0);</div><div class=3D"gmail_quote">=C2=
=A0 =C2=A0 v.reserve(100);</div><div class=3D"gmail_quote">=C2=A0 =C2=A0 as=
sert(100 <=3D v.capacity());</div><div class=3D"gmail_quote">=C2=A0 =C2=
=A0 assert(v.size() < v.capacity()); =C2=A0// because 0 < 100</div><d=
iv class=3D"gmail_quote">=C2=A0 =C2=A0 v.emplace_back(); =C2=A0 // "no=
reallocation shall take place" here<br></div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote">Therefore (under the above interpre=
tation) it is <b>not</b> "permissible for an implementation given a ca=
ll to reserve() on an empty vector to defer any allocation to the first ins=
ert".</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote">I <i>think</i> this applies to plain old std::vector<T, std::alloca=
tor<T>> even on a sufficiently clever compiler, because std::alloc=
ator<T> is required to defer to ::operator new, and ::operator new <i=
>might</i> be overridden by the user (with a definition that produces obser=
vable side effects), and we can't possibly know that until link time. H=
owever, I admit that a reasonable person might take the wording in [allocat=
or.members]/2=C2=A0"the storage is obtained by calling ::operator new,=
but it is unspecified when or how often this function is called" to b=
e evidence=C2=A0<i>in favor</i> of a sufficiently clever compiler actually =
being able to defer allocations until insert-time, for containers that use =
std::allocator<T>. For containers that use MyCustomAllocator<T>=
, the wording in [allocator.members]/2 is irrelevant and everything stands =
or falls on the interpretation of the word "reallocation" above.<=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></=
div><div class=3D"gmail_quote">Doing my part for the sacred mysteries,</div=
><div class=3D"gmail_quote">=E2=80=93Arthur</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0LUaq4eF7V7ShdzGaBST2N%3Dpk9BTS=
6RmORvwWg8kW_fpg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LUaq4eF7=
V7ShdzGaBST2N%3Dpk9BTS6RmORvwWg8kW_fpg%40mail.gmail.com</a>.<br />
--f403045c1d6e96d3a105553cfea7--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 26 Jul 2017 13:08:33 -0700 (PDT)
Raw View
------=_Part_149_998904493.1501099713995
Content-Type: multipart/alternative;
boundary="----=_Part_150_1775628293.1501099713995"
------=_Part_150_1775628293.1501099713995
Content-Type: text/plain; charset="UTF-8"
On Wednesday, July 26, 2017 at 2:55:44 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> On Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <jmck...@gmail.com
>> <javascript:>> wrote:
>>
>>> On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-)" Liber wrote:
>>>>
>>>> On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <e...@catmur.co.uk>
>>>> wrote:
>>>>
>>>>>
>>>>> I see one possible change in behavior: currently it is permissible for
>>>>> an implementation given a call to reserve() on an empty vector to defer any
>>>>> allocation to the first insert (and then allocate the full amount required
>>>>> by capacity()); this would no longer be possible (since data() is
>>>>> noexcept).
>>>>>
>>>>
>>>> How exactly is that possible, given that the post condition for
>>>> reserve(n) is capacity() >= n?
>>>>
>>>
>>> Simple: you return the new capacity, but you didn't allocate any of the
>>> memory behind it yet.
>>>
>>>
>>>> If you defer the allocation, how can vector guarantee the allocation
>>>> succeeds, especially since the allocation takes place in the allocator and
>>>> not by vector itself?
>>>>
>>>
>>> That's the sticking point. If there is unused capacity in a `vector`, if
>>> `size()` < `capacity()`, then a vector is not allowed to fail due to
>>> allocation errors. So it's unclear how an implementation could implement
>>> this requirement and still not allocate upon `reserve` > `capacity`.
>>>
>>
>> Am I missing something? [vector.modifiers] just says that in case no
>> reallocation occurs on push_back() all pointers, iterators and references
>> to elements remain valid; an empty vector has no elements, so this is
>> trivially true. Is this somewhere within the overall library, container or
>> sequence container requirements?
>>
>
> Under the wording for "reserve" itself, N4659 says: "*No reallocation
> shall take place during insertions* that happen after a call to reserve()
> *until* the time when an insertion would make the size of the vector
> greater than the value of capacity()."
>
> The Standard never exactly defines what it means by "reallocation" AFAIK,
>
Actually, that might make for a really good defect report. The standard
defines the effect of reallocation on iterators/et. al in several places,
but it defines them all *differently* in those places. For example:
> Reallocation invalidates all the references, pointers, and iterators
referring to the elements in the sequence.
> Reallocation invalidates all the references, pointers, and iterators
referring to the elements in the sequence as well as the past-the-end
iterator.
The first one is from `reserve`; the second is from `shrink_to_fit`. Notice
the difference? Yes, the "past-the-end" iterator bit is not stated in
`reserve`. By that reasoning, if you `reserve` elements, your past-the-end
iterator should *always* be fine, but not if `shrink_to_fit` provokes
reallocation.
So yes, the meaning of reallocation needs to be spelled out and
*centralized*, so that there can be no further errors of this type.
`basic_string` should likewise be adjusted.
--
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/45d228c5-6b66-4426-a620-bcfc33f79c94%40isocpp.org.
------=_Part_150_1775628293.1501099713995
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, July 26, 2017 at 2:55:44 PM UTC-4, A=
rthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur' via IS=
O C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"czgYjst4AAAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a=
>></span> wrote:<div><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote"><span>On Wed, Jul 26, 2017 at 4:3=
0 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"czgYjst4AAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">jmck...@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr">On Tuesday, July 25, 2017 at 10:59:34=
PM UTC-4, Nevin ":-)" Liber wrote:<span><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr">On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <span dir=3D"ltr">=
<<a rel=3D"nofollow">e...@catmur.co.uk</a>></span> wrote:<br><div><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br><sp=
an style=3D"color:rgb(34,34,34)">I see one possible change in behavior: cur=
rently it is permissible for an implementation given a call to reserve() on=
an empty vector to defer any allocation to the first insert (and then allo=
cate the full amount required by capacity()); this would no longer be possi=
ble (since data() is noexcept).=C2=A0</span></div></div></div></blockquote>=
<div><br></div><div>How exactly is that possible, given that the post condi=
tion for reserve(n) is capacity() >=3D n?</div></div></div></div></block=
quote></span><div><br>Simple: you return the new capacity, but you didn'=
;t allocate any of the memory behind it yet.<br>=C2=A0</div><span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>If you defer =
the allocation, how can vector guarantee the allocation succeeds, especiall=
y since the allocation takes place in the allocator and not by vector itsel=
f?</div></div></div></div></blockquote></span><div><br>That's the stick=
ing point. If there is unused capacity in a `vector`, if `size()` < `cap=
acity()`, then a vector is not allowed to fail due to allocation errors. So=
it's unclear how an implementation could implement this requirement an=
d still not allocate upon `reserve` > `capacity`.</div></div></blockquot=
e><div><br></div></span><div>Am I missing something? [vector.modifiers] jus=
t says that in case no reallocation occurs on push_back() all pointers, ite=
rators and references to elements remain valid; an empty vector has no elem=
ents, so this is trivially true. Is this somewhere within the overall libra=
ry, container or sequence container requirements?</div></div></div></div></=
blockquote><div><br></div>Under the wording for "reserve" itself,=
N4659 says: "<b>No reallocation shall take place during insertions</b=
> that happen after a call to reserve() <b>until</b> the time when an inser=
tion would make the size of the vector greater than the value of capacity()=
.."<br><br>The Standard never exactly defines what it means by "re=
allocation" AFAIK,</div></div></div></blockquote><div><br>Actually, th=
at might make for a really good defect report. The standard defines the eff=
ect of reallocation on iterators/et. al in several places, but it defines t=
hem all <i>differently</i> in those places. For example:<br><br>>=C2=A0 =
Reallocation invalidates all the references, pointers, and iterators referr=
ing to the elements in the sequence.<br><br>>=C2=A0 Reallocation invalid=
ates all the references, pointers, and iterators referring to the elements =
in the sequence as well as the past-the-end iterator.<br><br>The first one =
is from `reserve`; the second is from `shrink_to_fit`. Notice the differenc=
e? Yes, the "past-the-end" iterator bit is not stated in `reserve=
`. By that reasoning, if you `reserve` elements, your past-the-end iterator=
should <i>always</i> be fine, but not if `shrink_to_fit` provokes realloca=
tion.<br><br>So yes, the meaning of reallocation needs to be spelled out an=
d <i>centralized</i>, so that there can be no further errors of this type. =
`basic_string` should likewise be adjusted.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/45d228c5-6b66-4426-a620-bcfc33f79c94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45d228c5-6b66-4426-a620-bcfc33f79c94=
%40isocpp.org</a>.<br />
------=_Part_150_1775628293.1501099713995--
------=_Part_149_998904493.1501099713995--
.
Author: Ross Smith <ross.smith@otoy.com>
Date: Thu, 27 Jul 2017 08:46:14 +1200
Raw View
On 2017-07-26 11:27, Edward Catmur wrote:
>
> To avoid a double negative, I would suggest "The value returned by
> data() is changed only by operations that cause reallocation. [Note:
> operations that insert and erase elements change the extent of the valid
> range [data(), data() + size()) but not its start. -- end note]"
>
> It would also be necessary to state that swap() exchanges data() along
> with capacity() and the elements.
It might also be necessary to specify the behaviour when moving a
vector, depending on what people decide is reasonable. If we write
vec2=std::move(vec1), do we expect the new vec2.data() to equal the old
vec1.data() always?
Ross Smith
--
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/af440d6a-fc4c-894d-b5d2-8719fad4fba9%40otoy.com.
.
Author: Ross Smith <ross.smith@otoy.com>
Date: Thu, 27 Jul 2017 08:51:35 +1200
Raw View
On 2017-07-26 11:27, Edward Catmur wrote:
>
> To avoid a double negative, I would suggest "The value returned by
> data() is changed only by operations that cause reallocation. [Note:
> operations that insert and erase elements change the extent of the valid
> range [data(), data() + size()) but not its start. -- end note]"
>
> It would also be necessary to state that swap() exchanges data() along
> with capacity() and the elements.
It might also be necessary to specify the behaviour when moving a
vector, depending on what people decide is reasonable. If we write
vec2=std::move(vec1), do we expect the new vec2.data() to equal the old
vec1.data() always?
Ross Smith
(apologies if this shows up twice, had posting errors and I only see the
list via gmane so I can't tell if the first attempt reached the mailing
list)
--
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/ce26b867-9647-f199-145c-a0b257d34ab3%40otoy.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 26 Jul 2017 23:52:14 +0300
Raw View
On 26 July 2017 at 23:46, Ross Smith <ross.smith@otoy.com> wrote:
> On 2017-07-26 11:27, Edward Catmur wrote:
>>
>>
>> To avoid a double negative, I would suggest "The value returned by data()
>> is changed only by operations that cause reallocation. [Note: operations
>> that insert and erase elements change the extent of the valid range [data(),
>> data() + size()) but not its start. -- end note]"
>>
>> It would also be necessary to state that swap() exchanges data() along
>> with capacity() and the elements.
>
>
> It might also be necessary to specify the behaviour when moving a vector,
> depending on what people decide is reasonable. If we write
> vec2=std::move(vec1), do we expect the new vec2.data() to equal the old
> vec1.data() always?
That depends on what the actual types of vec2 and vec1 are and whether
poc2 is const or not, since you need to take
POCCA and POCMA into account.
--
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/CAFk2RUZuDG82ACVVcviYpAKC5K5Q533UXLuZied4s4NJZWeiBw%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 26 Jul 2017 23:53:09 +0300
Raw View
On 26 July 2017 at 23:52, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 26 July 2017 at 23:46, Ross Smith <ross.smith@otoy.com> wrote:
>> On 2017-07-26 11:27, Edward Catmur wrote:
>>>
>>>
>>> To avoid a double negative, I would suggest "The value returned by data()
>>> is changed only by operations that cause reallocation. [Note: operations
>>> that insert and erase elements change the extent of the valid range [data(),
>>> data() + size()) but not its start. -- end note]"
>>>
>>> It would also be necessary to state that swap() exchanges data() along
>>> with capacity() and the elements.
>>
>>
>> It might also be necessary to specify the behaviour when moving a vector,
>> depending on what people decide is reasonable. If we write
>> vec2=std::move(vec1), do we expect the new vec2.data() to equal the old
>> vec1.data() always?
>
>
> That depends on what the actual types of vec2 and vec1 are and whether
> poc2 is const or not, since you need to take
> POCCA and POCMA into account.
And I mean vec2 instead of poc2. Once the mind wanders into the
POCCA/POCMA-land, funny
things happen.
--
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/CAFk2RUa9X%3Df03RiFURZd9x4aOzOS%3D%3DJ2OXJ9UG-7sKSFWu_uNw%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 26 Jul 2017 23:53:41 +0300
Raw View
On 26 July 2017 at 23:53, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 26 July 2017 at 23:52, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>> On 26 July 2017 at 23:46, Ross Smith <ross.smith@otoy.com> wrote:
>>> On 2017-07-26 11:27, Edward Catmur wrote:
>>>>
>>>>
>>>> To avoid a double negative, I would suggest "The value returned by data()
>>>> is changed only by operations that cause reallocation. [Note: operations
>>>> that insert and erase elements change the extent of the valid range [data(),
>>>> data() + size()) but not its start. -- end note]"
>>>>
>>>> It would also be necessary to state that swap() exchanges data() along
>>>> with capacity() and the elements.
>>>
>>>
>>> It might also be necessary to specify the behaviour when moving a vector,
>>> depending on what people decide is reasonable. If we write
>>> vec2=std::move(vec1), do we expect the new vec2.data() to equal the old
>>> vec1.data() always?
>>
>>
>> That depends on what the actual types of vec2 and vec1 are and whether
>> poc2 is const or not, since you need to take
>> POCCA and POCMA into account.
>
> And I mean vec2 instead of poc2. Once the mind wanders into the
> POCCA/POCMA-land, funny
> things happen.
And to add insult to injury, I mean vec1, not vec2. :)
--
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/CAFk2RUaELDkmxrhpDR%2BKSAanOCk6EacAwR2BgmaAHUxKniCCxg%40mail.gmail.com.
.
Author: Dan Raviv <dan.raviv@gmail.com>
Date: Thu, 27 Jul 2017 00:19:38 +0300
Raw View
--001a113d37e8a9f72105553f0247
Content-Type: text/plain; charset="UTF-8"
So it's unclear whether reserve() is allowed to postpone the actual
allocation?
I rely on it to do the actual allocation and defer it to later when
preparing for real-time rendering code which must not do allocations.
I guess I should use resize() instead. Though, to maintain the "logical"
interface of the vector, as if no elements have been inserted, that resize
should be immediately followed by a resize(0). Pretty ugly.
On Wed, Jul 26, 2017 at 11:08 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Wednesday, July 26, 2017 at 2:55:44 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals <std-pr...@isocpp.org> wrote:
>>
>>> On Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-)" Liber wrote:
>>>>>
>>>>> On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <e...@catmur.co.uk>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> I see one possible change in behavior: currently it is permissible
>>>>>> for an implementation given a call to reserve() on an empty vector to defer
>>>>>> any allocation to the first insert (and then allocate the full amount
>>>>>> required by capacity()); this would no longer be possible (since data() is
>>>>>> noexcept).
>>>>>>
>>>>>
>>>>> How exactly is that possible, given that the post condition for
>>>>> reserve(n) is capacity() >= n?
>>>>>
>>>>
>>>> Simple: you return the new capacity, but you didn't allocate any of the
>>>> memory behind it yet.
>>>>
>>>>
>>>>> If you defer the allocation, how can vector guarantee the allocation
>>>>> succeeds, especially since the allocation takes place in the allocator and
>>>>> not by vector itself?
>>>>>
>>>>
>>>> That's the sticking point. If there is unused capacity in a `vector`,
>>>> if `size()` < `capacity()`, then a vector is not allowed to fail due to
>>>> allocation errors. So it's unclear how an implementation could implement
>>>> this requirement and still not allocate upon `reserve` > `capacity`.
>>>>
>>>
>>> Am I missing something? [vector.modifiers] just says that in case no
>>> reallocation occurs on push_back() all pointers, iterators and references
>>> to elements remain valid; an empty vector has no elements, so this is
>>> trivially true. Is this somewhere within the overall library, container or
>>> sequence container requirements?
>>>
>>
>> Under the wording for "reserve" itself, N4659 says: "*No reallocation
>> shall take place during insertions* that happen after a call to
>> reserve() *until* the time when an insertion would make the size of the
>> vector greater than the value of capacity()."
>>
>> The Standard never exactly defines what it means by "reallocation" AFAIK,
>>
>
> Actually, that might make for a really good defect report. The standard
> defines the effect of reallocation on iterators/et. al in several places,
> but it defines them all *differently* in those places. For example:
>
> > Reallocation invalidates all the references, pointers, and iterators
> referring to the elements in the sequence.
>
> > Reallocation invalidates all the references, pointers, and iterators
> referring to the elements in the sequence as well as the past-the-end
> iterator.
>
> The first one is from `reserve`; the second is from `shrink_to_fit`.
> Notice the difference? Yes, the "past-the-end" iterator bit is not stated
> in `reserve`. By that reasoning, if you `reserve` elements, your
> past-the-end iterator should *always* be fine, but not if `shrink_to_fit`
> provokes reallocation.
>
> So yes, the meaning of reallocation needs to be spelled out and
> *centralized*, so that there can be no further errors of this type.
> `basic_string` should likewise be adjusted.
>
> --
> 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/45d228c5-6b66-4426-
> a620-bcfc33f79c94%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/45d228c5-6b66-4426-a620-bcfc33f79c94%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADw4SdQqCe3s79r2V8oNRMTnsteD9tw8eYwcf0wLOoV-Z2G8eA%40mail.gmail.com.
--001a113d37e8a9f72105553f0247
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So it's unclear whether reserve() is allowed to postpo=
ne the actual allocation?<div>I rely on it to do the actual allocation and =
defer it to later when preparing for real-time rendering code which must no=
t do allocations.=C2=A0</div><div><br></div><div>I guess I should use resiz=
e() instead. Though, to maintain the "logical" interface of the v=
ector, as if no elements have been inserted, that resize should be immediat=
ely followed by a resize(0). Pretty ugly.</div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Wed, Jul 26, 2017 at 11:08 PM, Nicol=
Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, July 26, 2017 at 2:55:=
44 PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur=
9; via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a rel=3D"=
nofollow">std-pr...@isocpp.org</a>></span> wrote:<span class=3D""><div><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><span>On Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <span d=
ir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr">On Tuesday, July 25, 2017 at 10:59:34 =
PM UTC-4, Nevin ":-)" Liber wrote:<span><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <span dir=3D"ltr">&=
lt;<a rel=3D"nofollow">e...@catmur.co.uk</a>></span> wrote:<br><div><div=
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br><spa=
n style=3D"color:rgb(34,34,34)">I see one possible change in behavior: curr=
ently it is permissible for an implementation given a call to reserve() on =
an empty vector to defer any allocation to the first insert (and then alloc=
ate the full amount required by capacity()); this would no longer be possib=
le (since data() is noexcept).=C2=A0</span></div></div></div></blockquote><=
div><br></div><div>How exactly is that possible, given that the post condit=
ion for reserve(n) is capacity() >=3D n?</div></div></div></div></blockq=
uote></span><div><br>Simple: you return the new capacity, but you didn'=
t allocate any of the memory behind it yet.<br>=C2=A0</div><span><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>If you defer t=
he allocation, how can vector guarantee the allocation succeeds, especially=
since the allocation takes place in the allocator and not by vector itself=
?</div></div></div></div></blockquote></span><div><br>That's the sticki=
ng point. If there is unused capacity in a `vector`, if `size()` < `capa=
city()`, then a vector is not allowed to fail due to allocation errors. So =
it's unclear how an implementation could implement this requirement and=
still not allocate upon `reserve` > `capacity`.</div></div></blockquote=
><div><br></div></span><div>Am I missing something? [vector.modifiers] just=
says that in case no reallocation occurs on push_back() all pointers, iter=
ators and references to elements remain valid; an empty vector has no eleme=
nts, so this is trivially true. Is this somewhere within the overall librar=
y, container or sequence container requirements?</div></div></div></div></b=
lockquote><div><br></div>Under the wording for "reserve" itself, =
N4659 says: "<b>No reallocation shall take place during insertions</b>=
that happen after a call to reserve() <b>until</b> the time when an insert=
ion would make the size of the vector greater than the value of capacity().=
"<br><br>The Standard never exactly defines what it means by "rea=
llocation" AFAIK,</div></div></span></div></blockquote><div><br>Actual=
ly, that might make for a really good defect report. The standard defines t=
he effect of reallocation on iterators/et. al in several places, but it def=
ines them all <i>differently</i> in those places. For example:<br><br>>=
=C2=A0 Reallocation invalidates all the references, pointers, and iterators=
referring to the elements in the sequence.<br><br>>=C2=A0 Reallocation =
invalidates all the references, pointers, and iterators referring to the el=
ements in the sequence as well as the past-the-end iterator.<br><br>The fir=
st one is from `reserve`; the second is from `shrink_to_fit`. Notice the di=
fference? Yes, the "past-the-end" iterator bit is not stated in `=
reserve`. By that reasoning, if you `reserve` elements, your past-the-end i=
terator should <i>always</i> be fine, but not if `shrink_to_fit` provokes r=
eallocation.<br><br>So yes, the meaning of reallocation needs to be spelled=
out and <i>centralized</i>, so that there can be no further errors of this=
type. `basic_string` should likewise be adjusted.<br></div></div><span cla=
ss=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/45d228c5-6b66-4426-a620-bcfc33f79c94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/45d2=
28c5-6b66-4426-<wbr>a620-bcfc33f79c94%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CADw4SdQqCe3s79r2V8oNRMTnsteD9tw8eYwc=
f0wLOoV-Z2G8eA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADw4SdQqCe3s79r2=
V8oNRMTnsteD9tw8eYwcf0wLOoV-Z2G8eA%40mail.gmail.com</a>.<br />
--001a113d37e8a9f72105553f0247--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 26 Jul 2017 16:49:01 -0500
Raw View
--f4030435b33ce7c88005553f6c5b
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 4:19 PM, Dan Raviv <dan.raviv@gmail.com> wrote:
> So it's unclear whether reserve() is allowed to postpone the actual
> allocation?
>
I don't think it is unclear. If you think it is, file a defect report,
because AFAIK that isn't intentional.
> I rely on it to do the actual allocation and defer it to later
>
So do many others, including myself.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP%3DsiKdhTZkMRrwQeu%2B6B1d7YbVzrEy9wTn8v_K0Wsbjg%40mail.gmail.com.
--f4030435b33ce7c88005553f6c5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Jul 26, 2017 at 4:19 PM, Dan Raviv <span dir=3D"lt=
r"><<a href=3D"mailto:dan.raviv@gmail.com" target=3D"_blank">dan.raviv@g=
mail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So it's un=
clear whether reserve() is allowed to postpone the actual allocation?</div>=
</blockquote><div><br></div><div>I don't think it is unclear.=C2=A0 If =
you think it is, file a defect report, because AFAIK that isn't intenti=
onal.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>I rely on it to do the actual allocation and defer it to later</div><=
/div></blockquote><div>=C2=A0</div><div>So do many others, including myself=
..</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_=
signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-=
)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" ta=
rget=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div><=
/div></div></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" 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/CAGg_6%2BP%3DsiKdhTZkMRrwQeu%2B6B1d7Y=
bVzrEy9wTn8v_K0Wsbjg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP%=
3DsiKdhTZkMRrwQeu%2B6B1d7YbVzrEy9wTn8v_K0Wsbjg%40mail.gmail.com</a>.<br />
--f4030435b33ce7c88005553f6c5b--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 01:02:31 +0300
Raw View
On 27 July 2017 at 00:49, Nevin Liber <nevin@eviloverlord.com> wrote:
> On Wed, Jul 26, 2017 at 4:19 PM, Dan Raviv <dan.raviv@gmail.com> wrote:
>>
>> So it's unclear whether reserve() is allowed to postpone the actual
>> allocation?
>
>
> I don't think it is unclear. If you think it is, file a defect report,
> because AFAIK that isn't intentional.
Don't waste our time with a nonsense "defect" report.
[vector.capacity]/6:
No reallocation shall take place during insertions that happen after a
call to reserve()
until the time when an insertion would make the size of the vector
greater than the value of capacity().
--
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/CAFk2RUYZ0i%3DG6wNoMSe6Rp%3DVZ1iYq4uzx%3Df6D5AkkdpAR5DJXA%40mail.gmail.com.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 26 Jul 2017 15:11:10 -0700 (PDT)
Raw View
------=_Part_311_1766685520.1501107070929
Content-Type: multipart/alternative;
boundary="----=_Part_312_1611443251.1501107070929"
------=_Part_312_1611443251.1501107070929
Content-Type: text/plain; charset="UTF-8"
I agree with Nicol. This snippet he wrote is what we need, I don't see how
the remainder of this thread can get around the fact that even if you could
get a valid pointer after just doing reserve you can't resize after filling
the buffer without overwriting it.
>
> vector<int> v(10, std::default_init);
> memcpy(v.data(), ..., 10 * sizeof(int));
>
I think this the only thing we need: A way to get default construction
instead of value construction. There are numerous cases where you want to
call legacy functions which take a T* and let them fill your pre-sized
vector but don't want the overhead of the value construction. This would
solve the OPs problem, as he would always need to know the size before
resizing anyway he can just as well resize first and then use operator[]
instead of push_back after observing the allocation address.
This feature could be complemented by a rule that says that
if_constructible_v<T, std::default_init> then the T(std::default_init)
constructor is to be called by the newly added vector constructor rather
than the T() constructor. This would allow certain performance critical
types such as for instance a Point class to provide distinct value and
default constructors (albeit with somewhat misleading names):
struct Point {
Point() : x(0), y(0) {} // value constructor
Point(std::default_init) {} // default constructor
Point(int _x, int _y) : x(_x), y(_y) {}
int x, y;
};
This would allow a vector of Points to be resized without zeroing all the x
and y members. This is of course less commonly needed than buffers of built
in types but seems to be a logical extension if a std::default_init
constructor/resize signature is added to vector (and maybe other
containers, at least deque).
This could be extended, with the help of core language features, to allow
the same distinction for variables or at least new expressions:
T x(); // *Unfortunately not a value
constructed variable but a forward declared function...*
T y; // default constructed
T z(std::default_init()); // default constructed
T* a = new T; // default constructed
T* b = new T(); // value constructed
T* c = new T[100]; // default constructed array
T* d = new T[100](); // *New syntax required to get value construction*
The problems I could find are highlighted in bold. Note however that there
is no backward compatibility issue as there is currently no
std::default_init type to use, so noone can have written a constructor with
this type as parameter. Not being able to value construct variables when
there is a default constructor specified for the type seems very
restricting though. As we are already in the area of messing up language
with std library we could add another magic type std::value_init and an
operator new() overload to handle these cases:
T x(std::value_init()); // value constructed
T y; // default constructed
T z(std::default_init()); // default constructed
T* a = new T; // default constructed
T* b = new T(); // value constructed
T* c = new T[100]; // default constructed array
T* d = new(std::value_init()) T[100]; // New overloaded new to get value
construction
Still annoying to have to write that much to inform the parser that you are
not declaring a function x but notably this only happens if there is a
separate value vs. default constructor. If there is no constructor taking
std::default_init the T() constructor will be used in all cases.
If we can't find a better way to spell out the desire for value or default
construction when defining variables I don't think this is reasonable to
add and would suggest only the library feature, i.e. a new
constructor/resize tagged to use default construction. I think it would
also be good to check for the T(std::default_init) constructor but this is
maybe less important. One drawback with not having this feature is that
people may think it exists and write:
vector<Point> ps(100, std::default_init());
If there is no special handling this would still call T() ignoring the
other constructor, and there would still be no way to set up a buffer of
points without zeroing it.
This type of buffer handling is typical when interacting with libraries
such as OpenGL through a C++ wrapper layer, where performance is often
critical.
--
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/9950433b-abfb-47e8-8a09-f4e34a9947bf%40isocpp.org.
------=_Part_312_1611443251.1501107070929
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I agree with Nicol. This snippet he wrote is what we =
need, I don't see how the remainder of this thread can get around the f=
act that even if you could get a valid pointer after just doing reserve you=
can't resize after filling the buffer without overwriting it.=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px"><code><div><span style=3D"color:#000=
">vector</span><span style=3D"color:#080"><int></span><span style=3D"=
color:#000"> v</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#066">10</span><span style=3D"color:#660">,</span><span style=3D"color:#0=
00"> std</span><span style=3D"color:#660">::</span><span style=3D"color:#00=
0">default_init</span><span style=3D"color:#660">);</span><span style=3D"co=
lor:#000"><br>memcpy</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">v</span><span style=3D"color:#660">.</span><span style=3D"c=
olor:#000">data</span><span style=3D"color:#660">(),</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">...,</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#066">10</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">*</span><span style=3D"color:#000">=
</span><span style=3D"color:#008">sizeof</span><span style=3D"color:#660">=
(</span><span style=3D"color:#008">int</span><span style=3D"color:#660">));=
</span></div></code></div></div></div></blockquote><div><br></div><div>I th=
ink this the only thing we need: A way to get default construction instead =
of value construction. There are numerous cases where you want to call lega=
cy functions which take a T* and let them fill your pre-sized vector but do=
n't want the overhead of the value construction. This would solve the O=
Ps problem, as he would always need to know the size before resizing anyway=
he can just as well resize first and then use operator[] instead of push_b=
ack after observing the allocation address.</div><div><br></div><div>This f=
eature could be complemented by a rule that says that if_constructible_v<=
;T,=C2=A0<span style=3D"font-family: monospace; background-color: rgb(250, =
250, 250); color: rgb(0, 0, 0);">std</span><span style=3D"font-family: mono=
space; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">::</=
span><span style=3D"font-family: monospace; background-color: rgb(250, 250,=
250); color: rgb(0, 0, 0);">default_init>=C2=A0</span>then the T(std::d=
efault_init) constructor is to be called by the newly added vector construc=
tor rather than the T() constructor. This would allow certain performance c=
ritical types such as for instance a Point class to provide distinct value =
and default constructors (albeit with somewhat misleading names):</div><div=
><br></div><div>struct Point {</div><div>=C2=A0 =C2=A0 Point() : x(0), y(0)=
{} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=
/ value constructor</div><div>=C2=A0 =C2=A0 Point(std::default_init) {} =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// default constructor</div><d=
iv>=C2=A0 =C2=A0 Point(int _x, int _y) : x(_x), y(_y) {}</div><div>=C2=A0 =
=C2=A0 int x, y;</div><div>};</div><div><br></div><div>This would allow a v=
ector of Points to be resized without zeroing all the x and y members. This=
is of course less commonly needed than buffers of built in types but seems=
to be a logical extension if a std::default_init constructor/resize signat=
ure is added to vector (and maybe other containers, at least deque).</div><=
div><br></div><div>This could be extended, with the help of core language f=
eatures, to allow the same distinction for variables or at least new expres=
sions:</div><div><br></div><div>T x(); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // <b>Unfort=
unately not a value constructed variable but a forward declared function...=
</b><br></div><div>T y; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // default construc=
ted</div><div>T z(std::default_init()); =C2=A0// default constructed</div><=
div><br></div><div><div>T* a =3D new T; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0// default constructed</div><div>T* b =3D new T(); =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // value constructed</div></div><div=
><br></div><div>T* c =3D new T[100]; =C2=A0 =C2=A0 =C2=A0// default constru=
cted array</div><div>T* d =3D new T[100](); =C2=A0 // <b>New syntax require=
d to get value construction</b></div><div><b><br></b></div><div>The problem=
s I could find are highlighted in bold. Note however that there is no backw=
ard compatibility issue as there is currently no std::default_init type to =
use, so noone can have written a constructor with this type as parameter. N=
ot being able to value construct variables when there is a default construc=
tor specified for the type seems very restricting though. As we are already=
in the area of messing up language with std library we could add another m=
agic type std::value_init and an operator new() overload to handle these ca=
ses:</div><div><br></div><div><br></div><div><div>T x(std::value_init()); =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //=C2=A0value constructed<br></div><div>=
T y; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// default co=
nstructed</div><div>T z(std::default_init()); =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=
/ default constructed</div><div><br></div><div><div>T* a =3D new T; =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // de=
fault constructed</div><div>T* b =3D new T(); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// value constructed</div></div><d=
iv><br></div><div>T* c =3D new T[100]; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // default constructed array</div><div>T* d =3D new(std::valu=
e_init()) T[100]; =C2=A0 //=C2=A0New overloaded new to get value constructi=
on</div></div><div><b><br></b></div><div>Still annoying to have to write th=
at much to inform the parser that you are not declaring a function x but no=
tably this only happens if there is a separate value vs. default constructo=
r. If there is no constructor taking std::default_init the T() constructor =
will be used in all cases.</div><div><br></div><div>If we can't find a =
better way to spell out the desire for value or default construction when d=
efining variables I don't think this is reasonable to add and would sug=
gest only the library feature, i.e. a new constructor/resize tagged to use =
default construction. I think it would also be good to check for the T(std:=
:default_init) constructor but this is maybe less important. One drawback w=
ith not having this feature is that people may think it exists and write:</=
div><div><br></div><div>vector<Point> ps(100, std::default_init());</=
div><div><br></div><div>If there is no special handling this would still ca=
ll T() ignoring the other constructor, and there would still be no way to s=
et up a buffer of points without zeroing it.=C2=A0</div><div><br></div><div=
>This type of buffer handling is typical when interacting with libraries su=
ch as OpenGL through a C++ wrapper layer, where performance is often critic=
al.</div><div><br></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" 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/9950433b-abfb-47e8-8a09-f4e34a9947bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9950433b-abfb-47e8-8a09-f4e34a9947bf=
%40isocpp.org</a>.<br />
------=_Part_312_1611443251.1501107070929--
------=_Part_311_1766685520.1501107070929--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 26 Jul 2017 15:50:21 -0700 (PDT)
Raw View
------=_Part_361_2007291235.1501109421959
Content-Type: multipart/alternative;
boundary="----=_Part_362_42177511.1501109421960"
------=_Part_362_42177511.1501109421960
Content-Type: text/plain; charset="UTF-8"
On Wednesday, July 26, 2017 at 6:02:34 PM UTC-4, Ville Voutilainen wrote:
>
> On 27 July 2017 at 00:49, Nevin Liber <ne...@eviloverlord.com
> <javascript:>> wrote:
> > On Wed, Jul 26, 2017 at 4:19 PM, Dan Raviv <dan....@gmail.com
> <javascript:>> wrote:
> >>
> >> So it's unclear whether reserve() is allowed to postpone the actual
> >> allocation?
> >
> >
> > I don't think it is unclear. If you think it is, file a defect report,
> > because AFAIK that isn't intentional.
>
>
> Don't waste our time with a nonsense "defect" report.
> [vector.capacity]/6:
> No reallocation shall take place during insertions that happen after a
> call to reserve()
> until the time when an insertion would make the size of the vector
> greater than the value of capacity().
>
The point that's unclear is (oddly enough) whether "reallocation" is *just*
about the behavior of iterators/references/pointers, or if it is also about
actually allocating memory and all of the side-effects thereof which are
not just iterators/references/pointers. The point is that the standard
doesn't *explicitly* state that "no reallocation" means no allocating
memory.
That's clearly the intent, but I'm not sure if it's well-specified.
But the thing I pointed out, with two sections defining "reallocation"
differently, that's either a defect or an editorial issue.
--
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/03ea2b86-d8a8-461a-961b-ca224be532f3%40isocpp.org.
------=_Part_362_42177511.1501109421960
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, July 26, 2017 at 6:02:34 PM UTC-4, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 27 July 2017=
at 00:49, Nevin Liber <<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"bK6uk_2CAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">ne...@eviloverlord.com</a>> wrote:
<br>> On Wed, Jul 26, 2017 at 4:19 PM, Dan Raviv <<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"bK6uk_2CAAAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">dan....@gmail.com</a>&g=
t; wrote:
<br>>>
<br>>> So it's unclear whether reserve() is allowed to postpone t=
he actual
<br>>> allocation?
<br>>
<br>>
<br>> I don't think it is unclear. =C2=A0If you think it is, file a =
defect report,
<br>> because AFAIK that isn't intentional.
<br>
<br>
<br>Don't waste our time with a nonsense "defect" report.
<br>[vector.capacity]/6:
<br>No reallocation shall take place during insertions that happen after a
<br>call to reserve()
<br>until the time when an insertion would make the size of the vector
<br>greater than the value of capacity().
<br></blockquote><div><br>The point that's unclear is (oddly enough) wh=
ether "reallocation" is <i>just</i> about the behavior of iterato=
rs/references/pointers, or if it is also about actually allocating memory a=
nd all of the side-effects thereof which are not just iterators/references/=
pointers. The point is that the standard doesn't <i>explicitly</i> stat=
e that "no reallocation" means no allocating memory.<br><br>That&=
#39;s clearly the intent, but I'm not sure if it's well-specified.<=
br><br>But the thing I pointed out, with two sections defining "reallo=
cation" differently, that's either a defect or an editorial issue.=
<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/03ea2b86-d8a8-461a-961b-ca224be532f3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/03ea2b86-d8a8-461a-961b-ca224be532f3=
%40isocpp.org</a>.<br />
------=_Part_362_42177511.1501109421960--
------=_Part_361_2007291235.1501109421959--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 26 Jul 2017 18:50:05 -0700
Raw View
On quarta-feira, 26 de julho de 2017 15:50:21 PDT Nicol Bolas wrote:
> The point that's unclear is (oddly enough) whether "reallocation" is *just*
> about the behavior of iterators/references/pointers, or if it is also about
> actually allocating memory and all of the side-effects thereof which are
> not just iterators/references/pointers. The point is that the standard
> doesn't *explicitly* state that "no reallocation" means no allocating
> memory.
I don't think the allocation is the issue. The issue is the lifetime begin of
the objects in the vector, even if trivial.
Suppose this was allowed:
std::vector<char> v;
v.reserve(1);
v.data()[0] = 'a';
v.resize(1);
return v[0];
What does this return?
Note that resize() will do
new (array[i]) T{};
Which will value-initialise (zero-initialise) the array, which means this
function returns 0.
Even if we had a resize() that did default intialisation, the compiler sees
this as the beginning of the lifetime of the char, which means the value that
was there can be discarded as a dead store. In this case, this function would
return an unspecified value and depending on it is UB.
So, tell me again: why does anyone want to access the vector's storage past
the end of the vector?
--
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/1589756.vaCZcMDWZv%40tjmaciei-mobl1.
.
Author: stevemk14ebr@gmail.com
Date: Wed, 26 Jul 2017 19:10:25 -0700 (PDT)
Raw View
------=_Part_422_171434821.1501121426028
Content-Type: multipart/alternative;
boundary="----=_Part_423_1771472008.1501121426029"
------=_Part_423_1771472008.1501121426029
Content-Type: text/plain; charset="UTF-8"
On Wednesday, July 26, 2017 at 9:50:20 PM UTC-4, Thiago Macieira wrote:
>
> On quarta-feira, 26 de julho de 2017 15:50:21 PDT Nicol Bolas wrote:
> > The point that's unclear is (oddly enough) whether "reallocation" is
> *just*
> > about the behavior of iterators/references/pointers, or if it is also
> about
> > actually allocating memory and all of the side-effects thereof which are
> > not just iterators/references/pointers. The point is that the standard
> > doesn't *explicitly* state that "no reallocation" means no allocating
> > memory.
>
> I don't think the allocation is the issue. The issue is the lifetime begin
> of
> the objects in the vector, even if trivial.
>
> Suppose this was allowed:
>
> std::vector<char> v;
> v.reserve(1);
> v.data()[0] = 'a';
> v.resize(1);
> return v[0];
>
> What does this return?
>
> Note that resize() will do
> new (array[i]) T{};
>
> Which will value-initialise (zero-initialise) the array, which means this
> function returns 0.
>
> Even if we had a resize() that did default intialisation, the compiler
> sees
> this as the beginning of the lifetime of the char, which means the value
> that
> was there can be discarded as a dead store. In this case, this function
> would
> return an unspecified value and depending on it is UB.
>
> So, tell me again: why does anyone want to access the vector's storage
> past
> the end of the vector?
>
>
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> There are exactly 3 different things being discussed in this thread
1) Allowing .data() to return a pointer that can be used properly for
pointer arithmatic, but have any dereference of it be undefined. I.E it
points to the buffer, but that's it, if you use it U.B
2) Default init the vector instead of value init. This could be a 'real'
solution to the next case (#3)
3) Using the .data() pointer to allow direct filling of the buffer, useful
in cases where a C api is exposed. But this has been mentioned that the
vector can't know of someone modifying it externally, so resize and things
will overwrite changes you make and letting people do this is probably bad.
(the solution was therefore to make dereferencing .data()'s pointer past
..size() be U.B)
I initially proposed #1, after further discussion, i suggested we add #3
for performance reasons for C apis. There should be two seperate solutions
in my mind for these. This thread is getting horribly off topic by bouncing
between all three of these. Does anyone at least disagree with chaning the
wording of .data() to allow it to be valid for pointer arithmatic, as long
as the vector has a capacity > 0?
--
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/16e6b5da-5165-4bc0-946a-9ea2d849475e%40isocpp.org.
------=_Part_423_1771472008.1501121426029
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, July 26, 2017 at 9:50:20 PM UTC-4, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quarta=
-feira, 26 de julho de 2017 15:50:21 PDT Nicol Bolas wrote:
<br>> The point that's unclear is (oddly enough) whether "reall=
ocation" is *just*
<br>> about the behavior of iterators/references/pointers, or if it is a=
lso about
<br>> actually allocating memory and all of the side-effects thereof whi=
ch are
<br>> not just iterators/references/pointers. The point is that the stan=
dard
<br>> doesn't *explicitly* state that "no reallocation" me=
ans no allocating
<br>> memory.
<br>
<br>I don't think the allocation is the issue. The issue is the lifetim=
e begin of=20
<br>the objects in the vector, even if trivial.
<br>
<br>Suppose this was allowed:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::vector<char>=
v;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0v.reserve(1);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0v.data()[0] =3D 'a&=
#39;;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0v.resize(1);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return v[0];
<br>
<br>What does this return?
<br>
<br>Note that resize() will do
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0new (array[i]) T{};
<br>
<br>Which will value-initialise (zero-initialise) the array, which means th=
is=20
<br>function returns 0.
<br>
<br>Even if we had a resize() that did default intialisation, the compiler =
sees=20
<br>this as the beginning of the lifetime of the char, which means the valu=
e that=20
<br>was there can be discarded as a dead store. In this case, this function=
would=20
<br>return an unspecified value and depending on it is UB.
<br>
<br>So, tell me again: why does anyone want to access the vector's stor=
age past=20
<br>the end of the vector?
<br>
<br>
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
There are exactly 3 different things being discussed in this thread</blockq=
uote><div><br></div><div>1) Allowing .data() to return a pointer that can b=
e used properly for pointer arithmatic, but have any dereference of it be u=
ndefined. I.E it points to the buffer, but that's it, if you use it U.B=
</div><div>2) Default init the vector instead of value init. This could be =
a 'real' solution to the next case (#3)</div><div>3) Using the .dat=
a() pointer to allow direct filling of the buffer, useful in cases where a =
C api is exposed. But this has been mentioned that the vector can't kno=
w of someone modifying it externally, so resize and things will overwrite c=
hanges you make and letting people do this is probably bad. (the solution w=
as therefore to make dereferencing .data()'s pointer past .size() be U.=
B)=C2=A0</div><div><br></div><div>I initially proposed #1, after further di=
scussion, i suggested we=C2=A0add #3 for performance reasons for C apis. Th=
ere should be two seperate solutions in my mind for these. This thread is g=
etting horribly off topic by bouncing between all three of these. Does anyo=
ne at least disagree with chaning the wording of .data() to allow it to be =
valid for pointer arithmatic, as long as the vector has a capacity > 0?=
=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/16e6b5da-5165-4bc0-946a-9ea2d849475e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/16e6b5da-5165-4bc0-946a-9ea2d849475e=
%40isocpp.org</a>.<br />
------=_Part_423_1771472008.1501121426029--
------=_Part_422_171434821.1501121426028--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 26 Jul 2017 19:31:30 -0700 (PDT)
Raw View
------=_Part_427_1399672327.1501122690990
Content-Type: multipart/alternative;
boundary="----=_Part_428_1321954924.1501122690990"
------=_Part_428_1321954924.1501122690990
Content-Type: text/plain; charset="UTF-8"
On Wednesday, July 26, 2017 at 10:10:26 PM UTC-4, stevem...@gmail.com wrote:
>
> There are exactly 3 different things being discussed in this thread
> 1) Allowing .data() to return a pointer that can be used properly for
> pointer arithmatic, but have any dereference of it be undefined. I.E it
> points to the buffer, but that's it, if you use it U.B
> 2) Default init the vector instead of value init. This could be a 'real'
> solution to the next case (#3)
> 3) Using the .data() pointer to allow direct filling of the buffer, useful
> in cases where a C api is exposed. But this has been mentioned that the
> vector can't know of someone modifying it externally, so resize and things
> will overwrite changes you make and letting people do this is probably bad.
> (the solution was therefore to make dereferencing .data()'s pointer past
> .size() be U.B)
>
> I initially proposed #1, after further discussion, i suggested we add #3
> for performance reasons for C apis. There should be two seperate solutions
> in my mind for these.
>
There have been only two problems presented here:
1: Using the value of an empty `vector`'s pointer as some kind of marker, a
pointer to hold until its filled in later.
2: Filling in the contents of a `vector` without having to initialize those
contents twice.
These two problems have absolutely nothing to do with one another. As such,
they require separate solutions.
Also, I have no idea how "make dereferencing .data()'s pointer past .size()
be U.B" is a solution to anything. The whole point of this thread is to
define behavior, not to make new undefined behavior.
This thread is getting horribly off topic by bouncing between all three of
> these. Does anyone at least disagree with chaning the wording of .data() to
> allow it to be valid for pointer arithmatic, as long as the vector has a
> capacity > 0?
>
What do you mean by "valid for pointer arithmatic[sic]"? Pointer arithmetic
in C++ is (at present) only defined for arrays of actual live objects,
which `vector` creates when you insert elements. Well, the return value of
`data()` for an empty `vector` would (at best) be just a memory allocation;
it's not an array of live objects. So you can't do pointer arithmetic on it.
To change that would require changing the meaning of pointer arithmetic,
which is a highly complex change. And while I would like to see those rules
loosened up, even I don't want to allow you to just arbitrarily perform
pointer arithmetic through random memory.
--
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/4ad3287b-c69b-419c-81bf-a7aae9006313%40isocpp.org.
------=_Part_428_1321954924.1501122690990
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, July 26, 2017 at 10:10:26 PM UTC-4, stevem..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>
There are exactly 3 different things being discussed in this thread</div><d=
iv>1) Allowing .data() to return a pointer that can be used properly for po=
inter arithmatic, but have any dereference of it be undefined. I.E it point=
s to the buffer, but that's it, if you use it U.B</div><div>2) Default =
init the vector instead of value init. This could be a 'real' solut=
ion to the next case (#3)</div><div>3) Using the .data() pointer to allow d=
irect filling of the buffer, useful in cases where a C api is exposed. But =
this has been mentioned that the vector can't know of someone modifying=
it externally, so resize and things will overwrite changes you make and le=
tting people do this is probably bad. (the solution was therefore to make d=
ereferencing .data()'s pointer past .size() be U.B)=C2=A0</div><div><br=
></div><div>I initially proposed #1, after further discussion, i suggested =
we=C2=A0add #3 for performance reasons for C apis. There should be two sepe=
rate solutions in my mind for these.</div></div></blockquote><div><br>There=
have been only two problems presented here:<br><br>1: Using the value of a=
n empty `vector`'s pointer as some kind of marker, a pointer to hold un=
til its filled in later.<br>2: Filling in the contents of a `vector` withou=
t having to initialize those contents twice.<br><br>These two problems have=
absolutely nothing to do with one another. As such, they require separate =
solutions.<br><br>Also, I have no idea how "make dereferencing .data()=
's pointer past=20
..size() be U.B" is a solution to anything. The whole point of this=20
thread is to define behavior, not to make new undefined behavior.<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>This=
thread is getting horribly off topic by bouncing between all three of thes=
e. Does anyone at least disagree with chaning the wording of .data() to all=
ow it to be valid for pointer arithmatic, as long as the vector has a capac=
ity > 0?=C2=A0</div></div></blockquote><div><br>What do you mean by &quo=
t;valid for pointer arithmatic[sic]"? Pointer arithmetic in C++ is (at=
present) only defined for arrays of actual live objects, which `vector` cr=
eates when you insert elements. Well, the return value of `data()` for an e=
mpty `vector` would (at best) be just a memory allocation; it's not an =
array of live objects. So you can't do pointer arithmetic on it.<br><br=
>To change that would require changing the meaning of pointer arithmetic, w=
hich is a highly complex change. And while I would like to see those rules =
loosened up, even I don't want to allow you to just arbitrarily perform=
pointer arithmetic through random memory.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4ad3287b-c69b-419c-81bf-a7aae9006313%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4ad3287b-c69b-419c-81bf-a7aae9006313=
%40isocpp.org</a>.<br />
------=_Part_428_1321954924.1501122690990--
------=_Part_427_1399672327.1501122690990--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 26 Jul 2017 19:34:27 -0700 (PDT)
Raw View
------=_Part_445_1002063726.1501122868035
Content-Type: multipart/alternative;
boundary="----=_Part_446_478884768.1501122868035"
------=_Part_446_478884768.1501122868035
Content-Type: text/plain; charset="UTF-8"
On Wednesday, July 26, 2017 at 9:50:20 PM UTC-4, Thiago Macieira wrote:
>
> On quarta-feira, 26 de julho de 2017 15:50:21 PDT Nicol Bolas wrote:
> > The point that's unclear is (oddly enough) whether "reallocation" is
> *just*
> > about the behavior of iterators/references/pointers, or if it is also
> about
> > actually allocating memory and all of the side-effects thereof which are
> > not just iterators/references/pointers. The point is that the standard
> > doesn't *explicitly* state that "no reallocation" means no allocating
> > memory.
>
> I don't think the allocation is the issue. The issue is the lifetime begin
> of
> the objects in the vector, even if trivial.
>
I think you've kind of gotten off the off-topic discussion. "The issue" I
was discussion was in response to a post about a possible standard defect
in how "reallocation" is defined.
We're pretty much all in agreement that there is no functional way to allow
you to just pretend that elements of a `vector` exist through `reserve`
without making them actually exist through `insertion`/`resize`/etc.
--
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/68088402-2eca-40e5-a993-2858b34032c9%40isocpp.org.
------=_Part_446_478884768.1501122868035
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, July 26, 2017 at 9:50: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 quarta-feira, =
26 de julho de 2017 15:50:21 PDT Nicol Bolas wrote:
<br>> The point that's unclear is (oddly enough) whether "reall=
ocation" is *just*
<br>> about the behavior of iterators/references/pointers, or if it is a=
lso about
<br>> actually allocating memory and all of the side-effects thereof whi=
ch are
<br>> not just iterators/references/pointers. The point is that the stan=
dard
<br>> doesn't *explicitly* state that "no reallocation" me=
ans no allocating
<br>> memory.
<br>
<br>I don't think the allocation is the issue. The issue is the lifetim=
e begin of=20
<br>the objects in the vector, even if trivial.<br></blockquote><div><br>I =
think you've kind of gotten off the off-topic discussion. "The iss=
ue" I was discussion was in response to a post about a possible standa=
rd defect in how "reallocation" is defined.<br><br>We're pret=
ty much all in agreement that there is no functional way to allow you to ju=
st pretend that elements of a `vector` exist through `reserve` without maki=
ng them actually exist through `insertion`/`resize`/etc.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/68088402-2eca-40e5-a993-2858b34032c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/68088402-2eca-40e5-a993-2858b34032c9=
%40isocpp.org</a>.<br />
------=_Part_446_478884768.1501122868035--
------=_Part_445_1002063726.1501122868035--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 26 Jul 2017 19:46:43 -0700
Raw View
On quarta-feira, 26 de julho de 2017 19:10:25 PDT stevemk14ebr@gmail.com
> 1) Allowing .data() to return a pointer that can be used properly for
> pointer arithmatic, but have any dereference of it be undefined. I.E it
> points to the buffer, but that's it, if you use it U.B
Fair enough, you can do pointer arithmetic on it up to capacity().
What's the use-case? What are you going to do with those different pointers
that you can't dereference?
> 2) Default init the vector instead of value init. This could be a 'real'
> solution to the next case (#3)
> 3) Using the .data() pointer to allow direct filling of the buffer, useful
> in cases where a C api is exposed. But this has been mentioned that the
> vector can't know of someone modifying it externally, so resize and things
> will overwrite changes you make and letting people do this is probably bad.
> (the solution was therefore to make dereferencing .data()'s pointer past
> .size() be U.B)
Agreed. So what you want is to resize() it with default initialisation (don't
memset), then pass it to the C library function.
I wrote this for QVector (resizeUninitialized), but had to remove it because
the enable_if I had broke for forward-declared element types.
> I initially proposed #1, after further discussion, i suggested we add #3
> for performance reasons for C apis. There should be two seperate solutions
> in my mind for these. This thread is getting horribly off topic by bouncing
> between all three of these. Does anyone at least disagree with chaning the
> wording of .data() to allow it to be valid for pointer arithmatic, as long
> as the vector has a capacity > 0?
Sure, I just don't see why you'd want to.
--
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/5179237.rDcqN5y67T%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 26 Jul 2017 19:48:58 -0700
Raw View
On quarta-feira, 26 de julho de 2017 19:31:30 PDT Nicol Bolas wrote:
> What do you mean by "valid for pointer arithmatic[sic]"? Pointer arithmetic
> in C++ is (at present) only defined for arrays of actual live objects,
> which `vector` creates when you insert elements.
You can do pointer arithmetic on the pointer returned by malloc(), operator
new() and the allocators up to the size you allocated (plus one). Initialising
the objects in that storage is not required.
In fact, arithmetic on those pointers is a requirement to start the lifetime
of the objects in the first place.
--
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/1514654.0ODxEMff4I%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 26 Jul 2017 19:49:58 -0700
Raw View
On quarta-feira, 26 de julho de 2017 19:34:27 PDT Nicol Bolas wrote:
> I think you've kind of gotten off the off-topic discussion. "The issue" I
> was discussion was in response to a post about a possible standard defect
> in how "reallocation" is defined.
>
> We're pretty much all in agreement that there is no functional way to allow
> you to just pretend that elements of a `vector` exist through `reserve`
> without making them actually exist through `insertion`/`resize`/etc.
Yeah, I kind of got in the middle. I saw the discussion going off-topic to the
original problem and replied to the latest email trying to bring it back.
--
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/19248125.fU3gO2GN2G%40tjmaciei-mobl1.
.
Author: stevemk14ebr@gmail.com
Date: Wed, 26 Jul 2017 20:05:06 -0700 (PDT)
Raw View
------=_Part_497_1719475426.1501124706199
Content-Type: multipart/alternative;
boundary="----=_Part_498_924697135.1501124706200"
------=_Part_498_924697135.1501124706200
Content-Type: text/plain; charset="UTF-8"
On Wednesday, July 26, 2017 at 10:49:08 PM UTC-4, Thiago Macieira wrote:
>
> On quarta-feira, 26 de julho de 2017 19:31:30 PDT Nicol Bolas wrote:
> > What do you mean by "valid for pointer arithmatic[sic]"? Pointer
> arithmetic
> > in C++ is (at present) only defined for arrays of actual live objects,
> > which `vector` creates when you insert elements.
>
> You can do pointer arithmetic on the pointer returned by malloc(),
> operator
> new() and the allocators up to the size you allocated (plus one).
> Initialising
> the objects in that storage is not required.
>
> In fact, arithmetic on those pointers is a requirement to start the
> lifetime
> of the objects in the first place.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> As nicol states problem 1) Using the value of an empty `vector`'s pointer
as some kind of marker, a pointer to hold until its filled in later.
There's two immediate cases i can think of
1) the functions makeJmpInst and makeCallInst need to be given a pointer to
where the instruction will be in memory. Their encoding depends upon their
memory location. I.E you cannot put them into the vector, without first
knowing where they will be put at.
std::vector<uint8_t> buf;
buf.reserve(32);
uint8_t* raw_buf = buf.data();
buf.push_back(makeJmpInst(raw_buf).bytes());
buf.push_back(makeCallInst(raw_buf).bytes());
2) gives you a way to check if the buffer was re-allocated
std::vector<uint8_t> buf;
buf.reserve(32);
uint8_t* raw_buf = buf.data();
buf.push_back({1,2,3});
if(buf.data() !=raw_buf)
error("oh no we got moved on push_back");
Where is it stated that a pointer has to point to a valid object, can it
not just point to memory. A call to reserve is absolutely going to put an
array of bytes into the underlying vector. What am i misunderstanding that
dis-allows you to cast this to a T* and let me to pointer arithmetic. If
it's an issue with T*, just give me a char*.
As Nicol states problem 2) Filling in the contents of a `vector` without
having to initialize those contents twice.
Imagine any C api ever that look like this
int fillSomeBuffer(T* buf); //returns the number of T's actually put into
buf
As it is you have to do this to not invoke U.B or overwrite elements
std::vector<uint8_t> buf;
buf.reserve(32);
uint8_t cBuf[32];
int count = fillSomebuffer(cBuf);
buf.insert(cBuf, cBuf + count);
Ew, look at how horrible that is. Surely we can do better.
That's two real-world cases why something needs to change. I'm not a
standardese guy i don't know all the necessary nuances to get this done
properly. I simply ask that others help guide me to get a solution to these.
--
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/be37032b-85a9-4b25-957f-6d3324760d5f%40isocpp.org.
------=_Part_498_924697135.1501124706200
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, July 26, 2017 at 10:49:08 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 quart=
a-feira, 26 de julho de 2017 19:31:30 PDT Nicol Bolas wrote:
<br>> What do you mean by "valid for pointer arithmatic[sic]"?=
Pointer arithmetic
<br>> in C++ is (at present) only defined for arrays of actual live obje=
cts,
<br>> which `vector` creates when you insert elements.
<br>
<br>You can do pointer arithmetic on the pointer returned by malloc(), oper=
ator=20
<br>new() and the allocators up to the size you allocated (plus one). Initi=
alising=20
<br>the objects in that storage is not required.
<br>
<br>In fact, arithmetic on those pointers is a requirement to start the lif=
etime=20
<br>of the objects in the first place.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div>As nicol states problem 1) Using the value of an empt=
y `vector`'s pointer as some kind of marker, a pointer to hold until it=
s filled in later.</div><div><br></div><div>There's two immediate cases=
i can think of</div><div><br></div><div>1) the functions makeJmpInst and m=
akeCallInst=C2=A0need to be given a pointer to where the instruction will b=
e in memory. Their encoding depends=C2=A0upon their memory location. I.E yo=
u cannot put them into the vector, without first knowing where they will be=
put at.<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span =
style=3D"color: #080;" class=3D"styled-by-prettify"><uint8_t></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> buf</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>buf</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">reserve</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">32</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>uint8_t</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> raw_b=
uf </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> buf</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">data</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>buf</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">push_back</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">makeJmpInst</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><font color=3D"#000000"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">raw_buf</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">).</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">bytes</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">());</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>buf</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">pus=
h_back</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">makeCallInst<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">raw_buf</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">).</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">bytes</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">());</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></font></div></code></div><div>=
<br></div>2) gives you a way to check if the buffer was re-allocated</div><=
div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span styl=
e=3D"color: #080;" class=3D"styled-by-prettify"><uint8_t></span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> buf</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>buf</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">reserve</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">32</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>uint8_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> raw_buf =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> buf</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">data</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>buf</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">.</span><font color=3D"#000000"><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">push_back</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">({</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">});</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">buf</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">data</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">raw_buf</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0error</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">"oh no we got mo=
ved on push_back"</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span></font></div></code></div><div><br></div><div>Where is it st=
ated that a pointer has to point to a valid object, can it not just point t=
o memory. A call to reserve is absolutely going to put an array of bytes in=
to the underlying vector. What am i misunderstanding that dis-allows you to=
cast this to a T* and let me to pointer arithmetic.=C2=A0If it's an is=
sue with T*, just give me a char*.</div><br>As Nicol states problem 2) Fill=
ing in the contents of a `vector` without having to initialize those conten=
ts twice.</div><div>Imagine any C api ever that look like this=C2=A0</div><=
div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"font-family: Arial, Helvetica, sans-serif;"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> fillSomeBuffer</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> buf</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//returns the number of T's actually put into buf </span></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code=
></div><div><br></div>As it is you have to do this to not invoke U.B or ove=
rwrite elements</div><div><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled=
-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v=
ector</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><u=
int8_t></span><font color=3D"#000000"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> buf</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>buf</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">res=
erve</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">32</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>uint8_t cBuf</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">32</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">];</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> count </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> fillSomebuffer</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cB=
uf</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>buf</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">insert</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">cBuf</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> cBuf </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> count</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span></font></div></code></div><div><br></div>Ew, look at how horribl=
e that is. Surely we can do better.=C2=A0</div><div><br></div><div>That'=
;s two real-world cases why something needs to change. I'm not a standa=
rdese=C2=A0guy i don't know all the necessary nuances to get this done =
properly. I simply ask that others help guide me to get a solution to these=
..</div><div><br></div><div><br>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/be37032b-85a9-4b25-957f-6d3324760d5f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/be37032b-85a9-4b25-957f-6d3324760d5f=
%40isocpp.org</a>.<br />
------=_Part_498_924697135.1501124706200--
------=_Part_497_1719475426.1501124706199--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 26 Jul 2017 20:22:55 -0700 (PDT)
Raw View
------=_Part_440_2138308007.1501125776002
Content-Type: multipart/alternative;
boundary="----=_Part_441_1233641467.1501125776003"
------=_Part_441_1233641467.1501125776003
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, July 26, 2017 at 10:49:08 PM UTC-4, Thiago Macieira wrote:
>
> On quarta-feira, 26 de julho de 2017 19:31:30 PDT Nicol Bolas wrote:=20
> > What do you mean by "valid for pointer arithmatic[sic]"? Pointer=20
> arithmetic=20
> > in C++ is (at present) only defined for arrays of actual live objects,=
=20
> > which `vector` creates when you insert elements.=20
>
> You can do pointer arithmetic on the pointer returned by malloc(),=20
> operator=20
> new() and the allocators up to the size you allocated (plus one).=20
> Initialising=20
> the objects in that storage is not required.=20
>
> In fact, arithmetic on those pointers is a requirement to start the=20
> lifetime=20
> of the objects in the first place.
>
[expr.add]/4 states:
> When an expression that has integral type is added to or subtracted from=
=20
a pointer, the result has the type of the pointer operand. If the=20
expression P points to element x[i] of an array object x with n elements,=
=20
86 the expressions P + J and J + P (where J has the value j ) point to the=
=20
(possibly-hypothetical) element x[i + j] if 0 =E2=89=A4 i + j =E2=89=A4 n ;=
otherwise, the=20
behavior is undefined. Likewise, the expression P - J points to the=20
(possibly-hypothetical) element x[i =E2=88=92 j] if 0 =E2=89=A4 i =E2=88=92=
j =E2=89=A4 n; otherwise, the=20
behavior is undefined.=20
If P is a freshly allocated piece of memory, it does not "point to element=
=20
x[i] of an array object x with n elements". Therefore "the behavior is=20
undefined".
Yes, this is powerfully dumb. Yes, this means it is impossible to implement=
=20
`std::vector`. Yes, this is actually how the standard works at present.
--=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/2c0abe57-9434-42dd-9431-acffe355852e%40isocpp.or=
g.
------=_Part_441_1233641467.1501125776003
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, July 26, 2017 at 10:49:08 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 quart=
a-feira, 26 de julho de 2017 19:31:30 PDT Nicol Bolas wrote:
<br>> What do you mean by "valid for pointer arithmatic[sic]"?=
Pointer arithmetic
<br>> in C++ is (at present) only defined for arrays of actual live obje=
cts,
<br>> which `vector` creates when you insert elements.
<br>
<br>You can do pointer arithmetic on the pointer returned by malloc(), oper=
ator=20
<br>new() and the allocators up to the size you allocated (plus one). Initi=
alising=20
<br>the objects in that storage is not required.
<br>
<br>In fact, arithmetic on those pointers is a requirement to start the lif=
etime=20
<br>of the objects in the first place.<br></blockquote><div><br>[expr.add]/=
4 states:<br><br>> When an expression that has integral type is added to=
or subtracted from a pointer, the result has the type of the pointer opera=
nd. If the expression P points to element x[i] of an array object x with n =
elements, 86 the expressions P + J and J + P (where J has the value j ) poi=
nt to the (possibly-hypothetical) element x[i + j] if 0 =E2=89=A4 i + j =E2=
=89=A4 n ; otherwise, the behavior is undefined. Likewise, the expression P=
- J points to the (possibly-hypothetical) element x[i =E2=88=92 j] if 0 =
=E2=89=A4 i =E2=88=92 j =E2=89=A4 n; otherwise, the behavior is undefined. =
<br><br>If P is a freshly allocated piece of memory, it does not "poin=
t to element x[i] of an array object x with n elements". Therefore &qu=
ot;the behavior is undefined".<br><br>Yes, this is powerfully dumb. Ye=
s, this means it is impossible to implement `std::vector`. Yes, this is act=
ually how the standard works at present.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2c0abe57-9434-42dd-9431-acffe355852e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2c0abe57-9434-42dd-9431-acffe355852e=
%40isocpp.org</a>.<br />
------=_Part_441_1233641467.1501125776003--
------=_Part_440_2138308007.1501125776002--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 26 Jul 2017 20:36:33 -0700 (PDT)
Raw View
------=_Part_447_1414806901.1501126593869
Content-Type: multipart/alternative;
boundary="----=_Part_448_80184894.1501126593870"
------=_Part_448_80184894.1501126593870
Content-Type: text/plain; charset="UTF-8"
On Wednesday, July 26, 2017 at 11:05:06 PM UTC-4, stevem...@gmail.com wrote:
>
> On Wednesday, July 26, 2017 at 10:49:08 PM UTC-4, Thiago Macieira wrote:
>>
>> On quarta-feira, 26 de julho de 2017 19:31:30 PDT Nicol Bolas wrote:
>> > What do you mean by "valid for pointer arithmatic[sic]"? Pointer
>> arithmetic
>> > in C++ is (at present) only defined for arrays of actual live objects,
>> > which `vector` creates when you insert elements.
>>
>> You can do pointer arithmetic on the pointer returned by malloc(),
>> operator
>> new() and the allocators up to the size you allocated (plus one).
>> Initialising
>> the objects in that storage is not required.
>>
>> In fact, arithmetic on those pointers is a requirement to start the
>> lifetime
>> of the objects in the first place.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>>
>> As nicol states problem 1) Using the value of an empty `vector`'s pointer
> as some kind of marker, a pointer to hold until its filled in later.
>
> There's two immediate cases i can think of
>
> 1) the functions makeJmpInst and makeCallInst need to be given a pointer
> to where the instruction will be in memory. Their encoding depends upon
> their memory location. I.E you cannot put them into the vector, without
> first knowing where they will be put at.
> std::vector<uint8_t> buf;
> buf.reserve(32);
> uint8_t* raw_buf = buf.data();
> buf.push_back(makeJmpInst(raw_buf).bytes());
> buf.push_back(makeCallInst(raw_buf).bytes());
>
>
So, it would be impossible to patch up the data with its actual memory
address after inserting it?
> 2) gives you a way to check if the buffer was re-allocated
>
No, it does not. Because if two reallocations happened, it is entirely
possible that `vector.data()` has the same value it used to have. Or
something as simple as this:
vector<int> vec1 = ...
auto ptr = vec1.data();
vec1.push_back(); //Cause reallocation. `ptr` is invallid.
vector<int> vec2 = ... //Just so happens to have the `ptr` value.
vec1 = std::move(vec2);
ptr == vec1.data(); //Reallocation happened, but we can't tell.
Where is it stated that a pointer has to point to a valid object, can it
> not just point to memory.
>
That isn't stated anywhere. But, nobody has suggested that this is a
problem. You can have pointers to random memory. But you can't do pointer
arithmetic on it.
> A call to reserve is absolutely going to put an array of bytes into the
> underlying vector. What am i misunderstanding that dis-allows you to cast
> this to a T* and let me to pointer arithmetic.
>
See [expr.add]/4. Pointer arithmetic does not work unless it's actually a
pointer into an array of `T`s.
> If it's an issue with T*, just give me a char*.
>
That doesn't work either, since it's not a pointer into an array of `char`.
As Nicol states problem 2) Filling in the contents of a `vector` without
> having to initialize those contents twice.
> ...
> That's two real-world cases why something needs to change. I'm not a
> standardese guy i don't know all the necessary nuances to get this done
> properly. I simply ask that others help guide me to get a solution to these.
>
And we already have: permit default initialization of objects. But you
rejected it with the reasoning "I'm weighing the probability of this
actually happening. It seems like doing something like that would come
around in C++ 30, while this could be done tomorrow."
If you reject the solution that can actually work in favor of one that
*can't* work, there's not much we can really do.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eeb461ae-d097-40af-836b-87b080389f5f%40isocpp.org.
------=_Part_448_80184894.1501126593870
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, July 26, 2017 at 11:05:06 PM UTC-4, stevem..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Wednesday, July 26, 2017 at 10:49:08 PM UTC-4, Thiago Macieira wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">On quarta-feira, 26 de julho de 2=
017 19:31:30 PDT Nicol Bolas wrote:
<br>> What do you mean by "valid for pointer arithmatic[sic]"?=
Pointer arithmetic
<br>> in C++ is (at present) only defined for arrays of actual live obje=
cts,
<br>> which `vector` creates when you insert elements.
<br>
<br>You can do pointer arithmetic on the pointer returned by malloc(), oper=
ator=20
<br>new() and the allocators up to the size you allocated (plus one). Initi=
alising=20
<br>the objects in that storage is not required.
<br>
<br>In fact, arithmetic on those pointers is a requirement to start the lif=
etime=20
<br>of the objects in the first place.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div>As nicol states problem 1) Using the value of an empt=
y `vector`'s pointer as some kind of marker, a pointer to hold until it=
s filled in later.</div><div><br></div><div>There's two immediate cases=
i can think of</div><div><br></div><div>1) the functions makeJmpInst and m=
akeCallInst=C2=A0need to be given a pointer to where the instruction will b=
e in memory. Their encoding depends=C2=A0upon their memory location. I.E yo=
u cannot put them into the vector, without first knowing where they will be=
put at.<div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>=
<div><span style=3D"color:#000">std</span><span style=3D"color:#660">::</sp=
an><span style=3D"color:#000">vector</span><span style=3D"color:#080"><u=
int8_t></span><span style=3D"color:#000"> buf</span><span style=3D"color=
:#660">;</span><span style=3D"color:#000"><br>buf</span><span style=3D"colo=
r:#660">.</span><span style=3D"color:#000">reserve</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#066">32</span><span style=3D"color:#=
660">);</span><span style=3D"color:#000"><br>uint8_t</span><span style=3D"c=
olor:#660">*</span><span style=3D"color:#000"> raw_buf </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> buf</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">data</span><span style=
=3D"color:#660">();</span><span style=3D"color:#000"><br>buf</span><span st=
yle=3D"color:#660">.</span><span style=3D"color:#000">push_back</span><span=
style=3D"color:#660">(</span><span style=3D"color:#000">makeJmpInst</span>=
<span style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"c=
olor:#000">raw_<wbr>buf</span><span style=3D"color:#660">).</span><span sty=
le=3D"color:#000">bytes</span><span style=3D"color:#660">());</span><span s=
tyle=3D"color:#000"><br>buf</span><span style=3D"color:#660">.</span><span =
style=3D"color:#000">push_back</span><span style=3D"color:#660">(</span><sp=
an style=3D"color:#000">makeCallInst</span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#000">raw<wbr>_buf</span><span style=3D"color:#660"=
>).</span><span style=3D"color:#000">bytes</span><span style=3D"color:#660"=
>());</span><span style=3D"color:#000"><br></span></font></div></code></div=
><div><br></div></div></div></blockquote><div><br>So, it would be impossibl=
e to patch up the data with its actual memory address after inserting it?<b=
r>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div></div>2) gives you a way to check if the buffer was re-allocated=
</div></div></blockquote><div><br>No, it does not. Because if two reallocat=
ions happened, it is entirely possible that `vector.data()` has the same va=
lue it used to have. Or something as simple as this:<br><br><div style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pr=
ettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span styl=
e=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> vec1 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> ptr </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
vec1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">data</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>vec1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">push_back</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">//Cause reallocation. `ptr` is invallid.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>vector</span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> vec2 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">//Just so happens to have the `ptr` value.</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>vec1 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">move</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">vec2</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>ptr </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> vec1</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">data</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">//Reallocation happened, but we can't t=
ell.</span></div></code></div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div><div>Where is it stated that a pointer has =
to point to a valid object, can it not just point to memory.</div></div></d=
iv></blockquote><div><br>That isn't stated anywhere. But, nobody has su=
ggested that this is a problem. You can have pointers to random memory. But=
you can't do pointer arithmetic on it.<br>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div>A call to reserve i=
s absolutely going to put an array of bytes into the underlying vector. Wha=
t am i misunderstanding that dis-allows you to cast this to a T* and let me=
to pointer arithmetic.</div></div></div></blockquote><div><br>See [expr.ad=
d]/4. Pointer arithmetic does not work unless it's actually a pointer i=
nto an array of `T`s.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div><div>If it's an issue with T*, just give m=
e a char*.</div></div></div></blockquote><div><br>That doesn't work eit=
her, since it's not a pointer into an array of `char`.<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>As Nicol st=
ates problem 2) Filling in the contents of a `vector` without having to ini=
tialize those contents twice.</div><div>...<br></div><div>That's two re=
al-world cases why something needs to change. I'm not a standardese=C2=
=A0guy i don't know all the necessary nuances to get this done properly=
.. I simply ask that others help guide me to get a solution to these.</div><=
/div></blockquote><div><br>And we already have: permit default initializati=
on of objects. But you rejected it with the reasoning "I'm weighin=
g the probability of this actually happening. It seems like=20
doing something like that would come around in C++ 30, while this could=20
be done tomorrow."<br><br>If you reject the solution that can actually=
work in favor of one that <i>can't</i> work, there's not much we c=
an really do.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eeb461ae-d097-40af-836b-87b080389f5f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eeb461ae-d097-40af-836b-87b080389f5f=
%40isocpp.org</a>.<br />
------=_Part_448_80184894.1501126593870--
------=_Part_447_1414806901.1501126593869--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 26 Jul 2017 21:05:46 -0700
Raw View
On quarta-feira, 26 de julho de 2017 20:36:33 PDT Nicol Bolas wrote:
> > 1) the functions makeJmpInst and makeCallInst need to be given a pointer
> > to where the instruction will be in memory. Their encoding depends upon
> > their memory location. I.E you cannot put them into the vector, without
> > first knowing where they will be put at.
> > std::vector<uint8_t> buf;
> > buf.reserve(32);
> > uint8_t* raw_buf = buf.data();
> > buf.push_back(makeJmpInst(raw_buf).bytes());
> > buf.push_back(makeCallInst(raw_buf).bytes());
>
> So, it would be impossible to patch up the data with its actual memory
> address after inserting it?
I might point out hat "patch up the data" is the state of the art in this
technology known as "linking"...
--
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/4510841.491RECi6Hy%40tjmaciei-mobl1.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 27 Jul 2017 15:47:55 +0100
Raw View
--001a11372cb46d0d5e05554da677
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 11:50 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, July 26, 2017 at 6:02:34 PM UTC-4, Ville Voutilainen wrote:
>>
>> On 27 July 2017 at 00:49, Nevin Liber <ne...@eviloverlord.com> wrote:
>> > On Wed, Jul 26, 2017 at 4:19 PM, Dan Raviv <dan....@gmail.com> wrote:
>> >>
>> >> So it's unclear whether reserve() is allowed to postpone the actual
>> >> allocation?
>> >
>> >
>> > I don't think it is unclear. If you think it is, file a defect report,
>> > because AFAIK that isn't intentional.
>>
>>
>> Don't waste our time with a nonsense "defect" report.
>> [vector.capacity]/6:
>> No reallocation shall take place during insertions that happen after a
>> call to reserve()
>> until the time when an insertion would make the size of the vector
>> greater than the value of capacity().
>>
>
> The point that's unclear is (oddly enough) whether "reallocation" is
> *just* about the behavior of iterators/references/pointers, or if it is
> also about actually allocating memory and all of the side-effects thereof
> which are not just iterators/references/pointers. The point is that the
> standard doesn't *explicitly* state that "no reallocation" means no
> allocating memory.
>
> That's clearly the intent, but I'm not sure if it's well-specified.
>
It's not that clear to me (and I don't think I'm being intentionally
obtuse). I'd hope implementations have considerable latitude over when they
call into the supplied allocator, allowing them to e.g. pool nodes or node
allocations if they so wish. Some operations are noexcept, meaning that
they can't allocate or deallocate, but otherwise I think it should be the
implementor's choice.
There are some sections (e.g. [stringbuf.virtuals]/8) where "reallocate" is
clearly referring to calls to an allocator, but in the case of vector (and
string) it could be read as a shorthand term for iterator/reference/pointer
invalidation.
But the thing I pointed out, with two sections defining "reallocation"
> differently, that's either a defect or an editorial issue.
>
--
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/CAJnLdOZUee-fz4m_MXhcgHPnHdvL9ct04TBEyeKKMb-a7h2%2B9Q%40mail.gmail.com.
--001a11372cb46d0d5e05554da677
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jul 26, 2017 at 11:50 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesda=
y, July 26, 2017 at 6:02:34 PM UTC-4, Ville Voutilainen wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">On 27 July 2017 at 00:49, Nevin Liber <<a rel=
=3D"nofollow">ne...@eviloverlord.com</a>> wrote:
<br>> On Wed, Jul 26, 2017 at 4:19 PM, Dan Raviv <<a rel=3D"nofollow"=
>dan....@gmail.com</a>> wrote:
<br>>>
<br>>> So it's unclear whether reserve() is allowed to postpone t=
he actual
<br>>> allocation?
<br>>
<br>>
<br>> I don't think it is unclear.=C2=A0 If you think it is, file a =
defect report,
<br>> because AFAIK that isn't intentional.
<br>
<br>
<br>Don't waste our time with a nonsense "defect" report.
<br>[vector.capacity]/6:
<br>No reallocation shall take place during insertions that happen after a
<br>call to reserve()
<br>until the time when an insertion would make the size of the vector
<br>greater than the value of capacity().
<br></blockquote><div><br>The point that's unclear is (oddly enough) wh=
ether "reallocation" is <i>just</i> about the behavior of iterato=
rs/references/pointers, or if it is also about actually allocating memory a=
nd all of the side-effects thereof which are not just iterators/references/=
pointers. The point is that the standard doesn't <i>explicitly</i> stat=
e that "no reallocation" means no allocating memory.<br><br>That&=
#39;s clearly the intent, but I'm not sure if it's well-specified.<=
br></div></div></blockquote><div><br></div><div>It's not that clear to =
me (and I don't think I'm being intentionally obtuse). I'd hope=
implementations have considerable latitude over when they call into the su=
pplied allocator, allowing them to e.g. pool nodes or node allocations if t=
hey so wish. Some operations are noexcept, meaning that they can't allo=
cate or deallocate, but otherwise I think it should be the implementor'=
s choice.</div><div><br></div><div>There are some sections (e.g. [stringbuf=
..virtuals]/8) where "reallocate" is clearly referring to calls to=
an allocator, but in the case of vector (and string) it could be read as a=
shorthand term for iterator/reference/pointer invalidation.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>But the thing I =
pointed out, with two sections defining "reallocation" differentl=
y, that's either a defect or an editorial issue.</div></div></blockquot=
e></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZUee-fz4m_MXhcgHPnHdvL9ct04TBE=
yeKKMb-a7h2%2B9Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZUee-fz4=
m_MXhcgHPnHdvL9ct04TBEyeKKMb-a7h2%2B9Q%40mail.gmail.com</a>.<br />
--001a11372cb46d0d5e05554da677--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 27 Jul 2017 10:51:48 -0400
Raw View
--001a114b00648642a305554db515
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 11:05 PM, <stevemk14ebr@gmail.com> wrote:
>
> 2) gives you a way to check if the buffer was re-allocated
> std::vector<uint8_t> buf;
> buf.reserve(32);
> uint8_t* raw_buf = buf.data();
> buf.push_back({1,2,3});
> if(buf.data() !=raw_buf)
> error("oh no we got moved on push_back");
>
No, this is no good. If the pointer in raw_buf has been deallocated, it is
undefined behavior to read its value.
You could use memcmp rather than !=, though.
--
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/CAHSYqda0%3D_BHgKhabeVwpFVtgipXDDQze6r3PHXj4mmyuiCakw%40mail.gmail.com.
--001a114b00648642a305554db515
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jul 26, 2017 at 11:05 PM, <span dir=3D"ltr"><<a href=3D"mailto:stev=
emk14ebr@gmail.com" target=3D"_blank">stevemk14ebr@gmail.com</a>></span>=
wrote:<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>2) gives you a =
way to check if the buffer was re-allocated</div><div><div class=3D"m_58341=
89501763507703prettyprint" style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code class=3D"m_5834189501763507703prettyprint"><div class=3D"m_58=
34189501763507703subprettyprint"><span style=3D"color:#000" class=3D"m_5834=
189501763507703styled-by-prettify">std</span><span style=3D"color:#660" cla=
ss=3D"m_5834189501763507703styled-by-prettify">::</span><span style=3D"colo=
r:#000" class=3D"m_5834189501763507703styled-by-prettify">vector</span><spa=
n style=3D"color:#080" class=3D"m_5834189501763507703styled-by-prettify">&l=
t;uint8_t></span><span style=3D"color:#000" class=3D"m_58341895017635077=
03styled-by-prettify"> buf</span><span style=3D"color:#660" class=3D"m_5834=
189501763507703styled-by-prettify">;</span><span style=3D"color:#000" class=
=3D"m_5834189501763507703styled-by-prettify"><br>buf</span><span style=3D"c=
olor:#660" class=3D"m_5834189501763507703styled-by-prettify">.</span><span =
style=3D"color:#000" class=3D"m_5834189501763507703styled-by-prettify">rese=
rve</span><span style=3D"color:#660" class=3D"m_5834189501763507703styled-b=
y-prettify">(</span><span style=3D"color:#066" class=3D"m_58341895017635077=
03styled-by-prettify">32</span><span style=3D"color:#660" class=3D"m_583418=
9501763507703styled-by-prettify">);</span><span style=3D"color:#000" class=
=3D"m_5834189501763507703styled-by-prettify"><br>uint8_t</span><span style=
=3D"color:#660" class=3D"m_5834189501763507703styled-by-prettify">*</span><=
span style=3D"color:#000" class=3D"m_5834189501763507703styled-by-prettify"=
> raw_buf </span><span style=3D"color:#660" class=3D"m_5834189501763507703s=
tyled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_58341895=
01763507703styled-by-prettify"> buf</span><span style=3D"color:#660" class=
=3D"m_5834189501763507703styled-by-prettify">.</span><span style=3D"color:#=
000" class=3D"m_5834189501763507703styled-by-prettify">data</span><span sty=
le=3D"color:#660" class=3D"m_5834189501763507703styled-by-prettify">();</sp=
an><span style=3D"color:#000" class=3D"m_5834189501763507703styled-by-prett=
ify"><br>buf</span><span style=3D"color:#660" class=3D"m_583418950176350770=
3styled-by-prettify">.</span><font color=3D"#000000"><span style=3D"color:#=
000" class=3D"m_5834189501763507703styled-by-prettify">push_back</span><spa=
n style=3D"color:#660" class=3D"m_5834189501763507703styled-by-prettify">({=
</span><span style=3D"color:#066" class=3D"m_5834189501763507703styled-by-p=
rettify">1</span><span style=3D"color:#660" class=3D"m_5834189501763507703s=
tyled-by-prettify">,</span><span style=3D"color:#066" class=3D"m_5834189501=
763507703styled-by-prettify">2</span><span style=3D"color:#660" class=3D"m_=
5834189501763507703styled-by-prettify">,</span><span style=3D"color:#066" c=
lass=3D"m_5834189501763507703styled-by-prettify">3</span><span style=3D"col=
or:#660" class=3D"m_5834189501763507703styled-by-prettify">});</span><span =
style=3D"color:#000" class=3D"m_5834189501763507703styled-by-prettify"><br>=
</span><span style=3D"color:#008" class=3D"m_5834189501763507703styled-by-p=
rettify">if</span><span style=3D"color:#660" class=3D"m_5834189501763507703=
styled-by-prettify">(</span><span style=3D"color:#000" class=3D"m_583418950=
1763507703styled-by-prettify">buf</span><span style=3D"color:#660" class=3D=
"m_5834189501763507703styled-by-prettify">.</span><span style=3D"color:#000=
" class=3D"m_5834189501763507703styled-by-prettify">data</span><span style=
=3D"color:#660" class=3D"m_5834189501763507703styled-by-prettify">()</span>=
<span style=3D"color:#000" class=3D"m_5834189501763507703styled-by-prettify=
"> </span><span style=3D"color:#660" class=3D"m_5834189501763507703styled-b=
y-prettify">!=3D</span><span style=3D"color:#000" class=3D"m_58341895017635=
07703styled-by-prettify">raw_buf</span><span style=3D"color:#660" class=3D"=
m_5834189501763507703styled-by-prettify">)</span><span style=3D"color:#000"=
class=3D"m_5834189501763507703styled-by-prettify"><br>=C2=A0 =C2=A0error</=
span><span style=3D"color:#660" class=3D"m_5834189501763507703styled-by-pre=
ttify">(</span><span style=3D"color:#080" class=3D"m_5834189501763507703sty=
led-by-prettify">"oh no we got moved on push_back"</span><span st=
yle=3D"color:#660" class=3D"m_5834189501763507703styled-by-prettify">);</sp=
an></font></div></code></div></div></div></blockquote><div><br></div><div>N=
o, this is no good.=C2=A0 If the pointer in raw_buf has been deallocated, i=
t is undefined behavior to read its value.<br>You could use memcmp rather t=
han !=3D, though.</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" 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/CAHSYqda0%3D_BHgKhabeVwpFVtgipXDDQze6=
r3PHXj4mmyuiCakw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda0%3D_BH=
gKhabeVwpFVtgipXDDQze6r3PHXj4mmyuiCakw%40mail.gmail.com</a>.<br />
--001a114b00648642a305554db515--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 17:53:10 +0300
Raw View
On 27 July 2017 at 17:47, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>> The point that's unclear is (oddly enough) whether "reallocation" is just
>> about the behavior of iterators/references/pointers, or if it is also about
>> actually allocating memory and all of the side-effects thereof which are not
>> just iterators/references/pointers. The point is that the standard doesn't
>> explicitly state that "no reallocation" means no allocating memory.
>>
>> That's clearly the intent, but I'm not sure if it's well-specified.
>
>
> It's not that clear to me (and I don't think I'm being intentionally
> obtuse). I'd hope implementations have considerable latitude over when they
> call into the supplied allocator, allowing them to e.g. pool nodes or node
> allocations if they so wish. Some operations are noexcept, meaning that they
> can't allocate or deallocate, but otherwise I think it should be the
> implementor's choice.
What 'nodes' is a vector supposed to use? If you think an actual
node-based container should have
liberties with when and how many nodes it allocates, that's fine and
certainly worth exploring, but
I don't see what that has to do with vector.
--
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/CAFk2RUZmUotuYxrSctYPjphBRaZy2BPeaXA0wLkGrho7YUHaqg%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 17:54:32 +0300
Raw View
On 27 July 2017 at 17:51, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Wed, Jul 26, 2017 at 11:05 PM, <stevemk14ebr@gmail.com> wrote:
>>
>> 2) gives you a way to check if the buffer was re-allocated
>> std::vector<uint8_t> buf;
>> buf.reserve(32);
>> uint8_t* raw_buf = buf.data();
>> buf.push_back({1,2,3});
>> if(buf.data() !=raw_buf)
>> error("oh no we got moved on push_back");
>
>
> No, this is no good. If the pointer in raw_buf has been deallocated, it is
> undefined behavior to read its value.
> You could use memcmp rather than !=, though.
Incorrect. " Indirection through an invalid pointer value and passing
an invalid pointer value to a deallocation
function have undefined behavior. Any other use of an invalid pointer
value has implementation-defined behavior."
--
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/CAFk2RUaN59%3DHV1WWV-ZgSjet9J0SC8Y6ZV%2BLaGzxw_iFRt5wJw%40mail.gmail.com.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 27 Jul 2017 15:56:07 +0100
Raw View
--94eb2c05e440bee9ca05554dc387
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 3:31 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, July 26, 2017 at 10:10:26 PM UTC-4, stevem...@gmail.com
> wrote:
>>
>> There are exactly 3 different things being discussed in this thread
>> 1) Allowing .data() to return a pointer that can be used properly for
>> pointer arithmatic, but have any dereference of it be undefined. I.E it
>> points to the buffer, but that's it, if you use it U.B
>> 2) Default init the vector instead of value init. This could be a 'real'
>> solution to the next case (#3)
>> 3) Using the .data() pointer to allow direct filling of the buffer,
>> useful in cases where a C api is exposed. But this has been mentioned that
>> the vector can't know of someone modifying it externally, so resize and
>> things will overwrite changes you make and letting people do this is
>> probably bad. (the solution was therefore to make dereferencing .data()'s
>> pointer past .size() be U.B)
>>
>> I initially proposed #1, after further discussion, i suggested we add #3
>> for performance reasons for C apis. There should be two seperate solutions
>> in my mind for these.
>>
>
> There have been only two problems presented here:
>
> 1: Using the value of an empty `vector`'s pointer as some kind of marker,
> a pointer to hold until its filled in later.
> 2: Filling in the contents of a `vector` without having to initialize
> those contents twice.
>
> These two problems have absolutely nothing to do with one another. As
> such, they require separate solutions.
>
Definitely.
> Also, I have no idea how "make dereferencing .data()'s pointer past
> .size() be U.B" is a solution to anything. The whole point of this thread
> is to define behavior, not to make new undefined behavior.
>
That's already UB (by implication, since [data(), data() + size) is a valid
range). I don't think there's any reason to think making data() stable
between reallocations should affect that.
> This thread is getting horribly off topic by bouncing between all three of
>> these. Does anyone at least disagree with chaning the wording of .data() to
>> allow it to be valid for pointer arithmatic, as long as the vector has a
>> capacity > 0?
>>
>
> What do you mean by "valid for pointer arithmatic[sic]"? Pointer
> arithmetic in C++ is (at present) only defined for arrays of actual live
> objects, which `vector` creates when you insert elements. Well, the return
> value of `data()` for an empty `vector` would (at best) be just a memory
> allocation; it's not an array of live objects. So you can't do pointer
> arithmetic on it.
>
At present, you can add 0 to it (and, I think, subtract 0 from it), which
is a degenerate form of arithmetic. You can also subtract it from itself,
giving 0.
It would not be necessary for the limits of pointer arithmetic to change to
give a stability guarantee; you would have a data() pointer that you can
still only use in degenerate pointer arithmetic, but one that is guaranteed
to remain stable across calls to data(). I'm mostly in favor of such a
guarantee, but since it would restrict implementor freedom you should
consider the views of implementors.
After all, there must be *some* reason that implementors do not already
choose to give you data() pointer stability.
> To change that would require changing the meaning of pointer arithmetic,
> which is a highly complex change. And while I would like to see those rules
> loosened up, even I don't want to allow you to just arbitrarily perform
> pointer arithmetic through random memory.
>
>
--
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/CAJnLdObxpQw7sOqh3nYveZ6xYvH8vQaThe4gQ%3DS1kpLqukqOqA%40mail.gmail.com.
--94eb2c05e440bee9ca05554dc387
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 27, 2017 at 3:31 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> 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"><span class=
=3D"">On Wednesday, July 26, 2017 at 10:10:26 PM UTC-4, <a href=3D"mailto:s=
tevem...@gmail.com" target=3D"_blank">stevem...@gmail.com</a> wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>
There are exactly 3 different things being discussed in this thread</div><d=
iv>1) Allowing .data() to return a pointer that can be used properly for po=
inter arithmatic, but have any dereference of it be undefined. I.E it point=
s to the buffer, but that's it, if you use it U.B</div><div>2) Default =
init the vector instead of value init. This could be a 'real' solut=
ion to the next case (#3)</div><div>3) Using the .data() pointer to allow d=
irect filling of the buffer, useful in cases where a C api is exposed. But =
this has been mentioned that the vector can't know of someone modifying=
it externally, so resize and things will overwrite changes you make and le=
tting people do this is probably bad. (the solution was therefore to make d=
ereferencing .data()'s pointer past .size() be U.B)=C2=A0</div><div><br=
></div><div>I initially proposed #1, after further discussion, i suggested =
we=C2=A0add #3 for performance reasons for C apis. There should be two sepe=
rate solutions in my mind for these.</div></div></blockquote></span><div><b=
r>There have been only two problems presented here:<br><br>1: Using the val=
ue of an empty `vector`'s pointer as some kind of marker, a pointer to =
hold until its filled in later.<br>2: Filling in the contents of a `vector`=
without having to initialize those contents twice.<br><br>These two proble=
ms have absolutely nothing to do with one another. As such, they require se=
parate solutions.<br></div></div></blockquote><div><br></div><div>Definitel=
y.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>Also, I have no idea how "make dereferencing .data()'s pointer =
past=20
..size() be U.B" is a solution to anything. The whole point of this=20
thread is to define behavior, not to make new undefined behavior.<br></div>=
</div></blockquote><div><br></div><div>That's already UB (by implicatio=
n, since [data(), data() + size) is a valid range). I don't think there=
's any reason to think making data() stable between reallocations shoul=
d affect that.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div></div><span class=3D""><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>This thread is getting horribly off topic by bounc=
ing between all three of these. Does anyone at least disagree with chaning =
the wording of .data() to allow it to be valid for pointer arithmatic, as l=
ong as the vector has a capacity > 0?=C2=A0</div></div></blockquote></sp=
an><div><br>What do you mean by "valid for pointer arithmatic[sic]&quo=
t;? Pointer arithmetic in C++ is (at present) only defined for arrays of ac=
tual live objects, which `vector` creates when you insert elements. Well, t=
he return value of `data()` for an empty `vector` would (at best) be just a=
memory allocation; it's not an array of live objects. So you can't=
do pointer arithmetic on it.<br></div></div></blockquote><div><br></div><d=
iv>At present, you can add 0 to it (and, I think, subtract 0 from it), whic=
h is a degenerate form of arithmetic. You can also subtract it from itself,=
giving 0.=C2=A0</div><div><br></div><div>It would not be necessary for the=
limits of pointer arithmetic to change to give a stability guarantee; you =
would have a data() pointer that you can still only use in degenerate point=
er arithmetic, but one that is guaranteed to remain stable across calls to =
data(). I'm mostly in favor of such a guarantee, but since it would res=
trict implementor freedom you should consider the views of implementors.</d=
iv><div><br></div><div>After all, there must be *some* reason that implemen=
tors do not already choose to give you data() pointer stability.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>To change =
that would require changing the meaning of pointer arithmetic, which is a h=
ighly complex change. And while I would like to see those rules loosened up=
, even I don't want to allow you to just arbitrarily perform pointer ar=
ithmetic through random memory.<br></div></div><span class=3D"">
<p></p></span></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdObxpQw7sOqh3nYveZ6xYvH8vQaThe4g=
Q%3DS1kpLqukqOqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObxpQw7sO=
qh3nYveZ6xYvH8vQaThe4gQ%3DS1kpLqukqOqA%40mail.gmail.com</a>.<br />
--94eb2c05e440bee9ca05554dc387--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 27 Jul 2017 16:01:22 +0100
Raw View
--001a1141042c80f7b605554dd62c
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 3:53 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 27 July 2017 at 17:47, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
> >> The point that's unclear is (oddly enough) whether "reallocation" is
> just
> >> about the behavior of iterators/references/pointers, or if it is also
> about
> >> actually allocating memory and all of the side-effects thereof which
> are not
> >> just iterators/references/pointers. The point is that the standard
> doesn't
> >> explicitly state that "no reallocation" means no allocating memory.
> >>
> >> That's clearly the intent, but I'm not sure if it's well-specified.
> >
> >
> > It's not that clear to me (and I don't think I'm being intentionally
> > obtuse). I'd hope implementations have considerable latitude over when
> they
> > call into the supplied allocator, allowing them to e.g. pool nodes or
> node
> > allocations if they so wish. Some operations are noexcept, meaning that
> they
> > can't allocate or deallocate, but otherwise I think it should be the
> > implementor's choice.
>
> What 'nodes' is a vector supposed to use? If you think an actual
> node-based container should have
> liberties with when and how many nodes it allocates, that's fine and
> certainly worth exploring, but
> I don't see what that has to do with vector.
>
That was an analogy, I suppose, to argue that taking liberties over when to
call into the allocator can be desirable.
--
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/CAJnLdOZ2xeQ3ewWUr4QcwwkC1o14JmS97i25sj%3DYbC6kHaOpqw%40mail.gmail.com.
--001a1141042c80f7b605554dd62c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 27, 2017 at 3:53 PM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">On 27 July 2017 at 17:47, 'Edward Catmur' via ISO C++ S=
tandard -<br>
<span class=3D"gmail-">Future Proposals <<a href=3D"mailto:std-proposals=
@isocpp.org">std-proposals@isocpp.org</a>> wrote:<br>
>> The point that's unclear is (oddly enough) whether "reall=
ocation" is just<br>
>> about the behavior of iterators/references/pointers, or if it is a=
lso about<br>
>> actually allocating memory and all of the side-effects thereof whi=
ch are not<br>
>> just iterators/references/pointers. The point is that the standard=
doesn't<br>
>> explicitly state that "no reallocation" means no allocat=
ing memory.<br>
>><br>
>> That's clearly the intent, but I'm not sure if it's we=
ll-specified.<br>
><br>
><br>
> It's not that clear to me (and I don't think I'm being int=
entionally<br>
> obtuse). I'd hope implementations have considerable latitude over =
when they<br>
> call into the supplied allocator, allowing them to e.g. pool nodes or =
node<br>
> allocations if they so wish. Some operations are noexcept, meaning tha=
t they<br>
> can't allocate or deallocate, but otherwise I think it should be t=
he<br>
> implementor's choice.<br>
<br>
</span>What 'nodes' is a vector supposed to use? If you think an ac=
tual<br>
node-based container should have<br>
liberties with when and how many nodes it allocates, that's fine and<br=
>
certainly worth exploring, but<br>
I don't see what that has to do with vector.<br></blockquote><div><br><=
/div><div>That was an analogy, I suppose, to argue that taking liberties ov=
er when to call into the allocator can be desirable.</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" 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/CAJnLdOZ2xeQ3ewWUr4QcwwkC1o14JmS97i25=
sj%3DYbC6kHaOpqw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZ2xeQ3ew=
WUr4QcwwkC1o14JmS97i25sj%3DYbC6kHaOpqw%40mail.gmail.com</a>.<br />
--001a1141042c80f7b605554dd62c--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 09:01:01 -0700
Raw View
On quinta-feira, 27 de julho de 2017 07:54:32 PDT Ville Voutilainen wrote:
> On 27 July 2017 at 17:51, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> > No, this is no good. If the pointer in raw_buf has been deallocated, it
> > is
> > undefined behavior to read its value.
> > You could use memcmp rather than !=, though.
>
> Incorrect. " Indirection through an invalid pointer value and passing
> an invalid pointer value to a deallocation
> function have undefined behavior. Any other use of an invalid pointer
> value has implementation-defined behavior."
That was the point of this entire discussion: you can use the .data() pointer
*because* you know it's valid. You can't dereference it yet because the data
there has not begun its lifetime, though.
--
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/2007182.prAO5VDbCx%40tjmaciei-mobl1.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 27 Jul 2017 12:03:59 -0400
Raw View
--001a11435bf8ab5b1d05554eb73d
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 10:54 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> Incorrect. " Indirection through an invalid pointer value and passing
> an invalid pointer value to a deallocation
> function have undefined behavior. Any other use of an invalid pointer
> value has implementation-defined behavior."
"36) Some implementations might define that copying an invalid pointer
value causes a system-generated runtime fault."
The standard doesn't say what a "runtime fault" is - this is the only use
of the word "fault" in the standard.
The typical case would be that such a fault crashes the program, so what
are the semantics of the sample code?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYa4Y54fE9F5KGVdW2epxJTr41KoqtGxRZSFcmHYfuArg%40mail.gmail.com.
--001a11435bf8ab5b1d05554eb73d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 27, 2017 at 10:54 AM, Ville Voutilainen <span dir=3D"ltr"><<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Incorrect. " Indirection through an invalid pointer value a=
nd passing<br>
an invalid pointer value to a deallocation<br>
function have undefined behavior. Any other use of an invalid pointer<br>
value has implementation-defined behavior."</blockquote><div><br>"=
;36) Some implementations might define that copying an invalid pointer valu=
e causes a system-generated runtime fault."<br>The standard doesn'=
t say what a "runtime fault" is - this is the only use of the wor=
d "fault" in the standard.<br>The typical case would be that such=
a fault crashes the program, so what are the semantics of the sample code?=
</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" 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/CAHSYqdYa4Y54fE9F5KGVdW2epxJTr41KoqtG=
xRZSFcmHYfuArg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYa4Y54fE9F=
5KGVdW2epxJTr41KoqtGxRZSFcmHYfuArg%40mail.gmail.com</a>.<br />
--001a11435bf8ab5b1d05554eb73d--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 27 Jul 2017 12:08:09 -0400
Raw View
--001a1135977c85bd4f05554ec610
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 12:01 PM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> That was the point of this entire discussion: you can use the .data()
> pointer
> *because* you know it's valid. You can't dereference it yet because the
> data
> there has not begun its lifetime, though.
In the posted code, someone was trying to check whether reallocation had
occurred by doing
void *old_pointer = v.data();
// Do a bunch of stuff
if (v.data() == old_pointer) { /* no reallocation has occurred */ }
But if reallocation had occurred, old_pointer might hold an invalid pointer
value, and trying
to read it could cause a "system-generated runtime fault".
--
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/CAHSYqdY5J5nTUdNtkkhr%3DwJudFcDyf8qHE5QfL2q0_WcrgPUjA%40mail.gmail.com.
--001a1135977c85bd4f05554ec610
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 27, 2017 at 12:01 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That was =
the point of this entire discussion: you can use the .data() pointer<br>
*because* you know it's valid. You can't dereference it yet because=
the data<br>
there has not begun its lifetime, though.</blockquote><div><br>In the poste=
d code, someone was trying to check whether reallocation had occurred by do=
ing<br><br>=C2=A0 =C2=A0 void *old_pointer =3D v.data();<br>=C2=A0 =C2=A0 /=
/ Do a bunch of stuff<br>=C2=A0 =C2=A0 if (v.data() =3D=3D old_pointer) { /=
* no reallocation has occurred */ }<br><br>But if reallocation had occurred=
, old_pointer might hold an invalid pointer value, and trying<br>to read it=
could cause a "<span style=3D"font-size:12.8px">system-generated runt=
ime fault".</span></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" 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/CAHSYqdY5J5nTUdNtkkhr%3DwJudFcDyf8qHE=
5QfL2q0_WcrgPUjA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY5J5nTUd=
Ntkkhr%3DwJudFcDyf8qHE5QfL2q0_WcrgPUjA%40mail.gmail.com</a>.<br />
--001a1135977c85bd4f05554ec610--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 09:16:52 -0700
Raw View
On quinta-feira, 27 de julho de 2017 09:08:09 PDT Hyman Rosen wrote:
> In the posted code, someone was trying to check whether reallocation had
> occurred by doing
>
> void *old_pointer = v.data();
> // Do a bunch of stuff
> if (v.data() == old_pointer) { /* no reallocation has occurred */ }
>
> But if reallocation had occurred, old_pointer might hold an invalid pointer
> value, and trying
> to read it could cause a "system-generated runtime fault".
Right, you can't do that.
This could happen on protected-mode 16- and 32-bit x86 with FAR pointers. The
upper 16 bits of the pointer are the segment descriptor. But you cannot load
them into a segment register if the LDT or GDT lacks an entry for that
segment: a GPF occurs if you do.
The compiler could implement the above comparison without loading into the
registers, just performing a plain 32- or 48-bit memory comparison. Or it
could load them, you don't know.
Hence, implementation-defined.
Conclusion: you cannot portably determine if the old pointer is the same as
the new one because you can't use the old pointer in the first place.
(But everyone does it)
--
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/2233516.vx36bHqgMl%40tjmaciei-mobl1.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 27 Jul 2017 12:29:20 -0400
Raw View
--001a113d7e6a4c237b05554f12a4
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 12:16 PM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> Conclusion: you cannot portably determine if the old pointer is the same as
> the new one because you can't use the old pointer in the first place.
> (But everyone does it)
You could use memcmp to compare the pointers byte by byte.
--
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/CAHSYqdYLQpnCF-hWhK1ML0-7gUkjjztwBeXm5gFOeU7iANm%2BLw%40mail.gmail.com.
--001a113d7e6a4c237b05554f12a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 27, 2017 at 12:16 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
Conclusion: you cannot portably determine if the old pointer is the same as=
<br>
the new one because you can't use the old pointer in the first place.<b=
r>
(But everyone does it)</blockquote><div><br>You could use memcmp to compare=
the pointers byte by byte.=C2=A0</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" 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/CAHSYqdYLQpnCF-hWhK1ML0-7gUkjjztwBeXm=
5gFOeU7iANm%2BLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYLQpnCF-=
hWhK1ML0-7gUkjjztwBeXm5gFOeU7iANm%2BLw%40mail.gmail.com</a>.<br />
--001a113d7e6a4c237b05554f12a4--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 27 Jul 2017 18:30:36 +0200
Raw View
--001a11c15ddea2530705554f1589
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 6:01 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> That was the point of this entire discussion: you can use the .data()
pointer *because* you know it's valid. You can't dereference it yet because
the data there has not begun its lifetime, though.
If we "know" the pointer is valid, and the data type has vacuous
initialisation (e.g., a char), then you can dereference the pointer, since
the lifetime has started. See [basic.life].
Cheers,
V.
--
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/CAA7YVg09Rdq_r__eoCQ7b6otwR%2BN%2BZyZTR_UeEMTG3CtyVpfGQ%40mail.gmail.com.
--001a11c15ddea2530705554f1589
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 27, 2017 at 6:01 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><div><br></div><div>> That was the point of this ent=
ire discussion: you can use the .data() pointer *because* you know it's=
valid. You can't dereference it yet because the data there has not beg=
un its lifetime, though.</div><div><br></div><div>If we "know" th=
e pointer is valid, and the data type has vacuous initialisation (e.g., a c=
har), then you can dereference the pointer, since the lifetime has started.=
See [basic.life].</div><div><br></div><div>Cheers,</div><div>V.</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" 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/CAA7YVg09Rdq_r__eoCQ7b6otwR%2BN%2BZyZ=
TR_UeEMTG3CtyVpfGQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg09Rdq_=
r__eoCQ7b6otwR%2BN%2BZyZTR_UeEMTG3CtyVpfGQ%40mail.gmail.com</a>.<br />
--001a11c15ddea2530705554f1589--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 09:37:16 -0700
Raw View
On Thursday, 27 July 2017 09:29:20 PDT Hyman Rosen wrote:
> On Thu, Jul 27, 2017 at 12:16 PM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > Conclusion: you cannot portably determine if the old pointer is the same
> > as
> > the new one because you can't use the old pointer in the first place.
> > (But everyone does it)
>
> You could use memcmp to compare the pointers byte by byte.
Bitwise comparison success is not necessary for equality. Now think of real-
mode x86, where you have 32 bits in a FAR pointer, but only 20 of which
determine the actual address in the low megabyte of RAM.
I'm not sure we can even say bitwise comparison success is sufficient: is it
possible that two pointers are bitwise equal but not really equal?
--
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/4490429.OJ5k9pV68Z%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 09:37:56 -0700
Raw View
On Thursday, 27 July 2017 09:30:36 PDT Viacheslav Usov wrote:
> If we "know" the pointer is valid, and the data type has vacuous
> initialisation (e.g., a char), then you can dereference the pointer, since
> the lifetime has started. See [basic.life].
Indeed.
But if vector new()s again, then a new lifetime starts and the compiler could
do dead-store elimination on everything that happened before.
--
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/6489005.63Ilz0a3lY%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 27 Jul 2017 09:41:34 -0700 (PDT)
Raw View
------=_Part_1025_767444685.1501173695068
Content-Type: multipart/alternative;
boundary="----=_Part_1026_1910313983.1501173695068"
------=_Part_1026_1910313983.1501173695068
Content-Type: text/plain; charset="UTF-8"
On Thursday, July 27, 2017 at 12:30:39 PM UTC-4, Viacheslav Usov wrote:
>
> On Thu, Jul 27, 2017 at 6:01 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
> > That was the point of this entire discussion: you can use the .data()
> pointer *because* you know it's valid. You can't dereference it yet because
> the data there has not begun its lifetime, though.
>
> If we "know" the pointer is valid, and the data type has vacuous
> initialisation (e.g., a char), then you can dereference the pointer, since
> the lifetime has started. See [basic.life].
>
No, it has not. The lifetime of an object cannot be started until the
object has been created, and an object is only created through the means
defined in [intro.object]/1. And writing to a piece of memory is not listed
there.
"Vacuous initialization" is not a free pass from object creation. It just
means that the object doesn't have to be initialized; it still has to be
*created*.
--
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/982844e6-3453-4fb5-8844-6842134524e9%40isocpp.org.
------=_Part_1026_1910313983.1501173695068
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 27, 2017 at 12:30:39 PM UTC-4, V=
iacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jul 27, 2017 at 6:01 PM, T=
hiago Macieira <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"fOgSSXW_AAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">thi...@macieira.org</a>></span> wrote:<b=
r><div><br></div><div>> That was the point of this entire discussion: yo=
u can use the .data() pointer *because* you know it's valid. You can=
9;t dereference it yet because the data there has not begun its lifetime, t=
hough.</div><div><br></div><div>If we "know" the pointer is valid=
, and the data type has vacuous initialisation (e.g., a char), then you can=
dereference the pointer, since the lifetime has started. See [basic.life].=
</div></div></div></div></blockquote><div><br>No, it has not. The lifetime =
of an object cannot be started until the object has been created, and an ob=
ject is only created through the means defined in [intro.object]/1. And wri=
ting to a piece of memory is not listed there.<br><br>"Vacuous initial=
ization" is not a free pass from object creation. It just means that t=
he object doesn't have to be initialized; it still has to be <i>created=
</i>.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/982844e6-3453-4fb5-8844-6842134524e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/982844e6-3453-4fb5-8844-6842134524e9=
%40isocpp.org</a>.<br />
------=_Part_1026_1910313983.1501173695068--
------=_Part_1025_767444685.1501173695068--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Thu, 27 Jul 2017 13:03:35 -0400
Raw View
--001a11473cf09c783c05554f8b1e
Content-Type: text/plain; charset="UTF-8"
It might be interesting for someone to submit a paper for SG12 to look at.
A case of "you cannot portably do this (but everyone does it)" sounds right
up that study group's alley.
2017-07-27 12:16 GMT-04:00 Thiago Macieira <thiago@macieira.org>:
> On quinta-feira, 27 de julho de 2017 09:08:09 PDT Hyman Rosen wrote:
> > In the posted code, someone was trying to check whether reallocation had
> > occurred by doing
> >
> > void *old_pointer = v.data();
> > // Do a bunch of stuff
> > if (v.data() == old_pointer) { /* no reallocation has occurred */ }
> >
> > But if reallocation had occurred, old_pointer might hold an invalid
> pointer
> > value, and trying
> > to read it could cause a "system-generated runtime fault".
>
> Right, you can't do that.
>
> This could happen on protected-mode 16- and 32-bit x86 with FAR pointers.
> The
> upper 16 bits of the pointer are the segment descriptor. But you cannot
> load
> them into a segment register if the LDT or GDT lacks an entry for that
> segment: a GPF occurs if you do.
>
> The compiler could implement the above comparison without loading into the
> registers, just performing a plain 32- or 48-bit memory comparison. Or it
> could load them, you don't know.
>
> Hence, implementation-defined.
>
> Conclusion: you cannot portably determine if the old pointer is the same as
> the new one because you can't use the old pointer in the first place.
> (But everyone does it)
>
> --
> 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/2233516.vx36bHqgMl%40tjmaciei-mobl1.
>
--
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/CAKiZDp0ZeS0ON18C2YUFjFH--k%3DsyCv3b8icUjS5-UWfDJFUHA%40mail.gmail.com.
--001a11473cf09c783c05554f8b1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It might be interesting for someone to submit a paper for =
SG12 to look at. A case of "you cannot portably do this (but everyone =
does it)" sounds right up that study group's alley.<br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-07-27 12:16 GMT-0=
4:00 Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieir=
a.org" target=3D"_blank">thiago@macieira.org</a>></span>:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><span class=3D"">On quinta-feira, 27 de julho de 2017 0=
9:08:09 PDT Hyman Rosen wrote:<br>
> In the posted code, someone was trying to check whether reallocation h=
ad<br>
> occurred by doing<br>
><br>
>=C2=A0 =C2=A0 =C2=A0void *old_pointer =3D v.data();<br>
>=C2=A0 =C2=A0 =C2=A0// Do a bunch of stuff<br>
>=C2=A0 =C2=A0 =C2=A0if (v.data() =3D=3D old_pointer) { /* no reallocati=
on has occurred */ }<br>
><br>
> But if reallocation had occurred, old_pointer might hold an invalid po=
inter<br>
> value, and trying<br>
> to read it could cause a "system-generated runtime fault".<b=
r>
<br>
</span>Right, you can't do that.<br>
<br>
This could happen on protected-mode 16- and 32-bit x86 with FAR pointers. T=
he<br>
upper 16 bits of the pointer are the segment descriptor. But you cannot loa=
d<br>
them into a segment register if the LDT or GDT lacks an entry for that<br>
segment: a GPF occurs if you do.<br>
<br>
The compiler could implement the above comparison without loading into the<=
br>
registers, just performing a plain 32- or 48-bit memory comparison. Or it<b=
r>
could load them, you don't know.<br>
<br>
Hence, implementation-defined.<br>
<br>
Conclusion: you cannot portably determine if the old pointer is the same as=
<br>
the new one because you can't use the old pointer in the first place.<b=
r>
(But everyone does it)<br>
<span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span class=3D"">--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/2233516.vx36bHqgMl%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/2233516.vx36bHqgMl%<wbr>40tjmaciei-=
mobl1</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" 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/CAKiZDp0ZeS0ON18C2YUFjFH--k%3DsyCv3b8=
icUjS5-UWfDJFUHA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0ZeS0ON1=
8C2YUFjFH--k%3DsyCv3b8icUjS5-UWfDJFUHA%40mail.gmail.com</a>.<br />
--001a11473cf09c783c05554f8b1e--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 27 Jul 2017 10:09:40 -0700
Raw View
--089e082211ac56298605554fa1e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 26, 2017 at 8:05 PM, <stevemk14ebr@gmail.com> wrote:
>
>> As nicol states problem 1) Using the value of an empty `vector`'s pointe=
r
> as some kind of marker, a pointer to hold until its filled in later.
>
> There's two immediate cases i can think of [...]
> [...] gives you a way to check if the buffer was re-allocated
> std::vector<uint8_t> buf;
> buf.reserve(32);
> uint8_t* raw_buf =3D buf.data();
> buf.push_back({1,2,3});
> if(buf.data() !=3Draw_buf)
> error("oh no we got moved on push_back");
>
FYI, no, if the buffer *did* get reallocated then this "check" would have
undefined behavior. This is analogous to "checking for signed integer
overflow" after you've already done the addition: it doesn't work. *BUT,*
if buf.data() were guaranteed to return a stable value even for an empty
(zero-size + nonzero-capacity) vector, then you wouldn't have to "check" at
all; you'd just be guaranteed that buf.data() =3D=3D raw_buf.
Here's an example of the sort of thing you'd be able to do with a data()
pointer that was stable between reallocations:
int *gp =3D nullptr;
extern "C" void c_api_remember(int *p) { gp =3D p; }
extern "C" void c_api_use(int i) { printf("%d\n", gp[i]); }
int main() {
std::vector<int> buf;
buf.reserve(100);
c_api_remember(buf.data()); // works in practice but isn't blessed by
the standard
for (int i=3D0; i < 100; ++i) {
buf.push_back(i);
c_api_use(i);
}
}
> Where is it stated that a pointer has to point to a valid object, can it
> not just point to memory.
>
(This line of questioning is a rabbit hole that you should not go down.
Just let it drop.)
As Nicol states problem 2) Filling in the contents of a `vector` without
> having to initialize those contents twice.
> Imagine any C api ever that look like this
> int fillSomeBuffer(T* buf); //returns the number of T's actually put into
> buf
>
> As it is you have to do this to not invoke U.B or overwrite elements
> std::vector<uint8_t> buf;
> buf.reserve(32);
> uint8_t cBuf[32];
> int count =3D fillSomebuffer(cBuf);
> buf.insert(cBuf, cBuf + count);
>
> Ew, look at how horrible that is. Surely we can do better.
>
Well, in this case the *obvious* way to do better is
std::vector<uint8_t> buf(32);
buf.resize(fillSomebuffer(buf.data()));
Sure, this runs the risk of an insufficiently smart compiler initializing a
few (<=3D32) extra bytes to all-zero-bits. But trust me, even if you use -O=
99
and a magic compiler from the future, your compiler *still* probably
initializes 32 bytes to all-zeros at least a *couple* of times more often
than it needs to, *somewhere* in your codebase. I really would not worry
about the cost in nanoseconds because for all intents and purposes there is
no cost.
However, if you really really want to avoid all-bits-zero-constructing the
elements of a container, that's what the C++ allocator model is for.
https://wandbox.org/permlink/WS6x1g1rdSI6Iri7
This is the second time I've given you this link. *Please click on it.*
=E2=80=93Arthur
--=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/CADvuK0KwFD0x9qt%2BoQ-vbZPz23qyxrx4niqPk8r6-2j-J=
c-%3D-Q%40mail.gmail.com.
--089e082211ac56298605554fa1e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Jul 26, 2017 at 8:05 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:stevemk14ebr@gmail.com" target=3D"_blank">stevemk14ebr@gmai=
l.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><br></blockquote></span><div>As nicol states problem 1) Using the =
value of an empty `vector`'s pointer as some kind of marker, a pointer =
to hold until its filled in later.</div><div><br></div><div>There's two=
immediate cases i can think of [...]</div><div>[...] gives you a way to ch=
eck if the buffer was re-allocated<br></div><div><div class=3D"gmail-m_-728=
2902709361860247prettyprint" style=3D"background-color:rgb(250,250,250);bor=
der:1px solid rgb(187,187,187);word-wrap:break-word"><code class=3D"gmail-m=
_-7282902709361860247prettyprint"><div class=3D"gmail-m_-728290270936186024=
7subprettyprint"><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902=
709361860247styled-by-prettify">std</span><span style=3D"color:rgb(102,102,=
0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">::</span><span=
style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-=
prettify">vector</span><span style=3D"color:rgb(0,136,0)" class=3D"gmail-m_=
-7282902709361860247styled-by-prettify"><uint8_t></span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-pretti=
fy"> buf</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-72829=
02709361860247styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_-7282902709361860247styled-by-prettify"><br>buf</span><spa=
n style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247style=
d-by-prettify">.</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7=
282902709361860247styled-by-prettify">reserve</span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">(</s=
pan><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-7282902709361860=
247styled-by-prettify">32</span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-7282902709361860247styled-by-prettify">);</span><span style=3D=
"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify"=
><br>uint8_t</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7=
282902709361860247styled-by-prettify">*</span><span style=3D"color:rgb(0,0,=
0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify"> raw_buf </spa=
n><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-728290270936186024=
7styled-by-prettify">=3D</span><span style=3D"color:rgb(0,0,0)" class=3D"gm=
ail-m_-7282902709361860247styled-by-prettify"> buf</span><span style=3D"col=
or:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify"=
>.</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-728290270936186=
0247styled-by-prettify">data</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"gmail-m_-7282902709361860247styled-by-prettify">();</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-pretti=
fy"><br>buf</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-72=
82902709361860247styled-by-prettify">.</span><font color=3D"#000000"><span =
style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-p=
rettify">push_back</span><span style=3D"color:rgb(102,102,0)" class=3D"gmai=
l-m_-7282902709361860247styled-by-prettify">({</span><span style=3D"color:r=
gb(0,102,102)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">1</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-728290270936186=
0247styled-by-prettify">,</span><span style=3D"color:rgb(0,102,102)" class=
=3D"gmail-m_-7282902709361860247styled-by-prettify">2</span><span style=3D"=
color:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-pretti=
fy">,</span><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-72829027=
09361860247styled-by-prettify">3</span><span style=3D"color:rgb(102,102,0)"=
class=3D"gmail-m_-7282902709361860247styled-by-prettify">});</span><span s=
tyle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-pr=
ettify"><br></span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-728=
2902709361860247styled-by-prettify">if</span><span style=3D"color:rgb(102,1=
02,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">(</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-b=
y-prettify">buf</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m=
_-7282902709361860247styled-by-prettify">.</span><span style=3D"color:rgb(0=
,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">data</span>=
<span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247s=
tyled-by-prettify">()</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail=
-m_-7282902709361860247styled-by-prettify"> </span><span style=3D"color:rgb=
(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">!=3D<=
/span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-728290270936186024=
7styled-by-prettify">raw_buf</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"gmail-m_-7282902709361860247styled-by-prettify">)</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-pretti=
fy"><br>=C2=A0 =C2=A0error</span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-7282902709361860247styled-by-prettify">(</span><span style=3D"=
color:rgb(0,136,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify=
">"oh no we got moved on push_back"</span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">);</=
span></font></div></code></div></div></div></blockquote><div><br></div><div=
>FYI, no, if the buffer <i>did</i> get reallocated then this "check&qu=
ot; would have undefined behavior. This is analogous to "checking for =
signed integer overflow" after you've already done the addition: i=
t doesn't work. =C2=A0<b><i>BUT,</i></b> if buf.data() were guaranteed =
to return a stable value even for an empty (zero-size + nonzero-capacity) v=
ector, then you wouldn't have to "check" at all; you'd ju=
st be guaranteed that buf.data() =3D=3D raw_buf.</div><div>Here's an ex=
ample of the sort of thing you'd be able to do with a data() pointer th=
at was stable between reallocations:</div><div><br></div><div><font face=3D=
"monospace, monospace">int *gp =3D nullptr;</font></div><div><font face=3D"=
monospace, monospace">extern "C" void c_api_remember(int *p) { gp=
=3D p; }</font></div><div><font face=3D"monospace, monospace">extern "=
;C" void c_api_use(int i) { printf("%d\n", gp[i]); }</font><=
/div><div><font face=3D"monospace, monospace">int main() {</font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 std::vector<int> b=
uf;</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 buf.=
reserve(100);</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 c_api_remember(buf.data()); =C2=A0// works in practice but isn't=
blessed by the standard<br></font></div><div><font face=3D"monospace, mono=
space">=C2=A0 =C2=A0 for (int i=3D0; i < 100; ++i) {</font></div><div><f=
ont face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 buf.push_back=
(i);</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 c_api_use(i);</font></div><div><font face=3D"monospace, monospac=
e">=C2=A0 =C2=A0 }</font></div><div><font face=3D"monospace, monospace">}</=
font></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div></div><div>Where is it stated that a pointer has to point to a =
valid object, can it not just point to memory.</div></div></div></blockquot=
e><div><br></div><div>(This line of questioning is a rabbit hole that you s=
hould not go down. Just let it drop.)</div><div><br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div>As Nicol states problem 2) Fillin=
g in the contents of a `vector` without having to initialize those contents=
twice.<br></div></div><div>Imagine any C api ever that look like this=C2=
=A0</div><div><div class=3D"gmail-m_-7282902709361860247prettyprint" style=
=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);wor=
d-wrap:break-word"><code class=3D"gmail-m_-7282902709361860247prettyprint">=
<div class=3D"gmail-m_-7282902709361860247subprettyprint"><span style=3D"fo=
nt-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(0,0,136)" cl=
ass=3D"gmail-m_-7282902709361860247styled-by-prettify">int</span><span styl=
e=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-prett=
ify"> fillSomeBuffer</span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-7282902709361860247styled-by-prettify">(</span><span style=3D"color:=
rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">T</spa=
n><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-728290270936186024=
7styled-by-prettify">*</span><span style=3D"color:rgb(0,0,0)" class=3D"gmai=
l-m_-7282902709361860247styled-by-prettify"> buf</span><span style=3D"color=
:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">)=
;</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860=
247styled-by-prettify"> </span><span style=3D"color:rgb(136,0,0)" class=3D"=
gmail-m_-7282902709361860247styled-by-prettify">//returns the number of T&#=
39;s actually put into buf </span></span><span style=3D"color:rgb(0,0,0)" c=
lass=3D"gmail-m_-7282902709361860247styled-by-prettify"><br></span></div></=
code></div><div><br></div>As it is you have to do this to not invoke U.B or=
overwrite elements</div><div><div class=3D"gmail-m_-7282902709361860247pre=
ttyprint" style=3D"background-color:rgb(250,250,250);border:1px solid rgb(1=
87,187,187);word-wrap:break-word"><code class=3D"gmail-m_-72829027093618602=
47prettyprint"><div class=3D"gmail-m_-7282902709361860247subprettyprint"><s=
pan style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-=
by-prettify">std</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_-7282902709361860247styled-by-prettify">::</span><span style=3D"color:rgb=
(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">vector</s=
pan><span style=3D"color:rgb(0,136,0)" class=3D"gmail-m_-728290270936186024=
7styled-by-prettify"><uint8_t></span><font color=3D"#000000"><span st=
yle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-pre=
ttify"> buf</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-72=
82902709361860247styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-7282902709361860247styled-by-prettify"><br>buf</span><=
span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247st=
yled-by-prettify">.</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m=
_-7282902709361860247styled-by-prettify">reserve</span><span style=3D"color=
:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">(=
</span><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-7282902709361=
860247styled-by-prettify">32</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"gmail-m_-7282902709361860247styled-by-prettify">);</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-pretti=
fy"><br>uint8_t cBuf</span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-7282902709361860247styled-by-prettify">[</span><span style=3D"color:=
rgb(0,102,102)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">32=
</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7282902709361=
860247styled-by-prettify">];</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-7282902709361860247styled-by-prettify"><br></span><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_-7282902709361860247styled-by-pret=
tify">int</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-72829027=
09361860247styled-by-prettify"> count </span><span style=3D"color:rgb(102,1=
02,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">=3D</span><=
span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled=
-by-prettify"> fillSomebuffer</span><span style=3D"color:rgb(102,102,0)" cl=
ass=3D"gmail-m_-7282902709361860247styled-by-prettify">(</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-pretti=
fy">cBuf</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-72829=
02709361860247styled-by-prettify">);</span><span style=3D"color:rgb(0,0,0)"=
class=3D"gmail-m_-7282902709361860247styled-by-prettify"><br>buf</span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247styl=
ed-by-prettify">.</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-=
7282902709361860247styled-by-prettify">insert</span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify">(</s=
pan><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247s=
tyled-by-prettify">cBuf</span><span style=3D"color:rgb(102,102,0)" class=3D=
"gmail-m_-7282902709361860247styled-by-prettify">,</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_-7282902709361860247styled-by-prettify"> cB=
uf </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7282902709=
361860247styled-by-prettify">+</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-7282902709361860247styled-by-prettify"> count</span><span styl=
e=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7282902709361860247styled-by-p=
rettify">);</span></font></div></code></div><div><br></div>Ew, look at how =
horrible that is. Surely we can do better.=C2=A0</div></div></blockquote><d=
iv><br></div><div>Well, in this case the <i>obvious</i> way to do better is=
</div><div><br></div><div>=C2=A0 =C2=A0 std::vector<uint8_t> buf(32);=
</div><div>=C2=A0 =C2=A0 buf.resize(fillSomebuffer(buf.data()));</div><div>=
<br></div><div>Sure, this runs the risk of an insufficiently smart compiler=
initializing a few (<=3D32) extra bytes to all-zero-bits. But trust me,=
even if you use -O99 and a magic compiler from the future, your compiler=
=C2=A0<i>still</i> probably initializes 32 bytes to all-zeros at least a <i=
>couple</i> of times more often than it needs to, <i>somewhere</i> in your =
codebase.=C2=A0 I really would not worry about the cost in nanoseconds beca=
use for all intents and purposes there is no cost.</div><div><br></div><div=
>However, if you really really want to avoid all-bits-zero-constructing the=
elements of a container, that's what the C++ allocator model is for.</=
div><div><br></div><div>=C2=A0 =C2=A0=C2=A0<a href=3D"https://wandbox.org/p=
ermlink/WS6x1g1rdSI6Iri7">https://wandbox.org/permlink/WS6x1g1rdSI6Iri7</a>=
</div><div><br></div><div>This is the second time I've given you this l=
ink. <b>Please click on it.</b></div><div><br></div><div>=E2=80=93Arthur</d=
iv></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0KwFD0x9qt%2BoQ-vbZPz23qyxrx4ni=
qPk8r6-2j-Jc-%3D-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KwFD0x=
9qt%2BoQ-vbZPz23qyxrx4niqPk8r6-2j-Jc-%3D-Q%40mail.gmail.com</a>.<br />
--089e082211ac56298605554fa1e2--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Thu, 27 Jul 2017 13:18:44 -0400
Raw View
--Apple-Mail=_C13CADE3-5068-44AF-95A9-A90C282B1793
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
On Jul 27, 2017, at 12:16 PM, Thiago Macieira <thiago@macieira.org> wrote:
>=20
> On quinta-feira, 27 de julho de 2017 09:08:09 PDT Hyman Rosen wrote:
>> In the posted code, someone was trying to check whether reallocation had
>> occurred by doing
>>=20
>> void *old_pointer =3D v.data();
>> // Do a bunch of stuff
>> if (v.data() =3D=3D old_pointer) { /* no reallocation has occurred */=
}
>>=20
>> But if reallocation had occurred, old_pointer might hold an invalid poin=
ter
>> value, and trying
>> to read it could cause a "system-generated runtime fault".
>=20
> Right, you can't do that.
>=20
> This could happen on protected-mode 16- and 32-bit x86 with FAR pointers.=
The
> upper 16 bits of the pointer are the segment descriptor. But you cannot l=
oad
> them into a segment register if the LDT or GDT lacks an entry for that
> segment: a GPF occurs if you do.
>=20
> The compiler could implement the above comparison without loading into th=
e
> registers, just performing a plain 32- or 48-bit memory comparison. Or it
> could load them, you don't know.
>=20
> Hence, implementation-defined.
>=20
> Conclusion: you cannot portably determine if the old pointer is the same =
as
> the new one because you can't use the old pointer in the first place.
> (But everyone does it)
If Herb=E2=80=99s spaceship operator gets passed, you would be able to comp=
are the pointers using that. (http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2017/p0515r1.pdf) If for no other reason than a total ordering among=
pointers, we should pass P0515.
Howard
--=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/B7E372CA-3810-4358-B0D2-A8B6A35E66B4%40gmail.com=
..
--Apple-Mail=_C13CADE3-5068-44AF-95A9-A90C282B1793
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJZeiB1AAoJEGbcHCxKqhWCha4P/jwodhfhuGmW0TX6VNlMcG/u
xem2tkC9rHQNvje36wh4FySHHK/Nv592LDDfo3VX9/qw8wiZDX/j+CFvXApg/AM2
qjEwJ94DTXjGkOxx6zTgg69hyzH96IM13/WioeCBqB9f1NLZgpy9VgukwxMapVsa
yVwEI1Zbpf9atVMceFv2rulA4vjOQch5V5KFKFf2/KARaD7RzMbNH2qKbpO7S1hL
zIL4y5PkhmxysCyXQuIlA/Rv6fMUSjo9wop+Y7/K085W0ZFgZHWZ74wFzoDCTPP0
P1TSgElLKJgCNf+XuObwUjTX6m8FPFahZmODYz9GGWX/qOshGTj1XzvjzHnn6coP
V6YPR/ZYv4x6U/jSogYGVmSy5RPlsGgdKd5vvQD7H9SgCpDQmwSSr5EIBeMDcID3
ym5f5KMXLGDj0s0Le+Ck0y6yYKDIDHOyE75Kn7qoo94HFiBhS6UeRhP+VJE9IKwO
k03iGOUH2rwRfjCWCv5ygzGFfkW0sgmGGIhnPinFj2bsBvt+u/dMtJmeX1A1tuzm
KeyWRO0a2GlEpWlI3Bn32OTmUYSZTFg+axVK8+J3sWahrlo6OUXsiXEWHF+m4+kD
vRGuR/4An4ss1CmC1guwAt8BdT/Hkg+j/WCRKdY/YF2EZTWoxiNZlFV74b057m0g
PjLqA+3Tfwl0ReJOkbku
=BSf3
-----END PGP SIGNATURE-----
--Apple-Mail=_C13CADE3-5068-44AF-95A9-A90C282B1793--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 20:21:53 +0300
Raw View
On 27 July 2017 at 20:03, Patrice Roy <patricer@gmail.com> wrote:
> It might be interesting for someone to submit a paper for SG12 to look at. A
> case of "you cannot portably do this (but everyone does it)" sounds right up
> that study group's alley.
I doubt that. We know that the behavior is implementation-defined
because platforms where
it used to matter were once somewhat common, and out of concern that
they might become common again,
we haven't nailed that behavior down.
--
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/CAFk2RUZFt0gWvPw-d4vbKj_%2Bu32%3DxtHZ6Uj9S67cxqtfgP5icQ%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 20:22:56 +0300
Raw View
On 27 July 2017 at 20:09, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> On Wed, Jul 26, 2017 at 8:05 PM, <stevemk14ebr@gmail.com> wrote:
>>>
>>>
>> As nicol states problem 1) Using the value of an empty `vector`'s pointer
>> as some kind of marker, a pointer to hold until its filled in later.
>>
>> There's two immediate cases i can think of [...]
>> [...] gives you a way to check if the buffer was re-allocated
>> std::vector<uint8_t> buf;
>> buf.reserve(32);
>> uint8_t* raw_buf = buf.data();
>> buf.push_back({1,2,3});
>> if(buf.data() !=raw_buf)
>> error("oh no we got moved on push_back");
>
>
> FYI, no, if the buffer did get reallocated then this "check" would have
> undefined behavior.
This is, again, incorrect, so you might as well all stop repeating that claim.
--
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/CAFk2RUZSOdt%2BCUNzSUf0Z02X8i7OkGDvJyK7%2Biyp9EdXeS1%3DhA%40mail.gmail.com.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 27 Jul 2017 10:37:03 -0700
Raw View
--f403043e44f04e99c60555500306
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Jul 27, 2017 at 10:03 AM, Patrice Roy <patricer@gmail.com> wrote:
> 2017-07-27 12:16 GMT-04:00 Thiago Macieira <thiago@macieira.org>:
>>
>> Conclusion: you cannot portably determine if the old pointer is the same
as
>> the new one because you can't use the old pointer in the first place.
>> (But everyone does it)
>
> It might be interesting for someone to submit a paper for SG12 to look at=
..
> A case of "you cannot portably do this (but everyone does it)" sounds
right
> up that study group's alley.
IMO, using a pointer's value after free() is a pretty well established
source of exploitable UB in the past few years. (I mean "exploitable" in
the sense that modern compilers exploit its optimization potential. Of
course if you're using UB you might get some security vulnerabilities as
well, but that's not my department.) See for example "Winner #2" here:
https://blog.regehr.org/archives/767
John Regehr will be one of the speakers at CppCon 2017. :)
On the related topic of "you cannot portably do this (but everyone does
it)" =E2=80=94 a.k.a. "std::vector is not implementable (but everyone imple=
ments
it)" =E2=80=94 also at this year's CppCon, Nicolai Josuttis has submitted a=
talk
titled "Why push_back(), optional, and variant are broken and why
std::launder() doesn't help". If the myriad rabbit-holes in this thread
interest you, you'll probably be interested in that talk.
@Howard Hinnant: actually the "total order" on pointers provided by
operator<=3D> (and also by the existing std::less<T*>) isn't good enough to
make the OP's code work. What you need in order to make the use-after-free
code work is a total order even on *pointer-shaped bit-patterns* that are
no longer valid due to having been freed. I admit I can't read Herb's mind,
but I am fairly confident that he is not *intending* to imply well-defined
behavior for this code:
int *p =3D new int[10];
int *q =3D new int[10];
printf(%d\n", (int)(p !=3D q)); // currently well-defined, prints "1"
delete [] p;
delete [] q;
printf("%d\n", (int)(p !=3D q)); // print "1", or keep the current
undefined behavior?
If we want to make this code well-defined, we'll have to go back and teach
Clang that it's well-defined; see the URL linked above for an example of
how Clang exploits this undefined behavior for optimization. (This is
awkward but certainly not a killer; C++17 well-defined a ton of things that
used to be exploitable UB, and there's nothing stopping us from continuing
in that vein a little further.)
=E2=80=93Arthur
--=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/CADvuK0JSGV%2BnJO7EhN8vuP%3Df%3DafYjjTXoXTOPtmDh=
1_RDJn1YQ%40mail.gmail.com.
--f403043e44f04e99c60555500306
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jul 27, 2017 at 10:03 AM, Patrice Roy <<a href=
=3D"mailto:patricer@gmail.com">patricer@gmail.com</a>> wrote:<br>> 20=
17-07-27 12:16 GMT-04:00 Thiago Macieira <<a href=3D"mailto:thiago@macie=
ira.org">thiago@macieira.org</a>>:<br>>><br>>> Conclusion: y=
ou cannot portably determine if the old pointer is the same as<br>>> =
the new one because you can't use the old pointer in the first place.<b=
r>>> (But everyone does it)=C2=A0<br>><br>> It might be interes=
ting for someone to submit a paper for SG12 to look at.<div>> A case of =
"you cannot portably do this (but everyone does it)" sounds right=
</div><div>> up that study group's alley.<br><br>IMO, using a pointe=
r's value after free() is a pretty well established source of exploitab=
le UB in the past few years. (I mean "exploitable" in the sense t=
hat modern compilers exploit its optimization potential. Of course if you&#=
39;re using UB you might get some security vulnerabilities as well, but tha=
t's not my department.) See for example "Winner #2" here:<br>=
<a href=3D"https://blog.regehr.org/archives/767">https://blog.regehr.org/ar=
chives/767</a><br>John Regehr will be one of the speakers at CppCon 2017. :=
)<br><br><br></div><div>On the related topic of "you cannot portably d=
o this (but everyone does it)" =E2=80=94 a.k.a. "std::vector is n=
ot implementable (but everyone implements it)" =E2=80=94 also at this =
year's CppCon, Nicolai Josuttis has submitted a talk titled=C2=A0"=
Why push_back(), optional, and variant are broken and why std::launder() do=
esn't help".=C2=A0If the myriad rabbit-holes in this thread intere=
st you, you'll probably be interested in that talk.</div><div><br></div=
><div><br></div><div>@Howard Hinnant: actually the "total order" =
on pointers provided by operator<=3D> (and also by the existing std::=
less<T*>) isn't good enough to make the OP's code work. What =
you need in order to make the use-after-free code work is a total order eve=
n on <i>pointer-shaped bit-patterns</i> that are no longer valid due to hav=
ing been freed. I admit I can't read Herb's mind, but I am fairly c=
onfident that he is not <i>intending</i> to imply well-defined behavior for=
this code:</div><div><br></div><div>=C2=A0 =C2=A0 int *p =3D new int[10];<=
/div><div>=C2=A0 =C2=A0 int *q =3D new int[10];</div><div>=C2=A0 =C2=A0 pri=
ntf(%d\n", (int)(p !=3D q)); =C2=A0// currently well-defined, prints &=
quot;1"</div><div>=C2=A0 =C2=A0 delete [] p;</div><div>=C2=A0 =C2=A0 d=
elete [] q;</div><div>=C2=A0 =C2=A0 printf("%d\n", (int)(p !=3D q=
)); =C2=A0// print "1", or keep the current undefined behavior?</=
div><div><br></div><div>If we want to make this code well-defined, we'l=
l have to go back and teach Clang that it's well-defined; see the URL l=
inked above for an example of how Clang exploits this undefined behavior fo=
r optimization. =C2=A0(This is awkward but certainly not a killer; C++17 we=
ll-defined a ton of things that used to be exploitable UB, and there's =
nothing stopping us from continuing in that vein a little further.)</div><d=
iv><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JSGV%2BnJO7EhN8vuP%3Df%3DafYjj=
TXoXTOPtmDh1_RDJn1YQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JSGV=
%2BnJO7EhN8vuP%3Df%3DafYjjTXoXTOPtmDh1_RDJn1YQ%40mail.gmail.com</a>.<br />
--f403043e44f04e99c60555500306--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 27 Jul 2017 10:39:06 -0700 (PDT)
Raw View
------=_Part_973_2076289494.1501177146700
Content-Type: multipart/alternative;
boundary="----=_Part_974_2077608158.1501177146700"
------=_Part_974_2077608158.1501177146700
Content-Type: text/plain; charset="UTF-8"
On Thursday, July 27, 2017 at 1:09:44 PM UTC-4, Arthur O'Dwyer wrote:
>
> However, if you really really want to avoid all-bits-zero-constructing the
> elements of a container, that's what the C++ allocator model is for.
>
> https://wandbox.org/permlink/WS6x1g1rdSI6Iri7
>
> This is the second time I've given you this link. *Please click on it.*
>
I'm not sure what that's supposed to prove. Yes, if you write your own
allocator, you can turn value initialization into default initialization.
But:
1: This requires using your own allocator. So `vector`s provided by other
APIs or whatever are non-workable with this.
2: It turns *all* value initialization into default initialization. So it's
no longer possible to value initialize elements at all.
--
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/9645b097-2ff1-4542-819b-eabb449162a1%40isocpp.org.
------=_Part_974_2077608158.1501177146700
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, July 27, 2017 at 1:09:44 PM UTC-4, Arthur O&#=
39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote"><div></div><div>However, if you really re=
ally want to avoid all-bits-zero-constructing the elements of a container, =
that's what the C++ allocator model is for.</div><div><br></div><div>=
=C2=A0 =C2=A0=C2=A0<a href=3D"https://wandbox.org/permlink/WS6x1g1rdSI6Iri7=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FWS6x1g1rdS=
I6Iri7\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFEbMx15844gLd-Bwnog0x-CMkkLg=
';return true;" onclick=3D"this.href=3D'https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FWS6x1g1rdSI6Iri7\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNFEbMx15844gLd-Bwnog0x-CMkkLg';return true;">h=
ttps://wandbox.org/<wbr>permlink/WS6x1g1rdSI6Iri7</a></div><div><br></div><=
div>This is the second time I've given you this link. <b>Please click o=
n it.</b></div></div></div></div></blockquote><div><br>I'm not sure wha=
t that's supposed to prove. Yes, if you write your own allocator, you c=
an turn value initialization into default initialization. But:<br><br>1: Th=
is requires using your own allocator. So `vector`s provided by other APIs o=
r whatever are non-workable with this.<br>2: It turns <i>all</i> value init=
ialization into default initialization. So it's no longer possible to v=
alue initialize elements at all.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9645b097-2ff1-4542-819b-eabb449162a1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9645b097-2ff1-4542-819b-eabb449162a1=
%40isocpp.org</a>.<br />
------=_Part_974_2077608158.1501177146700--
------=_Part_973_2076289494.1501177146700--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 27 Jul 2017 10:43:40 -0700 (PDT)
Raw View
------=_Part_1071_359707131.1501177420808
Content-Type: multipart/alternative;
boundary="----=_Part_1072_239122625.1501177420808"
------=_Part_1072_239122625.1501177420808
Content-Type: text/plain; charset="UTF-8"
On Thursday, July 27, 2017 at 12:37:27 PM UTC-4, Thiago Macieira wrote:
>
> On Thursday, 27 July 2017 09:29:20 PDT Hyman Rosen wrote:
> > On Thu, Jul 27, 2017 at 12:16 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>>
> >
> > wrote:
> > > Conclusion: you cannot portably determine if the old pointer is the
> same
> > > as
> > > the new one because you can't use the old pointer in the first place.
> > > (But everyone does it)
> >
> > You could use memcmp to compare the pointers byte by byte.
>
> Bitwise comparison success is not necessary for equality. Now think of
> real-
> mode x86, where you have 32 bits in a FAR pointer, but only 20 of which
> determine the actual address in the low megabyte of RAM.
>
> I'm not sure we can even say bitwise comparison success is sufficient: is
> it
> possible that two pointers are bitwise equal but not really equal?
>
That's essentially irrelevant for this question because you *cannot* use
pointer equality as a test to see if reallocation happened.
As I pointed out in one of my replies, if two reallocations happened, it is
possible that the second new pointer is the same as the old one. Or if you
reallocate and then move a new vector into it, they might be the same.
It is folly to even attempt to use pointer equality to test reallocation.
It's far better to simply check the capacity (but even that isn't
necessarily guaranteed, since you can shrink-to-fit or move from something).
--
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/a06f6b0e-46c6-4039-b879-46deedab6b25%40isocpp.org.
------=_Part_1072_239122625.1501177420808
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 27, 2017 at 12:37:27 PM UTC-4, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursd=
ay, 27 July 2017 09:29:20 PDT Hyman Rosen wrote:
<br>> On Thu, Jul 27, 2017 at 12:16 PM, Thiago Macieira <<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FWPANtS_AAAJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">thi...@macieira.o=
rg</a>>
<br>>=20
<br>> wrote:
<br>> > Conclusion: you cannot portably determine if the old pointer =
is the same
<br>> > as
<br>> > the new one because you can't use the old pointer in the =
first place.
<br>> > (But everyone does it)
<br>>=20
<br>> You could use memcmp to compare the pointers byte by byte.
<br>
<br>Bitwise comparison success is not necessary for equality. Now think of =
real-
<br>mode x86, where you have 32 bits in a FAR pointer, but only 20 of which=
=20
<br>determine the actual address in the low megabyte of RAM.
<br>
<br>I'm not sure we can even say bitwise comparison success is sufficie=
nt: is it=20
<br>possible that two pointers are bitwise equal but not really equal?
<br></blockquote><div><br>That's essentially irrelevant for this questi=
on because you *cannot* use pointer equality as a test to see if reallocati=
on happened.<br><br>As I pointed out in one of my replies, if two reallocat=
ions happened, it is possible that the second new pointer is the same as th=
e old one. Or if you reallocate and then move a new vector into it, they mi=
ght be the same.<br><br>It is folly to even attempt to use pointer equality=
to test reallocation. It's far better to simply check the capacity (bu=
t even that isn't necessarily guaranteed, since you can shrink-to-fit o=
r move from something).<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a06f6b0e-46c6-4039-b879-46deedab6b25%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a06f6b0e-46c6-4039-b879-46deedab6b25=
%40isocpp.org</a>.<br />
------=_Part_1072_239122625.1501177420808--
------=_Part_1071_359707131.1501177420808--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Thu, 27 Jul 2017 13:58:12 -0400
Raw View
--001a114926a0ee16df0555504e83
Content-Type: text/plain; charset="UTF-8"
@Ville : Good point
@Arthur : I understand what you mean; still, if it's common practice,
however misguided language-wise, it might deserve some scrutiny, including
clear exposure of the expected use-cases and alternative strategies. It
would require someone caring enough about the issue to put something down
in writing, obviously (I don't, but I'd be willing to read such a paper, to
better grasp the perspective of such a proposer).
2017-07-27 13:21 GMT-04:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 27 July 2017 at 20:03, Patrice Roy <patricer@gmail.com> wrote:
> > It might be interesting for someone to submit a paper for SG12 to look
> at. A
> > case of "you cannot portably do this (but everyone does it)" sounds
> right up
> > that study group's alley.
>
> I doubt that. We know that the behavior is implementation-defined
> because platforms where
> it used to matter were once somewhat common, and out of concern that
> they might become common again,
> we haven't nailed that behavior down.
>
> --
> 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/CAFk2RUZFt0gWvPw-d4vbKj_%2Bu32%
> 3DxtHZ6Uj9S67cxqtfgP5icQ%40mail.gmail.com.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0tJrs16ZiLkjNDkBKo1OBT2jih-sVvJ%3Dgt4EatLDRAtg%40mail.gmail.com.
--001a114926a0ee16df0555504e83
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Ville : Good point<br><br>@Arthur : I understand what you=
mean; still, if it's common practice, however misguided language-wise,=
it might deserve some scrutiny, including clear exposure of the expected u=
se-cases and alternative strategies. It would require someone caring enough=
about the issue to put something down in writing, obviously (I don't, =
but I'd be willing to read such a paper, to better grasp the perspectiv=
e of such a proposer).<br><br></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">2017-07-27 13:21 GMT-04:00 Ville Voutilainen <span dir=
=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blan=
k">ville.voutilainen@gmail.com</a>></span>:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><span class=3D"">On 27 July 2017 at 20:03, Patrice Roy <<a href=3D=
"mailto:patricer@gmail.com">patricer@gmail.com</a>> wrote:<br>
> It might be interesting for someone to submit a paper for SG12 to look=
at. A<br>
> case of "you cannot portably do this (but everyone does it)"=
sounds right up<br>
> that study group's alley.<br>
<br>
</span>I doubt that. We know that the behavior is implementation-defined<br=
>
because platforms where<br>
it used to matter were once somewhat common, and out of concern that<br>
they might become common again,<br>
we haven't nailed that behavior down.<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZFt0gWvPw-d4vbKj_%2Bu32=
%3DxtHZ6Uj9S67cxqtfgP5icQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposal=
s/CAFk2RUZFt0gWvPw-<wbr>d4vbKj_%2Bu32%<wbr>3DxtHZ6Uj9S67cxqtfgP5icQ%<wbr>40=
mail.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" 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/CAKiZDp0tJrs16ZiLkjNDkBKo1OBT2jih-sVv=
J%3Dgt4EatLDRAtg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0tJrs16Z=
iLkjNDkBKo1OBT2jih-sVvJ%3Dgt4EatLDRAtg%40mail.gmail.com</a>.<br />
--001a114926a0ee16df0555504e83--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 27 Jul 2017 13:57:57 -0400
Raw View
--001a11435bf83a74150555504f24
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 1:22 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> > FYI, no, if the buffer did get reallocated then this "check" would have
> > undefined behavior.
>
> This is, again, incorrect, so you might as well all stop repeating that
> claim.
It was undefined behavior in C++03. There are still plenty of people using
C++03 compilers (my own large employer included).
Now it's not undefined but it can cause a "system-generated runtime
fault". That sounds like a distinction without a difference.
--
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/CAHSYqdYCdcSQYqv83Oa_MSv_YqDjysKaFQH2LdM%2BcHVd5W9Qfg%40mail.gmail.com.
--001a11435bf83a74150555504f24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 27, 2017 at 1:22 PM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">
> FYI, no, if the buffer did get reallocated then this "check"=
would have<br>
> undefined behavior.<br>
<br>
</span>This is, again, incorrect, so you might as well all stop repeating t=
hat claim.</blockquote><div><br>It was undefined behavior in C++03.=C2=A0 T=
here are still plenty of people using C++03 compilers (my own large employe=
r included).<br>Now it's not undefined but it can cause a "system-=
generated runtime fault".=C2=A0 That sounds like a distinction without=
a difference.</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" 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/CAHSYqdYCdcSQYqv83Oa_MSv_YqDjysKaFQH2=
LdM%2BcHVd5W9Qfg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYCdcSQYq=
v83Oa_MSv_YqDjysKaFQH2LdM%2BcHVd5W9Qfg%40mail.gmail.com</a>.<br />
--001a11435bf83a74150555504f24--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 27 Jul 2017 11:05:32 -0700 (PDT)
Raw View
------=_Part_984_7494005.1501178732530
Content-Type: multipart/alternative;
boundary="----=_Part_985_1605196557.1501178732530"
------=_Part_985_1605196557.1501178732530
Content-Type: text/plain; charset="UTF-8"
On Thursday, July 27, 2017 at 1:58:20 PM UTC-4, Hyman Rosen wrote:
>
> On Thu, Jul 27, 2017 at 1:22 PM, Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>>
>> > FYI, no, if the buffer did get reallocated then this "check" would have
>> > undefined behavior.
>>
>> This is, again, incorrect, so you might as well all stop repeating that
>> claim.
>
>
> It was undefined behavior in C++03. There are still plenty of people
> using C++03 compilers (my own large employer included).
>
Sure, but we're talking about an extension to the existing standard. And
that existing standard is C++14, soon to be replaced by C++17.
We can't make proposals relative to the behavior of C++03. So its behavior
is rather irrelevant to this issue.
> Now it's not undefined but it can cause a "system-generated runtime
> fault". That sounds like a distinction without a difference.
>
Oh, there's a distinction. Implementation-defined means that you can pick
implementations which define it not to do things like cause faults.
--
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/e3265991-b2e9-44f3-8da9-69ba77aee773%40isocpp.org.
------=_Part_985_1605196557.1501178732530
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 27, 2017 at 1:58:20 PM UTC-4, Hy=
man Rosen 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"lt=
r"><div><div class=3D"gmail_quote">On Thu, Jul 27, 2017 at 1:22 PM, Ville V=
outilainen <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"F93MRD7EAAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">ville.vo...@gmail.com</a>></span> wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span>
> FYI, no, if the buffer did get reallocated then this "check"=
would have<br>
> undefined behavior.<br>
<br>
</span>This is, again, incorrect, so you might as well all stop repeating t=
hat claim.</blockquote><div><br>It was undefined behavior in C++03.=C2=A0 T=
here are still plenty of people using C++03 compilers (my own large employe=
r included).<br></div></div></div></div></blockquote><div><br>Sure, but we&=
#39;re talking about an extension to the existing standard. And that existi=
ng standard is C++14, soon to be replaced by C++17.<br><br>We can't mak=
e proposals relative to the behavior of C++03. So its behavior is rather ir=
relevant to this issue.<br>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Now it's=
not undefined but it can cause a "system-generated runtime fault"=
;.=C2=A0 That sounds like a distinction without a difference.</div></div></=
div></div></blockquote><div><br>Oh, there's a distinction. Implementati=
on-defined means that you can pick implementations which define it not to d=
o things like cause faults.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e3265991-b2e9-44f3-8da9-69ba77aee773%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3265991-b2e9-44f3-8da9-69ba77aee773=
%40isocpp.org</a>.<br />
------=_Part_985_1605196557.1501178732530--
------=_Part_984_7494005.1501178732530--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 11:17:06 -0700
Raw View
On Thursday, 27 July 2017 09:41:34 PDT Nicol Bolas wrote:
> No, it has not. The lifetime of an object cannot be started until the
> object has been created, and an object is only created through the means
> defined in [intro.object]/1. And writing to a piece of memory is not listed
> there.
>
> "Vacuous initialization" is not a free pass from object creation. It just
> means that the object doesn't have to be initialized; it still has to be
> *created*.
You're probably right for the strict interpretation, but we've had this
discussion before.
There's nothing preventing malloc from doing new (ptr) char; on the bytes that
compose the buffer it returned before it returned it. So the compiler has to
assume that objects may have been created there if you try to read or write to
it.
It can do DSE if it sees you do new, in which case it knows that whatever was
there was a dead store.
Also, in that discussion, we mostly tended towards saying that all trivial
types should be assumed to have begun lifetime before now and will end later,
so as to support shared memory mechanisms, sockets, object allocation by C
libraries, and a number of other things that don't actually call "new" but do
imply there's an object there. But there has been no paper on the subject and
I don't think we reached a consensus -- only a trend.
--
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/2707247.Vk7MbZgZM3%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 21:17:50 +0300
Raw View
On 27 July 2017 at 20:57, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 27, 2017 at 1:22 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> > FYI, no, if the buffer did get reallocated then this "check" would have
>> > undefined behavior.
>>
>> This is, again, incorrect, so you might as well all stop repeating that
>> claim.
>
>
> It was undefined behavior in C++03. There are still plenty of people using
> C++03 compilers (my own large employer included).
> Now it's not undefined but it can cause a "system-generated runtime fault".
> That sounds like a distinction without a difference.
Well, now that you mentioned your employer, I hear you have a rather
more interesting mixture
of operating systems, compilers, and hardware than many of us. Does
reading an invalid pointer
cause such a fault on any systems that you have?
--
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/CAFk2RUaBRMijGKn%2BTnj4ww2fBitxFEVBoAyW5yK9PV4fGixU5w%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 11:18:11 -0700
Raw View
On Thursday, 27 July 2017 10:18:44 PDT Howard Hinnant wrote:
> If Herb=E2=80=99s spaceship operator gets passed, you would be able to co=
mpare the
> pointers using that.
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r1.pdf) If
> for no other reason than a total ordering among pointers, we should pass
> P0515.
How does that work around the part of the text that Ville posted?
"Any other use of an invalid pointer value has implementation-defined=20
behavior."
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1669663.sefOoUbUt6%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 21:19:46 +0300
Raw View
On 27 July 2017 at 21:17, Thiago Macieira <thiago@macieira.org> wrote:
> Also, in that discussion, we mostly tended towards saying that all trivial
> types should be assumed to have begun lifetime before now and will end later,
> so as to support shared memory mechanisms, sockets, object allocation by C
> libraries, and a number of other things that don't actually call "new" but do
> imply there's an object there. But there has been no paper on the subject and
> I don't think we reached a consensus -- only a trend.
*ahem* http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0593r0.html
--
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/CAFk2RUYX_NF2Wn-8M2oCTgJgcb4MMPbw92ErZj9xux69vGjFzQ%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 11:20:34 -0700
Raw View
On Thursday, 27 July 2017 10:43:40 PDT Nicol Bolas wrote:
> > Bitwise comparison success is not necessary for equality. Now think of
> > real-
> > mode x86, where you have 32 bits in a FAR pointer, but only 20 of which
> > determine the actual address in the low megabyte of RAM.
> >
> > I'm not sure we can even say bitwise comparison success is sufficient: is
> > it
> > possible that two pointers are bitwise equal but not really equal?
>
> That's essentially irrelevant for this question because you *cannot* use
> pointer equality as a test to see if reallocation happened.
>
> As I pointed out in one of my replies, if two reallocations happened, it is
> possible that the second new pointer is the same as the old one. Or if you
> reallocate and then move a new vector into it, they might be the same.
Sounds like a variant of the ABA problem. But the ABA problem is usually about
threads, where testing for pointer equality to assume nothing has happened.
Usually, for the result of realloc() we're interested in whether *relocation*
happened, not just reallocation. In the case of the OP: if the base pointer
addresses differ, fixups to the absolute addresses stored in the vector are
needed.
--
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/2987916.gpHRvarF7U%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 11:24:08 -0700
Raw View
On Thursday, 27 July 2017 10:58:12 PDT Patrice Roy wrote:
> @Arthur : I understand what you mean; still, if it's common practice,
> however misguided language-wise, it might deserve some scrutiny, including
> clear exposure of the expected use-cases and alternative strategies. It
> would require someone caring enough about the issue to put something down
> in writing, obviously (I don't, but I'd be willing to read such a paper, to
> better grasp the perspective of such a proposer).
This will go back to the case of needing a replacement for the C library
realloc(), which we've had over and over and it doesn't seem WG14 is that
interested in helping us out.
--
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/1774589.SZ3imgmiND%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 21:26:54 +0300
Raw View
On 27 July 2017 at 21:24, Thiago Macieira <thiago@macieira.org> wrote:
> On Thursday, 27 July 2017 10:58:12 PDT Patrice Roy wrote:
>> @Arthur : I understand what you mean; still, if it's common practice,
>> however misguided language-wise, it might deserve some scrutiny, including
>> clear exposure of the expected use-cases and alternative strategies. It
>> would require someone caring enough about the issue to put something down
>> in writing, obviously (I don't, but I'd be willing to read such a paper, to
>> better grasp the perspective of such a proposer).
>
> This will go back to the case of needing a replacement for the C library
> realloc(), which we've had over and over and it doesn't seem WG14 is that
> interested in helping us out.
Has anyone proposed such a thing in WG14?
--
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/CAFk2RUZH9PMf6w2D6W-QJRfXNJFvh9KH2%3DOLtoNWJSOgqA_jhg%40mail.gmail.com.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 27 Jul 2017 15:07:58 -0400
Raw View
--001a11408d309ef36305555149ae
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 2:17 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> Does reading an invalid pointer cause such a fault on any systems that you
> have?
No. I don't think anyone has had systems like that since the 80286 went
away (and maybe also the late unlamented Intel 432).
Something just came up here at the office that's probably related - it's
undefined behavior to do std::memset(nullptr, 'a', 0) and similarly for the
other mem... and str... functions. If I had to guess, I would say it's
because compilers can translate those calls into fairly direct Intel x86
instruction sequences, but this involves loading the pointers into
registers that back in the day would have caused a "system-generated
runtime fault" if they were null.
--
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/CAHSYqdbXiadiQS6jO1RtjWvHR%3DJcqeyNZt-H-E501750sWPpBg%40mail.gmail.com.
--001a11408d309ef36305555149ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 27, 2017 at 2:17 PM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does readin=
g an invalid pointer cause such a fault on any systems that you have?</bloc=
kquote><div><br>No.=C2=A0 I don't think anyone has had systems like tha=
t since the 80286 went away (and maybe also the late unlamented Intel 432).=
<br><br>Something just came up here at the office that's probably relat=
ed - it's undefined behavior to do <font face=3D"monospace, monospace">=
std::memset(nullptr, 'a', 0)</font> and similarly for the other mem=
.... and str... functions.=C2=A0 If I had to guess, I would say it's bec=
ause compilers can translate those calls into fairly direct Intel x86 instr=
uction sequences, but this involves loading the pointers into registers tha=
t back in the day would have caused a "system-generated runtime fault&=
quot; if they were null.</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" 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/CAHSYqdbXiadiQS6jO1RtjWvHR%3DJcqeyNZt=
-H-E501750sWPpBg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbXiadiQS=
6jO1RtjWvHR%3DJcqeyNZt-H-E501750sWPpBg%40mail.gmail.com</a>.<br />
--001a11408d309ef36305555149ae--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 12:48:27 -0700
Raw View
On Thursday, 27 July 2017 11:26:54 PDT Ville Voutilainen wrote:
> > This will go back to the case of needing a replacement for the C librar=
y
> > realloc(), which we've had over and over and it doesn't seem WG14 is th=
at
> > interested in helping us out.
>=20
> Has anyone proposed such a thing in WG14?
Yes.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1085.htm
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/fTDoVNUrkJU/
aysn3o5KDwAJ
Howard wrote:
"I did not attend WG14 personally to present this paper. The feedback I go=
t=20
was that there was insufficient interest to move forward with it. I.e. no =
one=20
present was excited enough about it to do the hard work, and even I, the=20
author, wasn=E2=80=99t willing to shell out the vacation time and travel ex=
pense to=20
make it happen."
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/19103373.gciMVVbvxE%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 12:54:28 -0700
Raw View
On Thursday, 27 July 2017 11:19:46 PDT Ville Voutilainen wrote:
> On 27 July 2017 at 21:17, Thiago Macieira <thiago@macieira.org> wrote:
> > Also, in that discussion, we mostly tended towards saying that all trivial
> > types should be assumed to have begun lifetime before now and will end
> > later, so as to support shared memory mechanisms, sockets, object
> > allocation by C libraries, and a number of other things that don't
> > actually call "new" but do imply there's an object there. But there has
> > been no paper on the subject and I don't think we reached a consensus --
> > only a trend.
>
> *ahem* http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0593r0.html
Thanks for summarising it the discussion :-)
But we still have no papers proposing a solution. Doesn't look like
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0137r1.html addresses
this particular problem either.
--
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/14675647.0j1Wuxs9WX%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Jul 2017 23:02:51 +0300
Raw View
On 27 July 2017 at 22:54, Thiago Macieira <thiago@macieira.org> wrote:
> On Thursday, 27 July 2017 11:19:46 PDT Ville Voutilainen wrote:
>> On 27 July 2017 at 21:17, Thiago Macieira <thiago@macieira.org> wrote:
>> > Also, in that discussion, we mostly tended towards saying that all trivial
>> > types should be assumed to have begun lifetime before now and will end
>> > later, so as to support shared memory mechanisms, sockets, object
>> > allocation by C libraries, and a number of other things that don't
>> > actually call "new" but do imply there's an object there. But there has
>> > been no paper on the subject and I don't think we reached a consensus --
>> > only a trend.
>>
>> *ahem* http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0593r0.html
>
> Thanks for summarising it the discussion :-)
>
> But we still have no papers proposing a solution. Doesn't look like
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0137r1.html addresses
> this particular problem either.
We are going to get such a paper, Richard Smith has been tasked by
SG12 to write it.
I did not write P0593r0 to leave it up in the air, it's being followed
up after being discussed.
--
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/CAFk2RUa4wPRav__bTi8zjvm1n1vFOXXBL5yW3Pf1%2BWWkXwc0DA%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 27 Jul 2017 13:10:30 -0700
Raw View
On Thursday, 27 July 2017 12:07:58 PDT Hyman Rosen wrote:
> On Thu, Jul 27, 2017 at 2:17 PM, Ville Voutilainen <
>
> ville.voutilainen@gmail.com> wrote:
> > Does reading an invalid pointer cause such a fault on any systems that you
> > have?
>
> No. I don't think anyone has had systems like that since the 80286 went
> away (and maybe also the late unlamented Intel 432).
Technically speaking, the 80386 supported and all current x86 processors still
do segmented memory model, so long as they are in 16- or 32-bit mode. Only in
64-bit mode (long mode) is the flat memory model enforced, and even then we
still have the FS and GS registers that are in use, including new instructions
like RDFSBASE/RDGSBASE.
GCC 6 supports a "kind of" FAR pointer with the named address space feature,
see https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Named-Address-Spaces.html .
> Something just came up here at the office that's probably related - it's
> undefined behavior to do std::memset(nullptr, 'a', 0) and similarly for the
> other mem... and str... functions. If I had to guess, I would say it's
> because compilers can translate those calls into fairly direct Intel x86
> instruction sequences, but this involves loading the pointers into
> registers that back in the day would have caused a "system-generated
> runtime fault" if they were null.
Actually, that's not correct on both counts.
You can't memset at nullptr because the standard says you can't: we need a
specific address that is distinct from any valid object, so a pointer can be
known to be nullptr or not.
Whether the memory address corresponding to the bit pattern that nullptr
stores in a pointer is accessible or not, is orthogonal to the problem. This
was an issue a couple of years ago in the Linux kernel, when GCC began
assuming that dereferenced pointers weren't NULL, but an architecture required
writing there. Hence the -fno-delete-null-pointer-checks option.
As for x86, loading a segment selector with a value of 0 to 3 is always valid
and cannot produce a fault. From the SDM on the "MOV" instruction:
> A NULL segment selector (values 0000-0003) can be loaded into the DS, ES,
> FS, and GS registers without causing a protection exception. However, any
> subsequent attempt to reference a segment whose corresponding segment
> register is loaded with a NULL value causes a general protection exception
> (#GP) and no memory reference occurs.
--
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/7050969.XuY3tlu8zN%40tjmaciei-mobl1.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 27 Jul 2017 15:53:13 -0500
Raw View
--001a114a74ac3bef9a055552c31b
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 8:50 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> Suppose this was allowed:
>
> std::vector<char> v;
> v.reserve(1);
> v.data()[0] = 'a';
> v.resize(1);
> return v[0];
>
> What does this return?
>
> Note that resize() will do
> new (array[i]) T{};
>
No, it won't.
That would impose assignability on type T, which is not a requirement for
resize(). (The empty container is a degenerate case that will never call
assignment, but emptiness is in general a run-time decision, so the code
which calls assignment will still be compiled from the source, even if
optimized out).
And even if it were allowed, that would be very inefficient, especially for
types whose default construction is not cheap.
The requirements on single argument resize() are MoveInsertable (for
existing elements) and DefaultInsertable (when growing the container for
creating new elements). Both of those are intended to call constructors
via allocator_traits<A>::construct(...).
The line v.data()[0] = 'a'; is certainly intended to be library UB whether
or not you find a way to reason that it is not language UB.
So when you ask what does it return, well, the missiles are launched...
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNEZOFUF9aHU2zr6sxJy-Eouq6TrQ%2BHT0euvYzg5VEWuQ%40mail.gmail.com.
--001a114a74ac3bef9a055552c31b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Jul 26, 2017 at 8:50 PM, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex">Suppose this was allowed:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::vector<char> v;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v.reserve(1);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v.data()[0] =3D 'a';<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v.resize(1);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return v[0];<br>
<br>
What does this return?<br>
<br>
Note that resize() will do<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 new (array[i]) T{};<br></blockquote><div><br></=
div><div>No, it won't.</div><div><br></div><div>That would impose assig=
nability on type T, which is not a requirement for resize(). =C2=A0(The emp=
ty container is a degenerate case that will never call assignment, but empt=
iness is in general a run-time decision, so the code which calls assignment=
will still be compiled from the source, even if optimized out).</div><div>=
<br></div><div>And even if it were allowed, that would be very inefficient,=
especially for types whose default construction is not cheap.</div><div><b=
r></div><div>The requirements on single argument resize() are MoveInsertabl=
e (for existing elements) and DefaultInsertable (when growing the container=
for creating new elements).=C2=A0 Both of those are intended to call const=
ructors via allocator_traits<A>::construct(...).</div><div><br></div>=
<div><br></div><div>The line <font face=3D"monospace, monospace" size=3D"1"=
>v.data()[0] =3D 'a';</font> is certainly intended to be library UB=
whether or not you find a way to reason that it is not language UB.<br></d=
iv><div><br></div><div>So when you ask what does it return, well, the missi=
les are launched...</div></div>-- <br><div class=3D"gmail_signature"><div d=
ir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BNEZOFUF9aHU2zr6sxJy-Eouq6TrQ=
%2BHT0euvYzg5VEWuQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNEZO=
FUF9aHU2zr6sxJy-Eouq6TrQ%2BHT0euvYzg5VEWuQ%40mail.gmail.com</a>.<br />
--001a114a74ac3bef9a055552c31b--
.
Author: =?UTF-8?Q?Jos=C3=A9_Rodrigo?= <rodrigojose690@gmail.com>
Date: Thu, 27 Jul 2017 17:58:18 -0300
Raw View
--f403045fbb460aab5a055552d3d9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
module.exports =3D function ($scope, $document, $http, GameOptionsService) =
{
var targets =3D null;
$http.get('./../svg/age03_05_19_1_0.svg').then(function (response) {
var doc =3D $document[0].getElementById('main');
doc.innerHTML =3D response.data;
var res =3D GameOptionsService.filter(doc, viewAlterada, feedAberto,
callbackFinal);
});
var viewAlterada =3D (viewId) =3D> console.log(`View Alterada para ${viewId=
}`);
var feedAberto =3D (opcao) =3D> console.log("Feed " + (opcao? "certo" : "er=
rado")
+ " aberto");
var callbackFinal =3D () =3D> setTimeout(() =3D> console.log('Parabens vc
terminou as perguntas'))
};
2017-07-27 17:53 GMT-03:00 Nevin Liber <nevin@eviloverlord.com>:
> On Wed, Jul 26, 2017 at 8:50 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> Suppose this was allowed:
>>
>> std::vector<char> v;
>> v.reserve(1);
>> v.data()[0] =3D 'a';
>> v.resize(1);
>> return v[0];
>>
>> What does this return?
>>
>> Note that resize() will do
>> new (array[i]) T{};
>>
>
> No, it won't.
>
> That would impose assignability on type T, which is not a requirement for
> resize(). (The empty container is a degenerate case that will never call
> assignment, but emptiness is in general a run-time decision, so the code
> which calls assignment will still be compiled from the source, even if
> optimized out).
>
> And even if it were allowed, that would be very inefficient, especially
> for types whose default construction is not cheap.
>
> The requirements on single argument resize() are MoveInsertable (for
> existing elements) and DefaultInsertable (when growing the container for
> creating new elements). Both of those are intended to call constructors
> via allocator_traits<A>::construct(...).
>
>
> The line v.data()[0] =3D 'a'; is certainly intended to be library UB
> whether or not you find a way to reason that it is not language UB.
>
> So when you ask what does it return, well, the missiles are launched...
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
> <(847)%20691-1404>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAGg_6%2BNEZOFUF9aHU2zr6sxJy-
> Eouq6TrQ%2BHT0euvYzg5VEWuQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNE=
ZOFUF9aHU2zr6sxJy-Eouq6TrQ%2BHT0euvYzg5VEWuQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>
--=20
<https://about.me/rodrigojose690?promo=3Demail_sig&utm_source=3Dproduct&utm=
_medium=3Demail_sig&utm_campaign=3Dgmail_api&utm_content=3Dthumb>
Jos=C3=A9 Rodrigo
about.me/rodrigojose690
<https://about.me/rodrigojose690?promo=3Demail_sig&utm_source=3Dproduct&utm=
_medium=3Demail_sig&utm_campaign=3Dgmail_api&utm_content=3Dthumb>
--=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/CAJe%2Baq9HrGey72sojPvvMYTkC4yGx%2BR9LY5tu3TC%2B=
ZtTj0xxYA%40mail.gmail.com.
--f403045fbb460aab5a055552d3d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"color:rgb(212,212,212);background-color:rgb(=
30,30,30);font-family:"Courier New",monospace;font-size:14px;line=
-height:19px;white-space:pre"><div>module.exports =3D <span style=3D"color:=
rgb(86,156,214)">function</span> ($scope, $document, $http, GameOptionsServ=
ice) {</div><div> <span style=3D"color:rgb(86,156,214)">var</span> targe=
ts =3D <span style=3D"color:rgb(86,156,214)">null</span>;</div><br><div> =
$http.get(<span style=3D"color:rgb(206,145,120)">'./../svg/age03_05_19=
_1_0.svg'</span>).then(<span style=3D"color:rgb(86,156,214)">function</=
span> (response) {</div><div> <span style=3D"color:rgb(86,156,214)">=
var</span> doc =3D $document[<span style=3D"color:rgb(181,206,168)">0</span=
>].getElementById(<span style=3D"color:rgb(206,145,120)">'main'</sp=
an>);</div><div> doc.innerHTML =3D response.data;</div><br><div> =
<span style=3D"color:rgb(86,156,214)">var</span> res =3D GameOptionsSer=
vice.filter(doc, viewAlterada, feedAberto, callbackFinal);</div><div> })=
;</div><br><div> <span style=3D"color:rgb(86,156,214)">var</span> viewAl=
terada =3D (viewId) <span style=3D"color:rgb(86,156,214)">=3D></span> c=
onsole.log(<span style=3D"color:rgb(206,145,120)">`View Alterada para </spa=
n><span style=3D"color:rgb(86,156,214)">${</span><span style=3D"color:rgb(2=
06,145,120)">viewId</span><span style=3D"color:rgb(86,156,214)">}</span><sp=
an style=3D"color:rgb(206,145,120)">`</span>);</div><div> <span style=3D=
"color:rgb(86,156,214)">var</span> feedAberto =3D (opcao) <span style=3D"co=
lor:rgb(86,156,214)">=3D></span> console.log(<span style=3D"color:rgb(2=
06,145,120)">"Feed "</span> + (opcao? <span style=3D"color:rgb(20=
6,145,120)">"certo"</span> : <span style=3D"color:rgb(206,145,120=
)">"errado"</span>) + <span style=3D"color:rgb(206,145,120)">&quo=
t; aberto"</span>);</div><br><div> <span style=3D"color:rgb(86,156,=
214)">var</span> callbackFinal =3D () <span style=3D"color:rgb(86,156,214)"=
>=3D></span> setTimeout(() <span style=3D"color:rgb(86,156,214)">=3D>=
</span> console.log(<span style=3D"color:rgb(206,145,120)">'Parabens vc=
terminou as perguntas'</span>))</div><div>};</div></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-07-27 17:53 GMT-03:0=
0 Nevin Liber <span dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.co=
m" target=3D"_blank">nevin@eviloverlord.com</a>></span>:<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">On Wed, Jul 26, 2017 at 8:50 PM, Thiago=
Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" targ=
et=3D"_blank">thiago@macieira.org</a>></span> wrote:<br><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex">Suppose this was all=
owed:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::vector<char> v;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v.reserve(1);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v.data()[0] =3D 'a';<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v.resize(1);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return v[0];<br>
<br>
What does this return?<br>
<br>
Note that resize() will do<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 new (array[i]) T{};<br></blockquote><div><br></=
div><div>No, it won't.</div><div><br></div><div>That would impose assig=
nability on type T, which is not a requirement for resize(). =C2=A0(The emp=
ty container is a degenerate case that will never call assignment, but empt=
iness is in general a run-time decision, so the code which calls assignment=
will still be compiled from the source, even if optimized out).</div><div>=
<br></div><div>And even if it were allowed, that would be very inefficient,=
especially for types whose default construction is not cheap.</div><div><b=
r></div><div>The requirements on single argument resize() are MoveInsertabl=
e (for existing elements) and DefaultInsertable (when growing the container=
for creating new elements).=C2=A0 Both of those are intended to call const=
ructors via allocator_traits<A>::<wbr>construct(...).</div><div><br><=
/div><div><br></div><div>The line <font face=3D"monospace, monospace" size=
=3D"1">v.data()[0] =3D 'a';</font> is certainly intended to be libr=
ary UB whether or not you find a way to reason that it is not language UB.<=
br></div><div><br></div><div>So when you ask what does it return, well, the=
missiles are launched...</div></div><span class=3D"HOEnZb"><font color=3D"=
#888888">-- <br><div class=3D"m_-2263761855451952510gmail_signature"><div d=
ir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a><wbr>> =C2=A0<a href=3D"tel:(847)%20691-1404" =
value=3D"+18476911404" target=3D"_blank">+1-847-691-1404</a></div></div></d=
iv></div></div>
</font></span></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNEZOFUF9aHU2zr6sxJy-Eouq6TrQ=
%2BHT0euvYzg5VEWuQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAGg_6%<wbr>2BNEZOFUF9aHU2zr6sxJy-<wbr>Eouq6TrQ%2BHT0euv=
Yzg5VEWuQ%<wbr>40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><table =
border=3D"0" cellpadding=3D"0" cellspacing=3D"0">
<tbody>
<tr>
<td align=3D"left" valign=3D"bottom" width=3D"107" style=3D"lin=
e-height:0;vertical-align:bottom;padding-right:10px;padding-top:20px;paddin=
g-bottom:20px">
<a href=3D"https://about.me/rodrigojose690?promo=3Demail_si=
g&utm_source=3Dproduct&utm_medium=3Demail_sig&utm_campaign=3Dgm=
ail_api&utm_content=3Dthumb" style=3D"text-decoration:none" target=3D"_=
blank">
<img src=3D"https://thumbs.about.me/thumbnail/users/r/o=
/d/rodrigojose690_emailsig.jpg?_1495648931_109" alt=3D"" width=3D"105" heig=
ht=3D"70" style=3D"margin:0;padding:0;display:block;border:1px solid #eeeee=
e">
</a>
</td>
<td align=3D"left" valign=3D"bottom" style=3D"line-height:1.1;v=
ertical-align:bottom;padding-top:20px;padding-bottom:20px">
<img src=3D"https://about.me/t/sig?u=3Drodrigojose690" widt=
h=3D"1" height=3D"1" style=3D"border:0;margin:0;padding:0;width:1;height:1;=
overflow:hidden">
<div style=3D"font-size:18px;font-weight:bold;color:#333333=
;font-family:'Proxima Nova',Helvetica,Arial,sans-serif!important">J=
os=C3=A9 Rodrigo</div>
<a href=3D"https://about.me/rodrigojose690?promo=3Demail_si=
g&utm_source=3Dproduct&utm_medium=3Demail_sig&utm_campaign=3Dgm=
ail_api&utm_content=3Dthumb" style=3D"text-decoration:none;font-size:12=
px;color:#2b82ad;font-family:'Proxima Nova',Helvetica,Arial,sans-se=
rif!important" target=3D"_blank">about.me/rodrigojose690
</a>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJe%2Baq9HrGey72sojPvvMYTkC4yGx%2BR9=
LY5tu3TC%2BZtTj0xxYA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJe%2Baq9H=
rGey72sojPvvMYTkC4yGx%2BR9LY5tu3TC%2BZtTj0xxYA%40mail.gmail.com</a>.<br />
--f403045fbb460aab5a055552d3d9--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 27 Jul 2017 16:01:22 -0500
Raw View
--94eb2c190dc0630296055552e0e8
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 5:50 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> The point that's unclear is (oddly enough) whether "reallocation" is
> *just* about the behavior of iterators/references/pointers, or if it is
> also about actually allocating memory and all of the side-effects thereof
> which are not just iterators/references/pointers. The point is that the
> standard doesn't *explicitly* state that "no reallocation" means no
> allocating memory.
>
> That's clearly the intent, but I'm not sure if it's well-specified.
>
You have a class *that takes an Allocator as a parameter*, yet somehow you
rationalize that "reallocation" may have nothing to do with allocating
memory?
Unclear to random people on the Internet is not a defect in the Standard.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNCZjz8245CycVHM%3DvkHZS7f7twHVrCXJv2ND8Udtzgkw%40mail.gmail.com.
--94eb2c190dc0630296055552e0e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Jul 26, 2017 at 5:50 PM, Nicol Bolas <span dir=3D"=
ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br>The point that&=
#39;s unclear is (oddly enough) whether "reallocation" is <i>just=
</i> about the behavior of iterators/references/pointers, or if it is also =
about actually allocating memory and all of the side-effects thereof which =
are not just iterators/references/pointers. The point is that the standard =
doesn't <i>explicitly</i> state that "no reallocation" means =
no allocating memory.<br><br>That's clearly the intent, but I'm not=
sure if it's well-specified.<br></div></div></blockquote><div><br></di=
v><div>You have a class <i>that takes an Allocator as a parameter</i>, yet =
somehow you rationalize that "reallocation" may have nothing to d=
o with allocating memory?<br></div><div><br></div><div><div>Unclear to rand=
om people on the Internet is not a defect in the Standard.</div></div></div=
>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"lt=
r"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailt=
o:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =
=C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BNCZjz8245CycVHM%3DvkHZS7f7tw=
HVrCXJv2ND8Udtzgkw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNCZj=
z8245CycVHM%3DvkHZS7f7twHVrCXJv2ND8Udtzgkw%40mail.gmail.com</a>.<br />
--94eb2c190dc0630296055552e0e8--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 27 Jul 2017 17:21:29 -0500
Raw View
--001a11404b10e50e9c055553fe59
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 27, 2017 at 11:37 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> Bitwise comparison success is not necessary for equality. Now think of
> real-
> mode x86, where you have 32 bits in a FAR pointer, but only 20 of which
> determine the actual address in the low megabyte of RAM.
>
> I'm not sure we can even say bitwise comparison success is sufficient: is
> it
> possible that two pointers are bitwise equal but not really equal?
1. Get a copy of the standard library which works on that platform.
2. See what greater, less, greater_equal and less_equal do when
instantiated with either T* or void, as they must provide a total ordering;
look at the [comparisons] section of the standard for more details.
3. PROFIT!
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOwE8_7jYSNJy_%3Db68vhvBYmB1Bza940B88QfFMtVnTLw%40mail.gmail.com.
--001a11404b10e50e9c055553fe59
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jul 27, 2017 at 11:37 AM, Thiago Macieira <span di=
r=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thia=
go@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex">Bitwise comparison success is not nece=
ssary for equality. Now think of real-<br>
mode x86, where you have 32 bits in a FAR pointer, but only 20 of which<br>
determine the actual address in the low megabyte of RAM.<br>
<br>
I'm not sure we can even say bitwise comparison success is sufficient: =
is it<br>
possible that two pointers are bitwise equal but not really equal?</blockqu=
ote><div><ol><li>Get a copy of the standard library which works on that pla=
tform.</li><li>See what greater, less, greater_equal and less_equal do when=
instantiated with either T* or void, as they must provide a total ordering=
; look at the [comparisons] section of the standard for more details.</li><=
li>PROFIT!</li></ol></div></div>-- <br><div class=3D"gmail_signature"><div =
dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BOwE8_7jYSNJy_%3Db68vhvBYmB1B=
za940B88QfFMtVnTLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOwE8=
_7jYSNJy_%3Db68vhvBYmB1Bza940B88QfFMtVnTLw%40mail.gmail.com</a>.<br />
--001a11404b10e50e9c055553fe59--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 28 Jul 2017 00:07:05 +0100
Raw View
--001a1141042c98398b0555549f1d
Content-Type: text/plain; charset="UTF-8"
On 27 Jul 2017 17:37, "Thiago Macieira" <thiago@macieira.org> wrote:
On Thursday, 27 July 2017 09:29:20 PDT Hyman Rosen wrote:
> On Thu, Jul 27, 2017 at 12:16 PM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > Conclusion: you cannot portably determine if the old pointer is the same
> > as
> > the new one because you can't use the old pointer in the first place.
> > (But everyone does it)
>
> You could use memcmp to compare the pointers byte by byte.
Bitwise comparison success is not necessary for equality. Now think of real-
mode x86, where you have 32 bits in a FAR pointer, but only 20 of which
determine the actual address in the low megabyte of RAM.
I'm not sure we can even say bitwise comparison success is sufficient: is it
possible that two pointers are bitwise equal but not really equal?
As scalars, pointers are trivially copyable so are covered by
[basic.types]/3; that is, the bits in their value representation determine
their value (though not necessarily vice versa, as you've noted).
Inspecting or comparing that value may have unspecified or undefined
behavior, but that's a property of the value, not of the object holding the
value.
--
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/CAJnLdOZp8e35JEpt58kGfi20jK9Us%3DtWgocz%3DRL-au0dZAOE-A%40mail.gmail.com.
--001a1141042c98398b0555549f1d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 27 Jul 2017 17:37, "Thiago Macieira" <<a href=3D"=
mailto:thiago@macieira.org">thiago@macieira.org</a>> wrote:<br type=3D"a=
ttribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text">On Thursday=
, 27 July 2017 09:29:20 PDT Hyman Rosen wrote:<br>
> On Thu, Jul 27, 2017 at 12:16 PM, Thiago Macieira <<a href=3D"mailt=
o:thiago@macieira.org">thiago@macieira.org</a>><br>
><br>
> wrote:<br>
> > Conclusion: you cannot portably determine if the old pointer is t=
he same<br>
> > as<br>
> > the new one because you can't use the old pointer in the firs=
t place.<br>
> > (But everyone does it)<br>
><br>
> You could use memcmp to compare the pointers byte by byte.<br>
<br>
</div>Bitwise comparison success is not necessary for equality. Now think o=
f real-<br>
mode x86, where you have 32 bits in a FAR pointer, but only 20 of which<br>
determine the actual address in the low megabyte of RAM.<br>
<br>
I'm not sure we can even say bitwise comparison success is sufficient: =
is it<br>
possible that two pointers are bitwise equal but not really equal?<br>
<div class=3D"quoted-text"></div></blockquote></div></div></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">As scalars, pointers are trivially copya=
ble so are covered by [basic.types]/3; that is, the bits in their value rep=
resentation determine their value (though not necessarily vice versa, as yo=
u've noted).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">I=
nspecting or comparing that value may have unspecified or undefined behavio=
r, but that's a property of the value, not of the object holding the va=
lue.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cla=
ss=3D"quoted-text"><br></div></blockquote></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOZp8e35JEpt58kGfi20jK9Us%3DtWgo=
cz%3DRL-au0dZAOE-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZp8e35=
JEpt58kGfi20jK9Us%3DtWgocz%3DRL-au0dZAOE-A%40mail.gmail.com</a>.<br />
--001a1141042c98398b0555549f1d--
.
Author: Pedro Alves <pedro@palves.net>
Date: Mon, 7 Aug 2017 16:55:44 +0100
Raw View
On 07/27/2017 06:39 PM, Nicol Bolas wrote:
> I'm not sure what that's supposed to prove. Yes, if you write your own
> allocator, you can turn value initialization into default
> initialization. But:
>
> 1: This requires using your own allocator. So `vector`s provided by
> other APIs or whatever are non-workable with this.
> 2: It turns /all/ value initialization into default initialization. So
> it's no longer possible to value initialize elements at all.
For the latter, you simply v.resize() with an explicit value instead:
std::vector<char, DefaultAlloc<char>> v;
// v.resize(10); // default-init
v.resize(10, 0); // explicit value
for (char ch : v) {
printf("%d\n", ch);
}
Thanks,
Pedro Alves
--
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/fdbf2c8b-a86e-f3e6-4dde-ed63c66a0128%40palves.net.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 7 Aug 2017 10:35:10 -0700
Raw View
--f403045c1d6ed5dd4205562d44b5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-)" Liber wrote:
>>>
>>> On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <e...@catmur.co.uk>
>>> wrote:
>>>
>>>>
>>>> I see one possible change in behavior: currently it is permissible for
>>>> an implementation given a call to reserve() on an empty vector to defe=
r any
>>>> allocation to the first insert (and then allocate the full amount requ=
ired
>>>> by capacity()); this would no longer be possible (since data() is
>>>> noexcept).
>>>>
>>>
(We've established that the above is not actually permissible. However,
along the same lines...)
I think I might have found another loophole. It's related to the naive
(no-SSO) implementation of `std::string`.
There, we have
char *m_data =3D nullptr;
size_t m_size =3D 0;
size_t m_capacity =3D 0;
char *data() { return (m_data ? m_data : ""); }
because data() must return the same thing as c_str(), which must contain a
null terminator even when the string is in its empty, default-constructed
state. (In this state, our naive implementation does not allocate any
memory on default-construction.)
I *think* it would currently be conforming =E2=80=94 if sadistic =E2=80=94 =
to make this
char *data() { return (*m_size* ? m_data : ""); }
N4659 says that data() must return "A pointer p such that p + i =3D=3D
&operator[](i) for each i in [0, size()]." Notice the closing square
bracket there! Now, &operator[](size()) returns "a reference to an object
of type *[char]* with value *[zero]*, where modifying the object to any
value other than *[zero]* leads to undefined behavior." So this seems like
a conforming implementation.
Now we could do the same thing with std::vector.
T *data() { return (m_size ? m_data : nullptr); }
*Does* anyone do this? Of course not. *Should* anyone do this? Of course
not. But it would currently be conforming (I think), and if we changed
data() to always return the allocated buffer, then this sadistic
implementation would definitely no longer be conforming.
IMO this is still not a bad thing.
=E2=80=93Arthur
--=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/CADvuK0%2B55BP4aw-GTKatWjHuxxWgsnAyFhXxW1iRmhFgp=
mDyJg%40mail.gmail.com.
--f403045c1d6ed5dd4205562d44b5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur' =
via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr">On Wed, Jul 26, 2017 at 4:30 AM, Nicol=
Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><span class=3D"gmail-"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div dir=3D"ltr">On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin &qu=
ot;:-)" Liber wrote:<span><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Tue, Ju=
l 25, 2017 at 6:27 PM, Edward Catmur <span dir=3D"ltr"><<a rel=3D"nofoll=
ow">e...@catmur.co.uk</a>></span> wrote:<br><div><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr"><div><div><br><span style=3D"color:rg=
b(34,34,34)">I see one possible change in behavior: currently it is permiss=
ible for an implementation given a call to reserve() on an empty vector to =
defer any allocation to the first insert (and then allocate the full amount=
required by capacity()); this would no longer be possible (since data() is=
noexcept).=C2=A0</span></div></div></div></blockquote></div></div></div></=
blockquote></span></div></blockquote></span></div></div></div></blockquote>=
<div><br></div><div>(We've established that the above is not actually p=
ermissible. However, along the same lines...)</div><div><br></div><div>I th=
ink I might have found another loophole. It's related to the naive (no-=
SSO) implementation of `std::string`.</div><div>There, we have</div><div><b=
r></div><div>=C2=A0 =C2=A0 char *m_data =3D nullptr;</div><div>=C2=A0 =C2=
=A0 size_t m_size =3D 0;</div><div>=C2=A0 =C2=A0 size_t m_capacity =3D 0;</=
div><div><br></div><div>=C2=A0 =C2=A0 char *data() { return (m_data ? m_dat=
a : ""); }</div><div><br></div><div>because data() must return th=
e same thing as c_str(), which must contain a null terminator even when the=
string is in its empty, default-constructed state. (In this state, our nai=
ve implementation does not allocate any memory on default-construction.)</d=
iv><div><br></div><div>I <i>think</i> it would currently be conforming =E2=
=80=94 if sadistic =E2=80=94 to make this</div><div><br></div><div>=C2=A0 =
=C2=A0 char *data() { return (<b>m_size</b> ? m_data : ""); }</di=
v><div><br></div><div>N4659 says that data() must return "A pointer p =
such that p + i =3D=3D &operator[](i) for each i in [0, size()]." =
Notice the closing square bracket there! Now, &operator[](size()) retur=
ns=C2=A0"a reference to an object of type <i>[char]</i> with value <i>=
[zero]</i>, where modifying the object to any value other than <i>[zero]</i=
> leads to undefined behavior." So this seems like a conforming implem=
entation.</div><div><br></div><div>Now we could do the same thing with std:=
:vector.</div><div><br></div><div>=C2=A0 =C2=A0 T *data() { return (m_size =
? m_data : nullptr); }</div><div><br><i>Does</i> anyone do this? Of course =
not. <i>Should</i> anyone do this? Of course not. But it would currently be=
conforming (I think), and if we changed data() to always return the alloca=
ted buffer, then this sadistic implementation would definitely no longer be=
conforming.</div><div><br></div><div>IMO this is still not a bad thing.</d=
iv><div><br></div><div>=E2=80=93Arthur</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" 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/CADvuK0%2B55BP4aw-GTKatWjHuxxWgsnAyFh=
XxW1iRmhFgpmDyJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B55BP4=
aw-GTKatWjHuxxWgsnAyFhXxW1iRmhFgpmDyJg%40mail.gmail.com</a>.<br />
--f403045c1d6ed5dd4205562d44b5--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 8 Aug 2017 14:55:36 +0100
Raw View
--94eb2c05e44062662b05563e5157
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 7, 2017 at 6:35 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <jmckesson@gmail.com> wrote=
:
>>
>>> On Tuesday, July 25, 2017 at 10:59:34 PM UTC-4, Nevin ":-)" Liber wrote=
:
>>>>
>>>> On Tue, Jul 25, 2017 at 6:27 PM, Edward Catmur <e...@catmur.co.uk>
>>>> wrote:
>>>>
>>>>>
>>>>> I see one possible change in behavior: currently it is permissible fo=
r
>>>>> an implementation given a call to reserve() on an empty vector to def=
er any
>>>>> allocation to the first insert (and then allocate the full amount req=
uired
>>>>> by capacity()); this would no longer be possible (since data() is
>>>>> noexcept).
>>>>>
>>>>
> (We've established that the above is not actually permissible. However,
> along the same lines...)
>
On a natural reading of "reallocate", sure.
> I think I might have found another loophole. It's related to the naive
> (no-SSO) implementation of `std::string`.
> There, we have
>
> char *m_data =3D nullptr;
> size_t m_size =3D 0;
> size_t m_capacity =3D 0;
>
> char *data() { return (m_data ? m_data : ""); }
>
> because data() must return the same thing as c_str(), which must contain =
a
> null terminator even when the string is in its empty, default-constructed
> state. (In this state, our naive implementation does not allocate any
> memory on default-construction.)
>
> I *think* it would currently be conforming =E2=80=94 if sadistic =E2=80=
=94 to make this
>
> char *data() { return (*m_size* ? m_data : ""); }
>
> N4659 says that data() must return "A pointer p such that p + i =3D=3D
> &operator[](i) for each i in [0, size()]." Notice the closing square
> bracket there! Now, &operator[](size()) returns "a reference to an object
> of type *[char]* with value *[zero]*, where modifying the object to any
> value other than *[zero]* leads to undefined behavior." So this seems
> like a conforming implementation.
>
Note that (a) basic_string is a template, so "" will only have the correct
type for char instantiations, and (b) in any case string literals are not
writeable. In practice, non-SSO implementations will use a pointer to a
static data member of the value type - formerly const, now non-const. But
yes, this would be currently conforming.
> Now we could do the same thing with std::vector.
>
> T *data() { return (m_size ? m_data : nullptr); }
>
> *Does* anyone do this? Of course not. *Should* anyone do this? Of course
> not. But it would currently be conforming (I think), and if we changed
> data() to always return the allocated buffer, then this sadistic
> implementation would definitely no longer be conforming.
>
Well, actually. libstdc++ does this per the resolution to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59829 when vector is
instantiated with an allocator having an exotic pointer type. I doubt
Jonathan Wakeley's intention was to be sadistic, but you'll have to ask
them to be sure.
IMO this is still not a bad thing.
>
You say "sadistic", I say "generous in aiding early diagnosis of logic
errors". I'm in favor of this change in principle, though, mostly because
it's weird that data() shouldn't benefit from the stability guarantees
offered to other methods of access.
One thing puzzles me, though; OP claims that data() on an empty but
reserved vector "is sometimes optimized to return 0 by gcc". Unless they're
using an exotic allocator, I don't see how that would be the case. Maybe
they are?
--=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/CAJnLdOZCyPFpgEa8nZrG%2BVwjP8gUcwKJW4nW55nOJg_pJ=
koB-A%40mail.gmail.com.
--94eb2c05e44062662b05563e5157
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 7, 2017 at 6:35 PM, Arthur O'Dwyer <span dir=3D"ltr"><<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gm=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr">On Wed, Jul 26, 2017 at 10:19 AM, 'Edward Catm=
ur' via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a hr=
ef=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isoc=
pp.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">On Wed, Jul 26, 2017 at 4:30 AM, Nicol Bolas <span dir=3D"ltr"><<a hr=
ef=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>=
></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><span class=3D"gmail-m_6595740182413764451gmail-"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, July 25, 2017 at 10:=
59:34 PM UTC-4, Nevin ":-)" Liber wrote:<span><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tue, Jul 25, 2017 at 6=
:27 PM, Edward Catmur <span dir=3D"ltr"><<a rel=3D"nofollow">e...@catmur=
..co.uk</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><br><span=
style=3D"color:rgb(34,34,34)">I see one possible change in behavior: curre=
ntly it is permissible for an implementation given a call to reserve() on a=
n empty vector to defer any allocation to the first insert (and then alloca=
te the full amount required by capacity()); this would no longer be possibl=
e (since data() is noexcept).=C2=A0</span></div></div></div></blockquote></=
div></div></div></blockquote></span></div></blockquote></span></div></div><=
/div></blockquote><div><br></div><div>(We've established that the above=
is not actually permissible. However, along the same lines...)</div></div>=
</div></div></blockquote><div><br></div><div>On a natural reading of "=
reallocate", sure.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div></div><div>I think I might have found another loophol=
e. It's related to the naive (no-SSO) implementation of `std::string`.<=
/div><div>There, we have</div><div><br></div><div>=C2=A0 =C2=A0 char *m_dat=
a =3D nullptr;</div><div>=C2=A0 =C2=A0 size_t m_size =3D 0;</div><div>=C2=
=A0 =C2=A0 size_t m_capacity =3D 0;</div><div><br></div><div>=C2=A0 =C2=A0 =
char *data() { return (m_data ? m_data : ""); }</div><div><br></d=
iv><div>because data() must return the same thing as c_str(), which must co=
ntain a null terminator even when the string is in its empty, default-const=
ructed state. (In this state, our naive implementation does not allocate an=
y memory on default-construction.)</div><div><br></div><div>I <i>think</i> =
it would currently be conforming =E2=80=94 if sadistic =E2=80=94 to make th=
is</div><div><br></div><div>=C2=A0 =C2=A0 char *data() { return (<b>m_size<=
/b> ? m_data : ""); }</div><div><br></div><div>N4659 says that da=
ta() must return "A pointer p such that p + i =3D=3D &operator[](i=
) for each i in [0, size()]." Notice the closing square bracket there!=
Now, &operator[](size()) returns=C2=A0"a reference to an object o=
f type <i>[char]</i> with value <i>[zero]</i>, where modifying the object t=
o any value other than <i>[zero]</i> leads to undefined behavior." So =
this seems like a conforming implementation.</div></div></div></div></block=
quote><div>=C2=A0</div><div>Note that (a) basic_string is a template, so &q=
uot;" will only have the correct type for char instantiations, and (b)=
in any case string literals are not writeable. In practice, non-SSO implem=
entations will use a pointer to a static data member of the value type - fo=
rmerly const, now non-const. But yes, this would be currently conforming.<b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>Now we could do the same thing with std::vector.</div><div><br>=
</div><div>=C2=A0 =C2=A0 T *data() { return (m_size ? m_data : nullptr); }<=
/div><div><br><i>Does</i> anyone do this? Of course not. <i>Should</i> anyo=
ne do this? Of course not. But it would currently be conforming (I think), =
and if we changed data() to always return the allocated buffer, then this s=
adistic implementation would definitely no longer be conforming.</div></div=
></div></div></blockquote><div><br></div><div>Well, actually. libstdc++ doe=
s this per the resolution to=C2=A0<a href=3D"https://gcc.gnu.org/bugzilla/s=
how_bug.cgi?id=3D59829">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D5982=
9</a> when vector is instantiated with an allocator having an exotic pointe=
r type. I doubt Jonathan Wakeley's intention was to be sadistic, but yo=
u'll have to ask them to be sure.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div></div><div>IMO this is still not a bad th=
ing.</div></div></div></div></blockquote><div><br></div><div>You say "=
sadistic", I say "generous in aiding early diagnosis of logic err=
ors".=C2=A0I'm in favor of this change in principle, though, mostl=
y because it's weird that data() shouldn't benefit from the stabili=
ty guarantees offered to other methods of access.</div><div><br></div><div>=
One thing puzzles me, though; OP claims that data() on an empty but reserve=
d vector "<span style=3D"font-family:Arial,Helvetica,sans-serif;font-s=
ize:13px">is sometimes optimized to return 0 by gcc". Unless they'=
re using an exotic allocator, I don't see how that would be the case. M=
aybe they are?</span></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" 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/CAJnLdOZCyPFpgEa8nZrG%2BVwjP8gUcwKJW4=
nW55nOJg_pJkoB-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZCyPFpgE=
a8nZrG%2BVwjP8gUcwKJW4nW55nOJg_pJkoB-A%40mail.gmail.com</a>.<br />
--94eb2c05e44062662b05563e5157--
.
Author: olafvdspek@gmail.com
Date: Wed, 9 Aug 2017 02:43:39 -0700 (PDT)
Raw View
------=_Part_5265_401203751.1502271819870
Content-Type: multipart/alternative;
boundary="----=_Part_5266_259359962.1502271819870"
------=_Part_5266_259359962.1502271819870
Content-Type: text/plain; charset="UTF-8"
Op zaterdag 22 juli 2017 06:31:59 UTC+2 schreef stevem...@gmail.com:
>
>
>
> On Saturday, July 22, 2017 at 12:17:36 AM UTC-4, Thiago Macieira wrote:
>>
>> On Friday, 21 July 2017 19:40:25 PDT stevem...@gmail.com wrote:
>> > Sometimes when using vectors in low-level embedded land it is nice to
>> know
>> > where the underlying buffer of a vector is before any data exists in
>> the
>> > vector. As it stands it is not possible to do this, even if first
>> calling
>> > reserve.
>>
>> Call resize(), not reserve(). The reserve call may be ignored, if for any
>> reason the container does not wish to comply. So the moment you add your
>> instructions, the container could relocate.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>>
>
> The vector only reallocates if the capacity is < current size(). That's
> the whole point of me calling reserve first. Inserting, push_back, all safe
> as long as the capacity is there
>
Why don't you call resize()?
--
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/a536ad39-6f55-4ea5-a856-2bac3a2c5ff8%40isocpp.org.
------=_Part_5266_259359962.1502271819870
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Op zaterdag 22 juli 2017 06:31:59 UTC+2 schreef stevem...@=
gmail.com:<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"><br=
><br>On Saturday, July 22, 2017 at 12:17:36 AM UTC-4, Thiago Macieira wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">On Friday, 21 July 2017 19:40:25 P=
DT <a rel=3D"nofollow">stevem...@gmail.com</a> wrote:
<br>> Sometimes when using vectors in low-level embedded land it is nice=
to know
<br>> where the underlying buffer of a vector is before any data exists =
in the
<br>> vector. As it stands it is not possible to do this, even if first =
calling
<br>> reserve.
<br>
<br>Call resize(), not reserve(). The reserve call may be ignored, if for a=
ny=20
<br>reason the container does not wish to comply. So the moment you add you=
r=20
<br>instructions, the container could relocate.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br></blockquote><div><br></div><div>The vector only reallocates if the cap=
acity is < current size(). That's the whole point of me calling rese=
rve first. Inserting, push_back, all safe as long as the capacity is there<=
/div></div></blockquote><div><br></div><div>Why don't you call resize()=
? =C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a536ad39-6f55-4ea5-a856-2bac3a2c5ff8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a536ad39-6f55-4ea5-a856-2bac3a2c5ff8=
%40isocpp.org</a>.<br />
------=_Part_5266_259359962.1502271819870--
------=_Part_5265_401203751.1502271819870--
.
Author: the.ultimate.koala@gmail.com
Date: Fri, 25 Aug 2017 07:35:34 -0700 (PDT)
Raw View
------=_Part_2644_121269891.1503671734960
Content-Type: multipart/alternative;
boundary="----=_Part_2645_310263044.1503671734960"
------=_Part_2645_310263044.1503671734960
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le samedi 22 juillet 2017 04:40:25 UTC+2, stevem...@gmail.com a =C3=A9crit =
:
>
> Assume now that i want to use the vector to hold assembly instructions.=
=20
> Various instructions' encoding are relative to their location in memory, =
so=20
> in order to encode them properly one must know where they are about to li=
ve=20
> inside the vector. A naive user might try one of the following:
>
=20
I think I have read the whole thread, but there is something I failed to=20
locate in the messages. If an instruction, to be encoded, must know where=
=20
it will live, then why is the user, naive or not, using a vector-owner=20
buffer which may be relocated?
Why not a unique_ptr<unsigned short[]>, which will own the buffer, and a=20
view on it?
--=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/897ee8ec-85fd-46dc-b7c3-41893eb91e4c%40isocpp.or=
g.
------=_Part_2645_310263044.1503671734960
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le samedi 22 juillet 2017 04:40:25 UTC+2, stevem...@gmail.=
com a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>Assume now that i want to use the vector to hold assembly in=
structions. Various instructions' encoding are relative to their locati=
on in memory, so in order to encode them properly one must know where they =
are about to live inside the vector. A naive user might try one of the foll=
owing:</div></div></blockquote><div>=C2=A0<br>I think I have read the whole=
thread, but there is something I failed to locate in the messages. If an i=
nstruction, to be encoded, must know where it will live, then why is the us=
er, naive or not, using a vector-owner buffer which may be relocated?<br><b=
r>Why not a unique_ptr<unsigned short[]>, which will own the buffer, =
and a view on it?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/897ee8ec-85fd-46dc-b7c3-41893eb91e4c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/897ee8ec-85fd-46dc-b7c3-41893eb91e4c=
%40isocpp.org</a>.<br />
------=_Part_2645_310263044.1503671734960--
------=_Part_2644_121269891.1503671734960--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 25 Aug 2017 16:38:59 +0200
Raw View
2017-08-25 16:35 GMT+02:00 <the.ultimate.koala@gmail.com>:
> I think I have read the whole thread, but there is something I failed to
> locate in the messages. If an instruction, to be encoded, must know where it
> will live, then why is the user, naive or not, using a vector-owner buffer
> which may be relocated?
>
> Why not a unique_ptr<unsigned short[]>, which will own the buffer, and a
> view on it?
The downside is that you have to keep track of the size and capacity manually..
--
Olaf
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HNhgfX8QbbDWw7gTv6HejCzq9-1vw3i%2BE3rkdWByFOT%2BA%40mail.gmail.com.
.