Topic: Comment on N4416: Why not make
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 7 May 2015 13:04:53 -0700
Raw View
--047d7bb04b0ec5a8c50515836c90
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, May 7, 2015 at 10:05:50 AM UTC-7, Bo Persson wrote:
>
> On 2015-05-07 14:51, Nicol Bolas wrote:
> > On Thursday, May 7, 2015 at 3:39:19 AM UTC-4, Bengt Gustafsson wrote:
> >
> > As for the initial suggestion here, to make the new
> > reserve_initially function unnecessary by changing the behaviour of
> > reserve() this is not possible as it can't be instantiated for a
> > non-movable type, which was the reason to introdice the
> > reserve_initially() function in the first place, according to N4416=
..
(SFINAE allows you to instantiate a "limited reserve()" for non-moveable
elements which wouldn't move anything. But I have since realized that one
of my pet peeves about the STL is all the existing SFINAE tricks, so I
shouldn't be advocating for any more of them. Also, I've realized that the
intended use-case here is v.clear(); v.reserve_initially(n); =E2=80=94 it's=
not
that the vector has to be completely new, merely that you have to manually
empty it first, in cases where you can't assert it to be empty.)
> > At the same time, I don't see the need to mandate that
> > reserve_initially() does not allow reservation of additional
> > elements. The programmer obviously knows what the max limit is but
> > it does no harm (except maybe some lost memory) to allocate a bit
more.
> >
> > For some programmers "some lost memory" is significant harm.
> >
> > Besides consistency with the wording on the standard `reserve`, I don't
> > see anything to be gained from allowing implementations to allocate
> > extra elements. Remember: the whole point of `reserve_initially` is tha=
t
> > the user /cannot/ exceed the boundary. Since you're code will never go
> > beyond the element count you reserve, I see no reason why an
> > implementation would allocate more elements than the user asked.
>
> Possibly because the user asked for too few elements. :-)
>
> What should an implementation do with a vector<char> when a user asks
> for one element only? Should it be non-conforming to actually allocate 4
> or 8 bytes?
Yes, absolutely, 100 percent it should! If the user asks for exactly 1
element, the vector should not attempt to interfere with the user's
request, but instead simply relay that request to the allocator associated
with the vector. Now, the allocator (which actually knows about memory
alignment and so on) might well decide to malloc up 4 bytes instead of 1;
that's totally fine. The allocator is expected to concern itself with such
things. But there needs to be some way for the user to communicate a
specific request to his allocator, without interference, and without
completely abandoning std::vector.
This is also a good place to point out that std::vector<bool> is not
actually a special case in this respect. Any std::vector<bool> will need to
have the same m_size and m_capacity members as std::vector<T>; there's
nothing in the semantics that *requires* m_capacity to be a multiple of 8
(or 64, or 100). However, vector<bool> *is* a special case in one important
way: it is the only vector<T> that we intuitively expect to call allocate<U=
>
for any U not equal to T.
=E2=80=93Arthur
P.S. =E2=80=94 I would also love to see and/or write a proposal that forbid=
s
std::vector<T not equal to bool> to examine its allocator::rebind, just
because that keeps biting me every time I try to test anything involving
allocators. I keep inheriting from std::allocator and forgetting to
override rebind.)
http://melpon.org/wandbox/permlink/83azNz80bH1l8B73 (I feel great, my code
works fine with Clang)
http://melpon.org/wandbox/permlink/ZiPX2zMmqMdyjbkX (aw crap, my code
doesn't even get called with GCC)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7bb04b0ec5a8c50515836c90
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, May 7, 2015 at 10:05:50 AM UTC-7, Bo Persson =
wrote:<br>><br>> On 2015-05-07 14:51, Nicol Bolas wrote:<br>> >=
On Thursday, May 7, 2015 at 3:39:19 AM UTC-4, Bengt Gustafsson wrote:<br>&=
gt; ><br>> > =C2=A0 =C2=A0 As for the initial suggestion here, to =
make the new<br>> > =C2=A0 =C2=A0 reserve_initially function unnecess=
ary by changing the behaviour of<br>> > =C2=A0 =C2=A0 reserve() this =
is not possible as it can't be instantiated for a<br>> > =C2=A0 =
=C2=A0 non-movable type, which was the reason to introdice the<br>> >=
=C2=A0 =C2=A0 reserve_initially() function in the first place, according t=
o N4416.<br><br><br>(SFINAE allows you to instantiate a "limited reser=
ve()" for non-moveable elements which wouldn't move anything. But =
I have since realized that one of my pet peeves about the STL is all the ex=
isting SFINAE tricks, so I shouldn't be advocating for any more of them=
.. Also, I've realized that the intended use-case here is v.clear(); v.r=
eserve_initially(n); =E2=80=94 it's not that the vector has to be compl=
etely new, merely that you have to manually empty it first, in cases where =
you can't assert it to be empty.)<br>=C2=A0<br><br>> > =C2=A0 =C2=
=A0 At the same time, I don't see the need to mandate that<br>> >=
=C2=A0 =C2=A0 reserve_initially() does not allow reservation of additional=
<br>> > =C2=A0 =C2=A0 elements. The programmer obviously knows what t=
he max limit is but<br>> > =C2=A0 =C2=A0 it does no harm (except mayb=
e some lost memory) to allocate a bit more.<br>> ><br>> > For s=
ome programmers "some lost memory" is significant harm.<br>> &=
gt;<br>> > Besides consistency with the wording on the standard `rese=
rve`, I don't<br>> > see anything to be gained from allowing impl=
ementations to allocate<br>> > extra elements. Remember: the whole po=
int of `reserve_initially` is that<br>> > the user /cannot/ exceed th=
e boundary. Since you're code will never go<br>> > beyond the ele=
ment count you reserve, I see no reason why an<br>> > implementation =
would allocate more elements than the user asked.<br>><br>> Possibly =
because the user asked for too few elements. =C2=A0:-)<br>><br>> What=
should an implementation do with a vector<char> when a user asks<br>=
> for one element only? Should it be non-conforming to actually allocate=
4<br>> or 8 bytes?<br><br>Yes, absolutely, 100 percent it should!=C2=A0=
If the user asks for exactly 1 element, the <font face=3D"monospace, monos=
pace">vector</font> should not attempt to interfere with the user's req=
uest, but instead simply relay that request to the <font face=3D"monospace,=
monospace">allocator</font> associated with the <font face=3D"monospace, m=
onospace">vector</font>.=C2=A0 Now, the <font face=3D"monospace, monospace"=
>allocator</font> (which actually knows about memory alignment and so on) m=
ight well decide to malloc up 4 bytes instead of 1; that's totally fine=
.. The <font face=3D"monospace, monospace">allocator</font> is expected to c=
oncern itself with such things. But there needs to be some way for the user=
to communicate a specific request to his <font face=3D"monospace, monospac=
e">allocator</font>, without interference, and without completely abandonin=
g <font face=3D"monospace, monospace">std::vector</font>.<br><br>This is al=
so a good place to point out that <font face=3D"monospace, monospace">std::=
vector<bool></font> is not actually a special case in this respect. A=
ny=C2=A0<font face=3D"monospace, monospace">std::vector<bool></font> =
will need to have the same <font face=3D"monospace, monospace">m_size</font=
> and <font face=3D"monospace, monospace">m_capacity</font> members as <fon=
t face=3D"monospace, monospace">std::vector<T></font>; there's no=
thing in the semantics that <i>requires</i> <font face=3D"monospace, monosp=
ace">m_capacity</font> to be a multiple of 8 (or 64, or 100). However, <fon=
t face=3D"monospace, monospace">vector<bool></font> <i><b>is</b></i> =
a special case in one important way: it is the only <font face=3D"monospace=
, monospace">vector<T></font> that we intuitively expect to call=C2=
=A0<font face=3D"monospace, monospace">allocate<U></font> for any <fo=
nt face=3D"monospace, monospace">U</font> not equal to <font face=3D"monosp=
ace, monospace">T</font>.<br><br>=E2=80=93Arthur<div><br>P.S. =E2=80=94 I w=
ould also love to see and/or write a proposal that forbids <font face=3D"mo=
nospace, monospace">std::vector<T</font><font face=3D"arial, helvetica, =
sans-serif"> not equal to </font><font face=3D"monospace, monospace">bool&g=
t;</font> to examine its=C2=A0<font face=3D"monospace, monospace">allocator=
::rebind</font>, just because that keeps biting me every time I try to test=
anything involving allocators. I keep inheriting from <font face=3D"monosp=
ace, monospace">std::allocator</font> and forgetting to override <font face=
=3D"monospace, monospace">rebind</font>.)<div><a href=3D"http://melpon.org/=
wandbox/permlink/83azNz80bH1l8B73">http://melpon.org/wandbox/permlink/83azN=
z80bH1l8B73</a> (I feel great, my code works fine with Clang)</div><div><a =
href=3D"http://melpon.org/wandbox/permlink/ZiPX2zMmqMdyjbkX">http://melpon.=
org/wandbox/permlink/ZiPX2zMmqMdyjbkX</a> (aw crap, my code doesn't eve=
n get called with GCC)</div><div><br><div><br><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bb04b0ec5a8c50515836c90--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 7 May 2015 18:03:45 -0700 (PDT)
Raw View
------=_Part_1220_1591594999.1431047025146
Content-Type: multipart/alternative;
boundary="----=_Part_1221_880841161.1431047025146"
------=_Part_1221_880841161.1431047025146
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, May 7, 2015 at 4:04:55 PM UTC-4, Arthur O'Dwyer wrote:
> P.S. =E2=80=94 I would also love to see and/or write a proposal that forb=
ids=20
> std::vector<T not equal to bool> to examine its allocator::rebind, just=
=20
> because that keeps biting me every time I try to test anything involving=
=20
> allocators. I keep inheriting from std::allocator and forgetting to=20
> override rebind.)
> http://melpon.org/wandbox/permlink/83azNz80bH1l8B73 (I feel great, my=20
> code works fine with Clang)
> http://melpon.org/wandbox/permlink/ZiPX2zMmqMdyjbkX (aw crap, my code=20
> doesn't even get called with GCC)
>
We don't define the allocator model for specific containers; we define how=
=20
it works, period. How any individual container implementation uses it is up=
=20
to that implementation. allocator::rebind is part of the allocator=20
interface, and if an implementation chooses to use it, that's perfectly=20
fine.
The correct way to fix this is with a proper allocator concept. Then,=20
you'll get a compiler error if you try to use a=20
non-conforming-but-would-work-on-this-implementation allocator.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1221_880841161.1431047025146
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, May 7, 2015 at 4:04:55 PM UTC-4, Arth=
ur O'Dwyer wrote:<br><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>P.S. =E2=80=94 I would also love to see and/or write a propos=
al that forbids <font face=3D"monospace, monospace">std::vector<T</font>=
<font face=3D"arial, helvetica, sans-serif"> not equal to </font><font face=
=3D"monospace, monospace">bool></font> to examine its <font face=3D=
"monospace, monospace">allocator::rebind</font>, just because that keeps bi=
ting me every time I try to test anything involving allocators. I keep inhe=
riting from <font face=3D"monospace, monospace">std::allocator</font> and f=
orgetting to override <font face=3D"monospace, monospace">rebind</font>.)<d=
iv><a href=3D"http://melpon.org/wandbox/permlink/83azNz80bH1l8B73" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2F83azNz80bH1l8B73=
\46sa\75D\46sntz\0751\46usg\75AFQjCNFhgcE9fyGWX3PutWF7QviDzDFHNA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmel=
pon.org%2Fwandbox%2Fpermlink%2F83azNz80bH1l8B73\46sa\75D\46sntz\0751\46usg\=
75AFQjCNFhgcE9fyGWX3PutWF7QviDzDFHNA';return true;">http://melpon.org/wandb=
ox/<wbr>permlink/83azNz80bH1l8B73</a> (I feel great, my code works fine wit=
h Clang)</div><div><a href=3D"http://melpon.org/wandbox/permlink/ZiPX2zMmqM=
dyjbkX" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2FZi=
PX2zMmqMdyjbkX\46sa\75D\46sntz\0751\46usg\75AFQjCNHb3TxqjZUKuylxbnEGYI6wbJk=
G4A';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2FZiPX2zMmqMdyjbkX\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNHb3TxqjZUKuylxbnEGYI6wbJkG4A';return true;">http://me=
lpon.org/wandbox/<wbr>permlink/ZiPX2zMmqMdyjbkX</a> (aw crap, my code doesn=
't even get called with GCC)</div></div></div></blockquote><div><br>We don'=
t define the allocator model for specific containers; we define how it work=
s, period. How any individual container implementation uses it is up to tha=
t implementation. allocator::rebind is part of the allocator interface, and=
if an implementation chooses to use it, that's perfectly fine.<br><br>The =
correct way to fix this is with a proper allocator concept. Then, you'll ge=
t a compiler error if you try to use a non-conforming-but-would-work-on-thi=
s-implementation allocator.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1221_880841161.1431047025146--
------=_Part_1220_1591594999.1431047025146--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Fri, 8 May 2015 10:52:20 -0700
Raw View
--001a11c2365893e7d9051595b00f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, May 7, 2015 at 6:03 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, May 7, 2015 at 4:04:55 PM UTC-4, Arthur O'Dwyer wrote:
>
>> P.S. =E2=80=94 I would also love to see and/or write a proposal that for=
bids
>> std::vector<T not equal to bool> to examine its allocator::rebind, just
>> because that keeps biting me every time I try to test anything involving
>> allocators. I keep inheriting from std::allocator and forgetting to
>> override rebind.)
>> http://melpon.org/wandbox/permlink/83azNz80bH1l8B73 (I feel great, my
>> code works fine with Clang)
>> http://melpon.org/wandbox/permlink/ZiPX2zMmqMdyjbkX (aw crap, my code
>> doesn't even get called with GCC)
>>
>
> We don't define the allocator model for specific containers; we define ho=
w
> it works, period. How any individual container implementation uses it is =
up
> to that implementation. allocator::rebind is part of the allocator
> interface, and if an implementation chooses to use it, that's perfectly
> fine.
>
I see your rationale, but at the same time I disagree with it. I have a
piece of software that deals with vectors of SixteenByteRecords, and for
many parts of the codebase I don't need heap-allocation; I can get by with
allocating out of a large static array or even a 4K buffer preallocated on
the stack. It's easy to preallocate space for a bunch of SixteenByteRecords
(guaranteeing alignment and making sure that I can serve them up really
quickly simply by advancing a pointer into the buffer), and it's easy to
write an allocator that can allocate them. This is *not* a general-purpose
allocator; it's a speed optimization that is specialized to allocate
SixteenByteRecords only.
The problem is that some vendors' implementations of
std::vector<SixteenByteRecord> go out of their way to rebind and even to
allocate things that are *not* SixteenByteRecords, at which point all my
performance gains go out the window (on those specific vendors'
implementations). I can't blame the vendors, because they're operating
within the current spec for std::vector. The only recourse is to abandon
std::vector and replace all uses of it with MyVector (which is bit-for-bit
identical except for a few lines in reserve). This is the sort of problem
that standardization is meant to solve!
(You say "We don't define the allocator model for specific containers", but
of course the Standard *does* define the model; it just happens to leave it
a little bit too broad in the case of std::vector. I believe the wording
change to forbid vector from calling rebind would be a single additional
sentence.)
The correct way to fix this is with a proper allocator concept. Then,
> you'll get a compiler error if you try to use a
> non-conforming-but-would-work-on-this-implementation allocator.
>
> I'm looking forward to that. However, in addition to "Allocator", we also
need a "SpecializedAllocator" or "AlreadyBoundAllocator" concept
corresponding to the notion described above. Not all allocators *can* be
rebound arbitrarily... unless I'm missing out on some common idiom here.
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2365893e7d9051595b00f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, May 7, 2015 at 6:03 PM, Nicol Bolas <span dir=3D"l=
tr"><<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-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Thursda=
y, May 7, 2015 at 4:04:55 PM UTC-4, Arthur O'Dwyer wrote:<br><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>P.S. =E2=80=94 I would also love to see and/or=
write a proposal that forbids <font face=3D"monospace, monospace">std::vec=
tor<T</font><font face=3D"arial, helvetica, sans-serif"> not equal to </=
font><font face=3D"monospace, monospace">bool></font> to examine its=C2=
=A0<font face=3D"monospace, monospace">allocator::rebind</font>, just becau=
se that keeps biting me every time I try to test anything involving allocat=
ors. I keep inheriting from <font face=3D"monospace, monospace">std::alloca=
tor</font> and forgetting to override <font face=3D"monospace, monospace">r=
ebind</font>.)<div><a href=3D"http://melpon.org/wandbox/permlink/83azNz80bH=
1l8B73" rel=3D"nofollow" target=3D"_blank">http://melpon.org/wandbox/permli=
nk/83azNz80bH1l8B73</a> (I feel great, my code works fine with Clang)</div>=
<div><a href=3D"http://melpon.org/wandbox/permlink/ZiPX2zMmqMdyjbkX" rel=3D=
"nofollow" target=3D"_blank">http://melpon.org/wandbox/permlink/ZiPX2zMmqMd=
yjbkX</a> (aw crap, my code doesn't even get called with GCC)</div></di=
v></div></blockquote></span><div><br>We don't define the allocator mode=
l for specific containers; we define how it works, period. How any individu=
al container implementation uses it is up to that implementation. allocator=
::rebind is part of the allocator interface, and if an implementation choos=
es to use it, that's perfectly fine.<br></div></div></blockquote><div><=
br></div><div>I see your rationale, but at the same time I disagree with it=
..=C2=A0 I have a piece of software that deals with vectors of SixteenByteRe=
cords, and for many parts of the codebase I don't need heap-allocation;=
I can get by with allocating out of a large static array or even a 4K buff=
er preallocated on the stack. It's easy to preallocate space for a bunc=
h of SixteenByteRecords (guaranteeing alignment and making sure that I can =
serve them up really quickly simply by advancing a pointer into the buffer)=
, and it's easy to write an allocator that can allocate them.=C2=A0 Thi=
s is <i>not</i> a general-purpose allocator; it's a speed optimization =
that is specialized to allocate SixteenByteRecords only.</div><div><br></di=
v><div>The problem is that some vendors' implementations of <font face=
=3D"monospace, monospace">std::vector<SixteenByteRecord></font> go ou=
t of their way to rebind and even to allocate things that are <i><b>not</b>=
</i> SixteenByteRecords, at which point all my performance gains go out the=
window (on those specific vendors' implementations).=C2=A0 I can't=
blame the vendors, because they're operating within the current spec f=
or std::vector. The only recourse is to abandon <font face=3D"monospace, mo=
nospace">std::vector</font> and replace all uses of it with <font face=3D"m=
onospace, monospace">MyVector</font> (which is bit-for-bit identical except=
for a few lines in <font face=3D"monospace, monospace">reserve</font>).=C2=
=A0 This is the sort of problem that standardization is meant to solve!</di=
v><div><br></div><div>(You say "We don't define the allocator mode=
l for specific containers", but of course the Standard <i>does</i> def=
ine the model; it just happens to leave it a little bit too broad in the ca=
se of std::vector. I believe the wording change to forbid vector from calli=
ng rebind would be a single additional sentence.)</div><div><br></div><bloc=
kquote 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;paddin=
g-left:1ex"><div dir=3D"ltr"><div>The correct way to fix this is with a pro=
per allocator concept. Then, you'll get a compiler error if you try to =
use a non-conforming-but-would-work-on-this-implementation allocator.<br></=
div></div><div class=3D""><div class=3D"h5">
<p></p>
</div></div></blockquote><div>I'm looking forward to that. However, in =
addition to "Allocator", we also need a "SpecializedAllocato=
r" or "AlreadyBoundAllocator" concept corresponding to the n=
otion described above. Not all allocators <i>can</i> be rebound arbitrarily=
.... unless I'm missing out on some common idiom here.</div><div><br></d=
iv><div>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2365893e7d9051595b00f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 8 May 2015 15:24:49 -0700 (PDT)
Raw View
------=_Part_689_359479771.1431123890052
Content-Type: multipart/alternative;
boundary="----=_Part_690_905012186.1431123890052"
------=_Part_690_905012186.1431123890052
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, May 8, 2015 at 1:52:22 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Thu, May 7, 2015 at 6:03 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Thursday, May 7, 2015 at 4:04:55 PM UTC-4, Arthur O'Dwyer wrote:
>>
>>> P.S. =E2=80=94 I would also love to see and/or write a proposal that fo=
rbids=20
>>> std::vector<T not equal to bool> to examine its allocator::rebind, just=
=20
>>> because that keeps biting me every time I try to test anything involvin=
g=20
>>> allocators. I keep inheriting from std::allocator and forgetting to=20
>>> override rebind.)
>>> http://melpon.org/wandbox/permlink/83azNz80bH1l8B73 (I feel great, my=
=20
>>> code works fine with Clang)
>>> http://melpon.org/wandbox/permlink/ZiPX2zMmqMdyjbkX (aw crap, my code=
=20
>>> doesn't even get called with GCC)
>>>
>>
>> We don't define the allocator model for specific containers; we define=
=20
>> how it works, period. How any individual container implementation uses i=
t=20
>> is up to that implementation. allocator::rebind is part of the allocator=
=20
>> interface, and if an implementation chooses to use it, that's perfectly=
=20
>> fine.
>>
>
> I see your rationale, but at the same time I disagree with it. I have a=
=20
> piece of software that deals with vectors of SixteenByteRecords, and for=
=20
> many parts of the codebase I don't need heap-allocation; I can get by wit=
h=20
> allocating out of a large static array or even a 4K buffer preallocated o=
n=20
> the stack. It's easy to preallocate space for a bunch of SixteenByteRecor=
ds=20
> (guaranteeing alignment and making sure that I can serve them up really=
=20
> quickly simply by advancing a pointer into the buffer), and it's easy to=
=20
> write an allocator that can allocate them. This is *not* a=20
> general-purpose allocator; it's a speed optimization that is specialized =
to=20
> allocate SixteenByteRecords only.
>
> The problem is that some vendors' implementations of=20
> std::vector<SixteenByteRecord> go out of their way to rebind and even to=
=20
> allocate things that are *not* SixteenByteRecords, at which point all my=
=20
> performance gains go out the window (on those specific vendors'=20
> implementations). I can't blame the vendors, because they're operating=
=20
> within the current spec for std::vector. The only recourse is to abandon=
=20
> std::vector and replace all uses of it with MyVector (which is=20
> bit-for-bit identical except for a few lines in reserve). This is the=20
> sort of problem that standardization is meant to solve!
>
I don't see what the problem here is. Just because they didn't ask for the=
=20
exact type doesn't mean that they asked for more memory than you=20
pre-allocated. So give them a chunk of that pre-allocated memory (rounding=
=20
up to the nearest SixteenByteRecord).
I see no reason to abandon vector in this case.
=20
> (You say "We don't define the allocator model for specific containers",=
=20
> but of course the Standard *does* define the model; it just happens to=20
> leave it a little bit too broad in the case of std::vector. I believe the=
=20
> wording change to forbid vector from calling rebind would be a single=20
> additional sentence.)
>
When I said "for specific containers", that's what I meant. The allocator=
=20
model is what it is *equally for all containers*. Individual containers=20
don't decide what the model is on a case-by-case basis.
We should not have AllocatorForList, AllocatorForVector, AllocatorForDeque,=
=20
and so forth. We should have a single Allocator concept with explicit=20
requirements, which is used by *all containers*. And if a container doesn't=
=20
use certain elements of that allocator... too bad. You still have to=20
implement the whole thing.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_690_905012186.1431123890052
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, May 8, 2015 at 1:52:22 PM UTC-4, Arthur=
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 dir=3D"ltr=
">On Thu, May 7, 2015 at 6:03 PM, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ogqPiyXEpZgJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>></s=
pan> wrote:<br><div><div class=3D"gmail_quote"><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 dir=3D=
"ltr"><span>On Thursday, May 7, 2015 at 4:04:55 PM UTC-4, Arthur O'Dwyer wr=
ote:<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"><div>P.S. =E2=80=94 I would also =
love to see and/or write a proposal that forbids <font face=3D"monospace, m=
onospace">std::vector<T</font><font face=3D"arial, helvetica, sans-serif=
"> not equal to </font><font face=3D"monospace, monospace">bool></font> =
to examine its <font face=3D"monospace, monospace">allocator::rebind</=
font>, just because that keeps biting me every time I try to test anything =
involving allocators. I keep inheriting from <font face=3D"monospace, monos=
pace">std::allocator</font> and forgetting to override <font face=3D"monosp=
ace, monospace">rebind</font>.)<div><a href=3D"http://melpon.org/wandbox/pe=
rmlink/83azNz80bH1l8B73" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmelpon.org%2Fwandbo=
x%2Fpermlink%2F83azNz80bH1l8B73\46sa\75D\46sntz\0751\46usg\75AFQjCNFhgcE9fy=
GWX3PutWF7QviDzDFHNA';return true;" onclick=3D"this.href=3D'http://www.goog=
le.com/url?q\75http%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2F83azNz80bH1l8=
B73\46sa\75D\46sntz\0751\46usg\75AFQjCNFhgcE9fyGWX3PutWF7QviDzDFHNA';return=
true;">http://melpon.org/wandbox/<wbr>permlink/83azNz80bH1l8B73</a> (I fee=
l great, my code works fine with Clang)</div><div><a href=3D"http://melpon.=
org/wandbox/permlink/ZiPX2zMmqMdyjbkX" rel=3D"nofollow" target=3D"_blank" o=
nmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmelpo=
n.org%2Fwandbox%2Fpermlink%2FZiPX2zMmqMdyjbkX\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHb3TxqjZUKuylxbnEGYI6wbJkG4A';return true;" onclick=3D"this.href=3D'h=
ttp://www.google.com/url?q\75http%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2=
FZiPX2zMmqMdyjbkX\46sa\75D\46sntz\0751\46usg\75AFQjCNHb3TxqjZUKuylxbnEGYI6w=
bJkG4A';return true;">http://melpon.org/wandbox/<wbr>permlink/ZiPX2zMmqMdyj=
bkX</a> (aw crap, my code doesn't even get called with GCC)</div></div></di=
v></blockquote></span><div><br>We don't define the allocator model for spec=
ific containers; we define how it works, period. How any individual contain=
er implementation uses it is up to that implementation. allocator::rebind i=
s part of the allocator interface, and if an implementation chooses to use =
it, that's perfectly fine.<br></div></div></blockquote><div><br></div><div>=
I see your rationale, but at the same time I disagree with it. I have=
a piece of software that deals with vectors of SixteenByteRecords, and for=
many parts of the codebase I don't need heap-allocation; I can get by with=
allocating out of a large static array or even a 4K buffer preallocated on=
the stack. It's easy to preallocate space for a bunch of SixteenByteRecord=
s (guaranteeing alignment and making sure that I can serve them up really q=
uickly simply by advancing a pointer into the buffer), and it's easy to wri=
te an allocator that can allocate them. This is <i>not</i> a general-=
purpose allocator; it's a speed optimization that is specialized to allocat=
e SixteenByteRecords only.</div><div><br></div><div>The problem is that som=
e vendors' implementations of <font face=3D"monospace, monospace">std::vect=
or<SixteenByteRecord></font> go out of their way to rebind and even t=
o allocate things that are <i><b>not</b></i> SixteenByteRecords, at which p=
oint all my performance gains go out the window (on those specific vendors'=
implementations). I can't blame the vendors, because they're operati=
ng within the current spec for std::vector. The only recourse is to abandon=
<font face=3D"monospace, monospace">std::vector</font> and replace all use=
s of it with <font face=3D"monospace, monospace">MyVector</font> (which is =
bit-for-bit identical except for a few lines in <font face=3D"monospace, mo=
nospace">reserve</font>). This is the sort of problem that standardiz=
ation is meant to solve!</div></div></div></div></blockquote><div><br>I don=
't see what the problem here is. Just because they didn't ask for=20
the exact type doesn't mean that they asked for more memory than you=20
pre-allocated. So give them a chunk of that pre-allocated memory (rounding =
up to the nearest SixteenByteRecord).<br><br>I see no reason to abandon vec=
tor in this case.<br> <br></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 class=3D"gmail_quote"><div></div><div>(Yo=
u say "We don't define the allocator model for specific containers", but of=
course the Standard <i>does</i> define the model; it just happens to leave=
it a little bit too broad in the case of std::vector. I believe the wordin=
g change to forbid vector from calling rebind would be a single additional =
sentence.)</div></div></div></div></blockquote><div><br>When I said "for sp=
ecific containers", that's what I meant. The allocator model is what it is =
<i>equally for all containers</i>. Individual containers don't decide what =
the model is on a case-by-case basis.<br><br>We should not have AllocatorFo=
rList, AllocatorForVector, AllocatorForDeque, and so forth. We should have =
a single Allocator concept with explicit requirements, which is used by <i>=
all containers</i>. And if a container doesn't use certain elements of that=
allocator... too bad. You still have to implement the whole thing.</div></=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_690_905012186.1431123890052--
------=_Part_689_359479771.1431123890052--
.