Topic: C++ proposal to improve allocator interface
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Mon, 18 Jan 2016 18:08:58 -0200
Raw View
Hi,
I would like to ask for some feedback on a non-breaking proposal to
the C++ standard, that aims to reduce allocator complexity, support
realtime allocation and improve performance of node-based containers
through the addition
of overloads of the allocate and deallocate member functions. The PDF
can be found here.
https://github.com/mzimbres/rtcpp/blob/master/doc/proposal_allocator.pdf
A previous discussion on the subject can be found here [1].
Best regards,
Marcelo
[1] http://www.open-std.org/pipermail/embedded/2014-December/000335.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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 19 Jan 2016 09:43:49 +0800
Raw View
--Apple-Mail=_874A807E-4604-42EF-924F-7200AAB57AA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9319, at 4:08 AM, Marcelo Zimbres <mzimbres@gmai=
l.com> wrote:
>=20
> https://github.com/mzimbres/rtcpp/blob/master/doc/proposal_allocator.pdf =
<https://github.com/mzimbres/rtcpp/blob/master/doc/proposal_allocator.pdf>
I hope you don=E2=80=99t mind me summarizing: The proposal is to add an all=
ocate() method which is equivalent to allocate(1). The benefit is to bless =
allocators which avoid the complexity of variable-sized allocation blocks.
Why can=E2=80=99t such allocators simply return 1 from max_size()? This wou=
ld let array-based containers work up to an array size of 1, which should b=
e good enough for std::deque at least. Perhaps allocator_traits::max_size s=
hould be constexpr if a.max_size() is a constant expression. (Come to think=
of it, then deque<T,A> could detect this condition, and drop the MoveAssig=
nable requirement on T.)
Do allocators following the proposal have no allocate(size_type) overload a=
t all, or is it defined as deleted? That would break compatibility with all=
allocator-aware containers, which seems to level the balance with the fact=
that max_size currently tends to be ignored.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_874A807E-4604-42EF-924F-7200AAB57AA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=
=E2=80=9319, at 4:08 AM, Marcelo Zimbres <<a href=3D"mailto:mzimbres@gma=
il.com" class=3D"">mzimbres@gmail.com</a>> wrote:</div><div class=3D""><=
div class=3D""><br class=3D""><a href=3D"https://github.com/mzimbres/rtcpp/=
blob/master/doc/proposal_allocator.pdf" class=3D"">https://github.com/mzimb=
res/rtcpp/blob/master/doc/proposal_allocator.pdf</a><br class=3D""></div></=
div></blockquote><div><br class=3D""></div><div>I hope you don=E2=80=99t mi=
nd me summarizing: The proposal is to add an <font face=3D"Courier" class=
=3D"">allocate()</font> method which is equivalent to <font face=3D"Courier=
" class=3D"">allocate(1)</font>. The benefit is to bless allocators which a=
void the complexity of variable-sized allocation blocks.</div><div><br clas=
s=3D""></div><div>Why can=E2=80=99t such allocators simply return 1 from <f=
ont face=3D"Courier" class=3D"">max_size()</font>? This would let array-bas=
ed containers work up to an array size of 1, which should be good enough fo=
r <font face=3D"Courier" class=3D"">std::deque</font> at least. Perhaps <fo=
nt face=3D"Courier" class=3D"">allocator_traits::max_size</font> should be =
<font face=3D"Courier" class=3D"">constexpr</font> if <font face=3D"Co=
urier" class=3D"">a.max_size()</font> is a constant expression. (Come to th=
ink of it, then <font face=3D"Courier" class=3D"">deque<T,A></fo=
nt> could detect this condition, and drop the MoveAssignable requireme=
nt on <font face=3D"Courier" class=3D"">T</font>.)</div><div><br class=3D""=
></div><div>Do allocators following the proposal have no <font face=3D=
"Courier" class=3D"">allocate(size_type)</font> overload at all, or is it d=
efined as deleted? That would break compatibility with all allocator-aware =
containers, which seems to level the balance with the fact that <font face=
=3D"Courier" class=3D"">max_size</font> currently tends to be ignored.=
</div></div><br class=3D""></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_874A807E-4604-42EF-924F-7200AAB57AA5--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Tue, 19 Jan 2016 17:03:53 -0200
Raw View
2016-01-18 23:43 GMT-02:00 David Krauss <potswa@gmail.com>:
>
> I hope you don=E2=80=99t mind me summarizing: The proposal is to add an a=
llocate()
> method which is equivalent to allocate(1). The benefit is to bless
> allocators which avoid the complexity of variable-sized allocation blocks=
..
Shortly said, that's it, but this is not motivating enough, let me
also shortly explain with a use case, why the currently allocator
interface is not satisfactory, this may be missing in the draft.
Suppose the common situation where I want a linked list with,
say n =3D 20 elements somewhere in my code. I have two options
A) I simply use std::list<int>.
This is very undesirable for some reasons:
1) Nodes go on the heap. For only 20 elements I would be better
using the stack.
2) The node size is small (~20bytes), it does not make sense allocating
them individually on the heap. Fragmentation begin to play a role
if I have many lists (or bigger n)
3) Big overhead on the heap allocation: all the code inside malloc,
plus system calls and allocation strategies. (I only need 20bytes
of space for a node!)
All this is overkill for a simple list with a couple of elements
(for big n situation gets worser).
B) Use a custom allocator, something like:
std::array<char, 20 * node_size > buffer =3D {{}};
my_allocator alloc(buffer);
std::list<int, my_allocator<int>> l(alloc);
This is the ideal solution:
1) Nodes on the stack.
2) Buffer is as small as possible.
3) No allocation overhead: I only change some pointers.
This is however not possible in the current allocator interface
due to the fact that allocate(n) may be called with n !=3D 1 and
that means I have to add strategy to handle the many possible
values of n. The size of the buffer is not anymore clear. All the
added complexity is pointless. The proposal tries to "fix" this.
> Why can=E2=80=99t such allocators simply return 1 from max_size()? This w=
ould let
> array-based containers work up to an array size of 1, which should be goo=
d
> enough for std::deque at least. Perhaps allocator_traits::max_size should=
be
> constexpr if a.max_size() is a constant expression. (Come to think of it,
> then deque<T,A> could detect this condition, and drop the MoveAssignable
> requirement on T.)
Unordered containers usually need to rebind twice, once for node allocation
and once for array allocation. that means they would need allocate() and
allocate(size_type) as well. I cannot make max_size return 1 for this reaso=
n.
> Do allocators following the proposal have no allocate(size_type) overload=
at
> all, or is it defined as deleted? That would break compatibility with all
> allocator-aware containers, which seems to level the balance with the fac=
t
> that max_size currently tends to be ignored.
The allocators can provide both allocate() and allocate(size_type),
but if the typedef
use_node_allocation is defined to std::true_type, then the container should=
use
allocate() for its node allocations. The proposal is non-breaking.
Marcelo
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 Jan 2016 13:26:44 -0600
Raw View
--089e013a2268e5b91a0529b4db78
Content-Type: text/plain; charset=UTF-8
On 19 January 2016 at 13:03, Marcelo Zimbres <mzimbres@gmail.com> wrote:
>
> This is however not possible in the current allocator interface
> due to the fact that allocate(n) may be called with n != 1 and
> that means I have to add strategy to handle the many possible
> values of n.
No you don't. Just assert(n == 1) in your custom allocator. If someone
uses your custom allocator for something other than node based containers,
the assert will fire.
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e013a2268e5b91a0529b4db78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 19 January 2016 at 13:03, Marcelo Zimbres <span dir=3D"=
ltr"><<a href=3D"mailto:mzimbres@gmail.com" target=3D"_blank">mzimbres@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"><br>=C2=A0 =C2=A0 This is howev=
er not possible in the current allocator interface<br>
=C2=A0 =C2=A0 due to the fact that allocate(n) may be called with n !=3D 1 =
and<br>
=C2=A0 =C2=A0 that means I have to add strategy to handle the many possible=
<br>
=C2=A0 =C2=A0 values of n. </blockquote><div><br></div><div>No you don'=
t.=C2=A0 Just <font face=3D"monospace, monospace">assert(n =3D=3D 1)</font>=
in your custom allocator.=C2=A0 If someone uses your custom allocator for =
something other than node based containers, the assert will fire.</div></di=
v>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"l=
tr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mail=
to: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 />
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--089e013a2268e5b91a0529b4db78--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 19 Jan 2016 14:43:06 -0500
Raw View
On Jan 18, 2016, at 3:08 PM, Marcelo Zimbres <mzimbres@gmail.com> wrote:
>
> Hi,
>
> I would like to ask for some feedback on a non-breaking proposal to
> the C++ standard, that aims to reduce allocator complexity, support
> realtime allocation and improve performance of node-based containers
> through the addition
> of overloads of the allocate and deallocate member functions. The PDF
> can be found here.
>
> https://github.com/mzimbres/rtcpp/blob/master/doc/proposal_allocator.pdf
>
> A previous discussion on the subject can be found here [1].
>
> Best regards,
> Marcelo
>
> [1] http://www.open-std.org/pipermail/embedded/2014-December/000335.html
Just fyi, here is a link to past work in this area:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html
Howard
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 Jan 2016 13:42:44 -0600
Raw View
--047d7bd768a62a8f9c0529b515d4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 18 January 2016 at 19:43, David Krauss <potswa@gmail.com> wrote:
>
> On 2016=E2=80=9301=E2=80=9319, at 4:08 AM, Marcelo Zimbres <mzimbres@gmai=
l.com> wrote:
>
> https://github.com/mzimbres/rtcpp/blob/master/doc/proposal_allocator.pdf
>
>
> I hope you don=E2=80=99t mind me summarizing: The proposal is to add an a=
llocate()
> method which is equivalent to allocate(1). The benefit is to bless
> allocators which avoid the complexity of variable-sized allocation blocks=
..
>
> Why can=E2=80=99t such allocators simply return 1 from max_size()? This w=
ould let
> array-based containers work up to an array size of 1, which should be goo=
d
> enough for std::deque at least.
>
I have no idea what you are talking about with deque. deque is not a
node-based container. Could you elaborate?
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--047d7bd768a62a8f9c0529b515d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 18 January 2016 at 19:43, David Krauss <span dir=3D"ltr=
"><<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.co=
m</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><b=
r><div><blockquote type=3D"cite"><div>On 2016=E2=80=9301=E2=80=9319, at 4:0=
8 AM, Marcelo Zimbres <<a href=3D"mailto:mzimbres@gmail.com" target=3D"_=
blank">mzimbres@gmail.com</a>> wrote:</div><div><div><br><a href=3D"http=
s://github.com/mzimbres/rtcpp/blob/master/doc/proposal_allocator.pdf" targe=
t=3D"_blank">https://github.com/mzimbres/rtcpp/blob/master/doc/proposal_all=
ocator.pdf</a><br></div></div></blockquote><div><br></div><div>I hope you d=
on=E2=80=99t mind me summarizing: The proposal is to add an <font face=3D"C=
ourier">allocate()</font> method which is equivalent to <font face=3D"Couri=
er">allocate(1)</font>. The benefit is to bless allocators which avoid the =
complexity of variable-sized allocation blocks.</div><div><br></div><div>Wh=
y can=E2=80=99t such allocators simply return 1 from <font face=3D"Courier"=
>max_size()</font>? This would let array-based containers work up to an arr=
ay size of 1, which should be good enough for <font face=3D"Courier">std::d=
eque</font> at least. </div></div></div></blockquote><div><br></div><div>I =
have no idea what you are talking about with deque. =C2=A0deque is not a no=
de-based container.=C2=A0 Could you elaborate?</div></div>-- <br><div><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<a href=3D"tel:%2B1-847-691-1404" valu=
e=3D"+18476911404" target=3D"_blank">+1-847-691-1404</a></div></div></div><=
/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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7bd768a62a8f9c0529b515d4--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Tue, 19 Jan 2016 17:47:40 -0200
Raw View
2016-01-19 17:26 GMT-02:00 Nevin Liber <nevin@eviloverlord.com>:
>
> No you don't. Just assert(n == 1) in your custom allocator. If someone
> uses your custom allocator for something other than node based containers,
> the assert will fire.
What should I do when the condition n =! 1 is triggered with the client?
If the condition n != 1 holds for a given STL implementation than I either
give up on the custom allocator or add the allocation strategy anyway
(which may be rather complex by the way).
I am aiming for a simple (and efficient) solution, for a simple problem.
Marcelo
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 Jan 2016 13:54:24 -0600
Raw View
--001a11409fc2d995230529b53ec4
Content-Type: text/plain; charset=UTF-8
On 19 January 2016 at 13:47, Marcelo Zimbres <mzimbres@gmail.com> wrote:
> 2016-01-19 17:26 GMT-02:00 Nevin Liber <nevin@eviloverlord.com>:
> >
> > No you don't. Just assert(n == 1) in your custom allocator. If someone
> > uses your custom allocator for something other than node based
> containers,
> > the assert will fire.
>
> What should I do when the condition n =! 1 is triggered with the client?
>
1. Abort. They violated the contract that your allocator should only be
used with node-based containers.
2. Fall back to a different allocator, such as std::allocator. (This may
allow you to use your allocator with almost-node-based containers such as
std::deque; maybe that is what David Krauss was alluding to?)
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11409fc2d995230529b53ec4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 19 January 2016 at 13:47, Marcelo Zimbres <span dir=3D"=
ltr"><<a href=3D"mailto:mzimbres@gmail.com" target=3D"_blank">mzimbres@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"><span class=3D"">2016-01-19 17:=
26 GMT-02:00 Nevin Liber <<a href=3D"mailto:nevin@eviloverlord.com">nevi=
n@eviloverlord.com</a>>:<br>
><br>
> No you don't.=C2=A0 Just assert(n =3D=3D 1) in your custom allocat=
or.=C2=A0 If someone<br>
> uses your custom allocator for something other than node based contain=
ers,<br>
> the assert will fire.<br>
<br>
</span>What should I do when the condition n =3D! 1 is triggered with the c=
lient?<br></blockquote><div><br></div><div>1.=C2=A0 Abort.=C2=A0 They viola=
ted the contract that your allocator should only be used with node-based co=
ntainers.</div><div><br></div><div>2.=C2=A0 Fall back to a different alloca=
tor, such as std::allocator. =C2=A0(This may allow you to use your allocato=
r with almost-node-based containers such as std::deque; maybe that is what =
David Krauss was alluding to?)</div></div>-- <br><div class=3D"gmail_signat=
ure"><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 />
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11409fc2d995230529b53ec4--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Tue, 19 Jan 2016 18:25:39 -0200
Raw View
2016-01-19 17:54 GMT-02:00 Nevin Liber <nevin@eviloverlord.com>:
>
> 1. Abort. They violated the contract that your allocator should only be
> used with node-based containers.
Node-based containers can themselves use n != 1. There is no guarantee
for n == 1 in standard, even for node-based containers.
> 2. Fall back to a different allocator, such as std::allocator. (This may
> allow you to use your allocator with almost-node-based containers such as
> std::deque; maybe that is what David Krauss was alluding to?)
Fall back to std::allocator is undesirable in this simple case for
reasons mentioned
above, specially if I a doing embedded C++. A simple solution should
not require me to
allocate on the heap at all.
There is also the annoying possibility that a node-based container
uses n =! 1 far too often to avoid the overhead of many dynamic
allocations of small blocks (Allocation strategy being built on the container
itself).
Marcelo
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 Jan 2016 14:58:33 -0600
Raw View
--047d7bd768a646e1d90529b62432
Content-Type: text/plain; charset=UTF-8
On 19 January 2016 at 14:25, Marcelo Zimbres <mzimbres@gmail.com> wrote:
> 2016-01-19 17:54 GMT-02:00 Nevin Liber <nevin@eviloverlord.com>:
> >
> > 1. Abort. They violated the contract that your allocator should only be
> > used with node-based containers.
>
> Node-based containers can themselves use n != 1. There is no guarantee
> for n == 1 in standard, even for node-based containers.
>
IMO that is what we should address. It makes no sense (and can be a
pessimization) for both the container and allocator to be managing space
for nodes, especially since the allocator interface doesn't really give a
way for a container and allocator to negotiate space requests.
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd768a646e1d90529b62432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 19 January 2016 at 14:25, Marcelo Zimbres <span dir=3D"=
ltr"><<a href=3D"mailto:mzimbres@gmail.com" target=3D"_blank">mzimbres@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"><span class=3D"">2016-01-19 17:=
54 GMT-02:00 Nevin Liber <<a href=3D"mailto:nevin@eviloverlord.com">nevi=
n@eviloverlord.com</a>>:<br>
><br>
> 1.=C2=A0 Abort.=C2=A0 They violated the contract that your allocator s=
hould only be<br>
> used with node-based containers.<br>
<br>
</span>Node-based containers can themselves use n !=3D 1. There is no guara=
ntee<br>
for n =3D=3D 1 in standard, even for node-based containers.<br></blockquote=
><div><br></div><div>IMO that is what we should address.=C2=A0 It makes no =
sense (and can be a pessimization) for both the container and allocator to =
be managing space for nodes, especially since the allocator interface doesn=
't really give a way for a container and allocator to negotiate space r=
equests.</div><div>--=C2=A0<br></div></div><div class=3D"gmail_signature"><=
div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Libe=
r=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bla=
nk">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div><=
/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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7bd768a646e1d90529b62432--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 20 Jan 2016 14:13:43 +0800
Raw View
--Apple-Mail=_EEF1E789-F0E8-4100-804E-8FA433007EF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9320, at 3:03 AM, Marcelo Zimbres <mzimbres@gmai=
l.com> wrote:
>=20
> Unordered containers usually need to rebind twice, once for node allocati=
on
> and once for array allocation. that means they would need allocate() and
> allocate(size_type) as well. I cannot make max_size return 1 for this rea=
son.
In that case, the problem is much different: The template is implementing t=
wo completely different (and incompatible) allocators. One rebind produces =
a node allocator and one produces an array allocator. They can=E2=80=99t be=
distinguished by the n =3D=3D 1 test.
Reviewing the Allocator requirements, I don=E2=80=99t see why it shouldn=E2=
=80=99t work to simply implement the allocators separately. Converting a gi=
ven allocator between node mode and array mode requires preserving the stat=
e of both, but any given object is only in one mode. Only node mode max_siz=
e returns 1.
Taking a quick look at the libc++ and libstdc++ implementations, they alloc=
ate individual nodes and arrays of pointers. So you can implement array mod=
e as a partial specialization of the allocator template on pointer types.
The proposal certainly doesn=E2=80=99t clarify the two-in-one nature, parti=
cularly that the result of allocate(1) couldn=E2=80=99t be passed to deallo=
cate().
>> Do allocators following the proposal have no allocate(size_type) overloa=
d at
>> all, or is it defined as deleted? That would break compatibility with al=
l
>> allocator-aware containers, which seems to level the balance with the fa=
ct
>> that max_size currently tends to be ignored.
>=20
> The allocators can provide both allocate() and allocate(size_type),
> but if the typedef
> use_node_allocation is defined to std::true_type, then the container shou=
ld use
> allocate() for its node allocations. The proposal is non-breaking.
The task is to eliminate allocate(size_type), so it=E2=80=99s begging the q=
uestion to say they can provide it.
The proposal does introduce allocators without a well-behaved allocate(size=
_type), no? Though it=E2=80=99s technically non-breaking, these allocators =
would be incompatible with all existing containers. The max_size approach a=
voids incompatibilities.
In any case, the proposal needs to define requirements for [de]allocate(siz=
e_type) in the case that allocate() is defined.
> On 2016=E2=80=9301=E2=80=9320, at 4:25 AM, Marcelo Zimbres <mzimbres@gmai=
l.com> wrote:
>=20
> Node-based containers can themselves use n !=3D 1. There is no guarantee
> for n =3D=3D 1 in standard, even for node-based containers.
Does any standard library implementation allocate multiple nodes in the sam=
e block? If not, it might be better to simply add that guarantee.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_EEF1E789-F0E8-4100-804E-8FA433007EF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=
=E2=80=9320, at 3:03 AM, Marcelo Zimbres <<a href=3D"mailto:mzimbres@gma=
il.com" class=3D"">mzimbres@gmail.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><span style=3D"font-family: Helvetic=
a; font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !imp=
ortant;" class=3D"">Unordered containers usually need to rebind twice, once=
for node allocation</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !im=
portant;" class=3D"">and once for array allocation. that means they would n=
eed allocate() and</span><br style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !impo=
rtant;" class=3D"">allocate(size_type) as well. I cannot make max_size retu=
rn 1 for this reason.</span><br style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;" class=3D""></div></blockquote><div><br class=
=3D""></div><div>In that case, the problem is much different: The template =
is implementing two completely different (and incompatible) allocators. One=
rebind produces a node allocator and one produces an array allocator. They=
can=E2=80=99t be distinguished by the <font face=3D"Courier" class=3D"">n =
=3D=3D 1</font> test.</div><div><br class=3D""></div><div>Reviewing the All=
ocator requirements, I don=E2=80=99t see why it shouldn=E2=80=99t work to s=
imply implement the allocators separately. Converting a given allocator bet=
ween node mode and array mode requires preserving the state of both, but an=
y given object is only in one mode. Only node mode <font face=3D"Couri=
er" class=3D"">max_size</font> returns 1.</div><div><br class=3D""></div><d=
iv>Taking a quick look at the libc++ and libstdc++ implementations, they al=
locate individual nodes and arrays of pointers. So you can implement array =
mode as a partial specialization of the allocator template on pointer types=
..</div><div class=3D""><br class=3D""></div><div>The proposal certainly doe=
sn=E2=80=99t clarify the two-in-one nature, particularly that the result of=
<font face=3D"Courier" class=3D"">allocate(1)</font> couldn=E2=80=99t be p=
assed to <font face=3D"Courier" class=3D"">deallocate()</font>.</div><div><=
br class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><b=
lockquote type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;" class=3D"">Do allocators following the proposal have =
no allocate(size_type) overload at<br class=3D"">all, or is it defined as d=
eleted? That would break compatibility with all<br class=3D"">allocator-awa=
re containers, which seems to level the balance with the fact<br class=3D""=
>that max_size currently tends to be ignored.<br class=3D""></blockquote><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px; float: none; display: inline !important;" class=3D"">The allo=
cators can provide both allocate() and allocate(size_type),</span><br style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; o=
rphans: auto; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px; float: none; display: inline !important;" class=3D"">but if the ty=
pedef</span><br style=3D"font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px; float: none; display: inline !important;" class=
=3D"">use_node_allocation is defined to std::true_type, then the container =
should use</span><br style=3D"font-family: Helvetica; font-size: 12px; font=
-style: normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform:=
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-s=
troke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-s=
ize: 12px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
-webkit-text-stroke-width: 0px; float: none; display: inline !important;" =
class=3D"">allocate() for its node allocations. The proposal is non-breakin=
g.</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: none; w=
hite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wi=
dth: 0px;" class=3D""></div></blockquote></div><br class=3D""><div class=3D=
"">The task is to eliminate <font face=3D"Courier" class=3D"">allocate=
(size_type)</font>, so it=E2=80=99s begging the question to say they can pr=
ovide it.</div><div class=3D""><br class=3D""></div><div class=3D"">The pro=
posal does introduce allocators without a well-behaved <span style=3D"=
font-family: Courier;" class=3D"">allocate(size_type)</span>, no? Though it=
=E2=80=99s technically non-breaking, these allocators would be incompatible=
with all existing containers. The <font face=3D"Courier" class=3D"">max_si=
ze</font> approach avoids incompatibilities.</div><div class=3D""><br class=
=3D""></div><div class=3D"">In any case, the proposal needs to define requi=
rements for <font face=3D"Courier" class=3D"">[de]allocate(size_type)</font=
> in the case that <font face=3D"Courier" class=3D"">allocate()</font> is d=
efined.</div><div class=3D""><br class=3D""></div><div class=3D""><br class=
=3D""></div><div class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D"">On 2016=E2=80=9301=E2=80=9320, at 4:25 AM, Marcelo Zimbres <<a hre=
f=3D"mailto:mzimbres@gmail.com" class=3D"">mzimbres@gmail.com</a>> wrote=
:</div><br class=3D"Apple-interchange-newline"><div class=3D""><span class=
=3D"" style=3D"float: none; display: inline !important;">Node-based contain=
ers can themselves use n !=3D 1. There is no guarantee</span><br class=3D""=
><span class=3D"" style=3D"float: none; display: inline !important;">for n =
=3D=3D 1 in standard, even for node-based containers.</span><br class=3D"">=
</div></blockquote></div><div class=3D""><div class=3D""><span class=3D"" s=
tyle=3D"float: none; display: inline !important;"><br class=3D""></span></d=
iv></div><div class=3D""><span class=3D"" style=3D"float: none; display: in=
line !important;">Does any standard library implementation allocate multipl=
e nodes in the same block? If not, it might be better to simply add that gu=
arantee.</span></div><div class=3D""><span class=3D"" style=3D"float: none;=
display: inline !important;"><br class=3D""></span></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_EEF1E789-F0E8-4100-804E-8FA433007EF1--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 20 Jan 2016 14:19:37 +0800
Raw View
--Apple-Mail=_F57C2EBC-07C4-450F-A6C4-EA8CC057C019
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9320, at 3:42 AM, Nevin Liber <nevin@eviloverlor=
d.com> wrote:
>=20
> On 18 January 2016 at 19:43, David Krauss <potswa@gmail.com <mailto:potsw=
a@gmail.com>> wrote:
>=20
> Why can=E2=80=99t such allocators simply return 1 from max_size()? This w=
ould let array-based containers work up to an array size of 1, which should=
be good enough for std::deque at least.=20
>=20
> I have no idea what you are talking about with deque. deque is not a nod=
e-based container. Could you elaborate?
I=E2=80=99m just considering the effect of passing a node-based allocator t=
o an array-based container. deque could get a bonus feature.
I forgot about the =E2=80=9Ctable of contents=E2=80=9D array, though. That=
=E2=80=99s a fly in the ointment, so node-deque would actually be slightly =
trickier than an unordered container =E2=80=94 ah well.
> On 2016=E2=80=9301=E2=80=9320, at 3:54 AM, Nevin Liber <nevin@eviloverlor=
d.com> wrote:
>=20
> 2. Fall back to a different allocator, such as std::allocator. (This ma=
y allow you to use your allocator with almost-node-based containers such as=
std::deque; maybe that is what David Krauss was alluding to?)
Nah, my max_size suggestion is just the same as your assert suggestion, but=
without the option of fallback. Fallback is the status quo, anyway, no pro=
posal needed.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_F57C2EBC-07C4-450F-A6C4-EA8CC057C019
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v class=3D""><div class=3D""><div><blockquote type=3D"cite" class=3D""><div=
class=3D"">On 2016=E2=80=9301=E2=80=9320, at 3:42 AM, Nevin Liber <<a h=
ref=3D"mailto:nevin@eviloverlord.com" class=3D"">nevin@eviloverlord.com</a>=
> wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><d=
iv dir=3D"ltr" class=3D"">On 18 January 2016 at 19:43, David Krauss <s=
pan dir=3D"ltr" class=3D""><<a href=3D"mailto:potswa@gmail.com" target=
=3D"_blank" class=3D"">potswa@gmail.com</a>></span> wrote:<br class=
=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote cla=
ss=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; paddin=
g-left: 1ex;"><div class=3D"" style=3D"word-wrap: break-word;"><br class=3D=
""><div class=3D""><div class=3D"">Why can=E2=80=99t such allocators simply=
return 1 from <font face=3D"Courier" class=3D"">max_size()</font>? Th=
is would let array-based containers work up to an array size of 1, which sh=
ould be good enough for <font face=3D"Courier" class=3D"">std::deque</=
font> at least. </div></div></div></blockquote><div class=3D""><b=
r class=3D""></div><div class=3D"">I have no idea what you are talking abou=
t with deque. deque is not a node-based container. Could you el=
aborate?</div></div></div></div></div></blockquote><br class=3D""></div><di=
v>I=E2=80=99m just considering the effect of passing a node-based allocator=
to an array-based container. <font face=3D"Courier" class=3D"">deque<=
/font> could get a bonus feature.</div></div><div><br class=3D""></div=
><div>I forgot about the =E2=80=9Ctable of contents=E2=80=9D array, though.=
That=E2=80=99s a fly in the ointment, so node-<font face=3D"Courier" class=
=3D"">deque</font> would actually be slightly trickier than an unordered co=
ntainer =E2=80=94 ah well.</div><div><br class=3D""></div><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=E2=80=9320, at =
3:54 AM, Nevin Liber <<a href=3D"mailto:nevin@eviloverlord.com" class=3D=
"">nevin@eviloverlord.com</a>> wrote:</div><br class=3D"Apple-interchang=
e-newline"><div class=3D""><div class=3D"gmail_quote"><div class=3D"">2.&nb=
sp; Fall back to a different allocator, such as std::allocator. (This=
may allow you to use your allocator with almost-node-based containers such=
as std::deque; maybe that is what David Krauss was alluding to?)</div></di=
v></div></blockquote><br class=3D""></div><div>Nah, my <font face=3D"C=
ourier" class=3D"">max_size</font> suggestion is just the same as your=
<font face=3D"Courier" class=3D"">assert</font> suggestion, but =
without the option of fallback. Fallback is the status quo, anyway, no prop=
osal needed.</div></div><div><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_F57C2EBC-07C4-450F-A6C4-EA8CC057C019--
.
Author: Alisdair Meredith <alisdairm@me.com>
Date: Wed, 20 Jan 2016 07:52:25 -0500
Raw View
--Apple-Mail=_3E93EC0F-EE08-497C-9345-D6C3B6371CA2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
1) I dislike the idea of narrowing the standard contract, which is wide, bu=
t can
throw. If you request more memory than can be supplied by a single request=
,
throw std::bad_alloc. Otherwise, I agree with the idea that the existing a=
llocator
interface supports allocators optimized for this purpose, and it is no surp=
rise
that they would not work well for =E2=80=98vector=E2=80=99, that has contig=
uous memory requirements.
2) Fall-back allocators may be reasonable. The backing pool must be obtain=
ed
from somewhere, and may use a fall-back allocator to grow on demand anyway,
although certainly not all pools would need (or offer) this facility. You =
can cover
a lot of ground with creative use of the current interface.
Our approach to this issue is to observe that pooling is such a big win, we=
build
it into our node-based containers (with a generalized pool abstraction buil=
d on
top of the allocator interface) so that our containers are pooling, whether=
or not
the allocator is optimized for this strategy. I know other libraries have =
looked
into this and stepped back, as the standard containers (other than deque) o=
ffer
no interface that would allow the container to give up excessive memory all=
ocated
when a container hits an abnormally high peak size, holding onto that mostl=
y
unused memory until the container is destroyed.
We also have pooling allocators in the Library Fundamentals TS in the polym=
orphic
memory resources section, and good experience using them over many years at
Bloomberg, which is why we proposed them in the first place! I would be in=
terested
in feedback on how well they work (or not) for others in practice, before i=
nventing
new allocator interfaces to solve the same problem.
AlisdairM
> On Jan 19, 2016, at 2:54 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>=20
> On 19 January 2016 at 13:47, Marcelo Zimbres <mzimbres@gmail.com <mailto:=
mzimbres@gmail.com>> wrote:
> 2016-01-19 17:26 GMT-02:00 Nevin Liber <nevin@eviloverlord.com <mailto:ne=
vin@eviloverlord.com>>:
> >
> > No you don't. Just assert(n =3D=3D 1) in your custom allocator. If so=
meone
> > uses your custom allocator for something other than node based containe=
rs,
> > the assert will fire.
>=20
> What should I do when the condition n =3D! 1 is triggered with the client=
?
>=20
> 1. Abort. They violated the contract that your allocator should only be=
used with node-based containers.
>=20
> 2. Fall back to a different allocator, such as std::allocator. (This ma=
y allow you to use your allocator with almost-node-based containers such as=
std::deque; maybe that is what David Krauss was alluding to?)
> --=20
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com <mailto:nevin@evilover=
lord.com>> +1-847-691-1404
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at https://groups.google.com/a/isocpp.org/group/std-prop=
osals/ <https://groups.google.com/a/isocpp.org/group/std-proposals/>.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_3E93EC0F-EE08-497C-9345-D6C3B6371CA2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">1) I dislike the i=
dea of narrowing the standard contract, which is wide, but can<div class=3D=
"">throw. If you request more memory than can be supplied by a single=
request,</div><div class=3D"">throw std::bad_alloc. Otherwise, I agr=
ee with the idea that the existing allocator</div><div class=3D"">interface=
supports allocators optimized for this purpose, and it is no surprise</div=
><div class=3D"">that they would not work well for =E2=80=98vector=E2=80=99=
, that has contiguous memory requirements.</div><div class=3D""><br class=
=3D""></div><div class=3D"">2) Fall-back allocators may be reasonable. &nbs=
p;The backing pool must be obtained</div><div class=3D"">from somewhere, an=
d may use a fall-back allocator to grow on demand anyway,</div><div class=
=3D"">although certainly not all pools would need (or offer) this facility.=
You can cover</div><div class=3D"">a lot of ground with creative use=
of the current interface.</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">Our approach to this issue is to observe that pooling is such a b=
ig win, we build</div><div class=3D"">it into our node-based containers (wi=
th a generalized pool abstraction build on</div><div class=3D"">top of the =
allocator interface) so that our containers are pooling, whether or not</di=
v><div class=3D"">the allocator is optimized for this strategy. I kno=
w other libraries have looked</div><div class=3D"">into this and stepped ba=
ck, as the standard containers (other than deque) offer</div><div class=3D"=
">no interface that would allow the container to give up excessive memory a=
llocated</div><div class=3D"">when a container hits an abnormally high peak=
size, holding onto that mostly</div><div class=3D"">unused memory until th=
e container is destroyed.</div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">We also have pooling allocators in the Library Fundamentals TS in =
the polymorphic</div><div class=3D"">memory resources section, and good exp=
erience using them over many years at</div><div class=3D"">Bloomberg, which=
is why we proposed them in the first place! I would be interested</d=
iv><div class=3D"">in feedback on how well they work (or not) for others in=
practice, before inventing</div><div class=3D"">new allocator interfaces t=
o solve the same problem.</div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">AlisdairM</div><div class=3D""><br class=3D""><div><blockquote typ=
e=3D"cite" class=3D""><div class=3D"">On Jan 19, 2016, at 2:54 PM, Nevin Li=
ber <<a href=3D"mailto:nevin@eviloverlord.com" class=3D"">nevin@evilover=
lord.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><div c=
lass=3D""><div dir=3D"ltr" class=3D"">On 19 January 2016 at 13:47, Marcelo =
Zimbres <span dir=3D"ltr" class=3D""><<a href=3D"mailto:mzimbres@gmail.c=
om" target=3D"_blank" class=3D"">mzimbres@gmail.com</a>></span> wrote:<b=
r class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span class=3D"">2016-01-19 17:26 GMT-02:00 Nevin Li=
ber <<a href=3D"mailto:nevin@eviloverlord.com" class=3D"">nevin@evilover=
lord.com</a>>:<br class=3D"">
><br class=3D"">
> No you don't. Just assert(n =3D=3D 1) in your custom allocator.&=
nbsp; If someone<br class=3D"">
> uses your custom allocator for something other than node based contain=
ers,<br class=3D"">
> the assert will fire.<br class=3D"">
<br class=3D"">
</span>What should I do when the condition n =3D! 1 is triggered with the c=
lient?<br class=3D""></blockquote><div class=3D""><br class=3D""></div><div=
class=3D"">1. Abort. They violated the contract that your allo=
cator should only be used with node-based containers.</div><div class=3D"">=
<br class=3D""></div><div class=3D"">2. Fall back to a different allo=
cator, such as std::allocator. (This may allow you to use your alloca=
tor with almost-node-based containers such as std::deque; maybe that is wha=
t David Krauss was alluding to?)</div></div>-- <br class=3D""><div class=3D=
"gmail_signature"><div dir=3D"ltr" class=3D""><div class=3D""><div dir=3D"l=
tr" class=3D""><div class=3D""> Nevin ":-)" Liber <mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank" class=3D"">nevin@e=
viloverlord.com</a>> +1-847-691-1404</div></div></div></div></div>
</div></div><div class=3D""><br class=3D"webkit-block-placeholder"></div>
-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
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" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" class=3D"">https://groups.google.com/a/isocpp.org/group/st=
d-proposals/</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_3E93EC0F-EE08-497C-9345-D6C3B6371CA2--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Wed, 20 Jan 2016 18:21:07 -0200
Raw View
2016-01-20 10:52 GMT-02:00 Alisdair Meredith <alisdairm@me.com>:
> 1) I dislike the idea of narrowing the standard contract, which is wide, =
but can throw.
My proposal does not narrow the standard contract. Library
implementors can still use the allocate(size_type) when they want but
are required to support node allocation as well, when it is the user
desire.
I also think that if it were narrow, major libraries like libcxx and
libstd++ (I did not test on VS) would be profiting from
allocate(size_type) which is not the case (n is always 1).
> If you request more memory than can be supplied by a single request, thr=
ow std::bad_alloc.
I do not like the idea of throwing when I did not run out of memory,
all n !=3D 1 would be throwing. IMO the problem arises as a result of
doing linked allocation with an array allocator. They have distinct
nature.
> Otherwise, I agree with the idea that the existing
> allocator
> interface supports allocators optimized for this purpose, and it is no
> surprise
> that they would not work well for =E2=80=98vector=E2=80=99, that has cont=
iguous memory
> requirements.
I also think so and therefore I am proposing to have support for node
allocation in addition to array allocation, to bless node-based
containers as well. The split between array and node allocation is not
new [1]
> Our approach to this issue is to observe that pooling is such a big win, =
we
> build it into our node-based containers (with a generalized pool abstract=
ion build
> on top of the allocator interface) so that our containers are pooling, wh=
ether
> or not the allocator is optimized for this strategy. I know other librar=
ies have
> looked into this and stepped back, as the standard containers (other tha=
n deque)
> offer no interface that would allow the container to give up excessive me=
mory
> allocated when a container hits an abnormally high peak size, holding ont=
o that mostly
> unused memory until the container is destroyed.
I see pooling inside the container as undesirable since I may want to
hang many containers on the same allocator, this way its better to
keep container memory use to a minimum i.e. equal to the number of
elements, and let the allocator handle it. A container is not aware of
other containers the allocator yes. Additionally, it is also
restrictive as the pooling strategy cannot be changed by the user. If
it is kept in the allocator, users can change it at will.
> We also have pooling allocators in the Library Fundamentals TS in the
> polymorphic
> memory resources section, and good experience using them over many years =
at
> Bloomberg, which is why we proposed them in the first place! I would be
> interested
> in feedback on how well they work (or not) for others in practice, before
> inventing
> new allocator interfaces to solve the same problem.
I will have a look.
> AlisdairM
Thanks for the feedback.
Marcelo
[1] The Art of Computer Programming, Vol. 1, section 2.2.3.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Wed, 20 Jan 2016 18:47:15 -0200
Raw View
2016-01-20 4:13 GMT-02:00 David Krauss <potswa@gmail.com>:
>
> On 2016=E2=80=9301=E2=80=9320, at 3:03 AM, Marcelo Zimbres <mzimbres@gmai=
l.com> wrote:
>
> Unordered containers usually need to rebind twice, once for node allocati=
on
> and once for array allocation. that means they would need allocate() and
> allocate(size_type) as well. I cannot make max_size return 1 for this
> reason.
>
>
> In that case, the problem is much different: The template is implementing
> two completely different (and incompatible) allocators. One rebind produc=
es
> a node allocator and one produces an array allocator. They can=E2=80=99t =
be
> distinguished by the n =3D=3D 1 test.
I cannot pass two allocators to the container and cannot know which
rebound instance will be used for array/node allocation, that is why
in this case, both allocate() and allocate(size_type) must be
available.
> Reviewing the Allocator requirements, I don=E2=80=99t see why it shouldn=
=E2=80=99t work to
> simply implement the allocators separately. Converting a given allocator
> between node mode and array mode requires preserving the state of both, b=
ut
> any given object is only in one mode. Only node mode max_size returns 1.
>
> Taking a quick look at the libc++ and libstdc++ implementations, they
> allocate individual nodes and arrays of pointers. So you can implement ar=
ray
> mode as a partial specialization of the allocator template on pointer typ=
es.
The partial specialization trick may work, but it requires me to go
deeper in the internal details of how unordered containers are
implemented, which is unnecessary since I can distinguish allocation
types with allocate overloads.
> The proposal certainly doesn=E2=80=99t clarify the two-in-one nature, par=
ticularly
> that the result of allocate(1) couldn=E2=80=99t be passed to deallocate()=
..
I will fix that. It is meant that deallocate(pointer) can be only used
with pointers returned by allocate(),
> Do allocators following the proposal have no allocate(size_type) overload=
at
> all, or is it defined as deleted? That would break compatibility with all
> allocator-aware containers, which seems to level the balance with the fac=
t
> that max_size currently tends to be ignored.
>
>
> The allocators can provide both allocate() and allocate(size_type),
> but if the typedef
> use_node_allocation is defined to std::true_type, then the container shou=
ld
> use
> allocate() for its node allocations. The proposal is non-breaking.
>
>
> The task is to eliminate allocate(size_type), so it=E2=80=99s begging the=
question
> to say they can provide it.
I do not want to eliminate allocate(size_type) I want to have the
option of not using it. Array allocations are still there.
> The proposal does introduce allocators without a well-behaved
> allocate(size_type), no? Though it=E2=80=99s technically non-breaking, th=
ese
> allocators would be incompatible with all existing containers. The max_si=
ze
> approach avoids incompatibilities.
allocate(size_type) is untouched. The max_size approach alone does not
solve the problem, specially for unordered containers where I need an
allocate for array allocations and one for node allocation.
> In any case, the proposal needs to define requirements for
> [de]allocate(size_type) in the case that allocate() is defined.
I will do it. Thanks.
Marcelo
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 20 Jan 2016 16:35:43 -0600
Raw View
--047d7b4143189938e80529cb9dca
Content-Type: text/plain; charset=UTF-8
On 20 January 2016 at 14:47, Marcelo Zimbres <mzimbres@gmail.com> wrote:
> I cannot pass two allocators to the container and cannot know which
> rebound instance will be used for array/node allocation, that is why
> in this case, both allocate() and allocate(size_type) must be
> available.
>
But unless you mandate that node allocations are to be done by calling
allocate() I don't see how this fixes this problem. And if you are going
to mandate that, why not just mandate that they call allocate(1)?
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b4143189938e80529cb9dca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 20 January 2016 at 14:47, Marcelo Zimbres <span dir=3D"=
ltr"><<a href=3D"mailto:mzimbres@gmail.com" target=3D"_blank">mzimbres@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">I cannot pass two allocators to=
the container and cannot know which<br>
rebound instance will be used for array/node allocation, that is why<br>
in this case, both allocate() and allocate(size_type) must be<br>
available.<br></blockquote><div><br></div><div>But unless you mandate that =
node allocations are to be done by calling allocate() I don't see how t=
his fixes this problem.=C2=A0 And if you are going to mandate that, why not=
just mandate that they call allocate(1)?</div></div>-- <br><div class=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 />
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7b4143189938e80529cb9dca--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Thu, 21 Jan 2016 17:08:59 -0200
Raw View
2016-01-20 20:35 GMT-02:00 Nevin Liber <nevin@eviloverlord.com>:
>
> But unless you mandate that node allocations are to be done by calling
> allocate() I don't see how this fixes this problem.
That is what I am proposing. Node allocations are handle by allocate()
whenever the allocator defines a typedef use_node_allocation to
std::true_type,
> And if you are going to mandate that, why not just mandate that they call allocate(1)?
That would work for pure node-based containers, but not for unordered
ones. In general, there is no way of knowing which rebound type is
used for node/array allocation. They have to be performed on distinct
member functions.
Marcelo
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?UTF-8?Q?Ion_Gazta=c3=b1aga?= <igaztanaga@gmail.com>
Date: Thu, 21 Jan 2016 22:19:27 +0100
Raw View
On 21/01/2016 20:08, Marcelo Zimbres wrote:
> 2016-01-20 20:35 GMT-02:00 Nevin Liber <nevin@eviloverlord.com>:
>>
>> But unless you mandate that node allocations are to be done by calling
>> allocate() I don't see how this fixes this problem.
>
> That is what I am proposing. Node allocations are handle by allocate()
> whenever the allocator defines a typedef use_node_allocation to
> std::true_type,
>
>
>> And if you are going to mandate that, why not just mandate that they call allocate(1)?
>
> That would work for pure node-based containers, but not for unordered
> ones. In general, there is no way of knowing which rebound type is
> used for node/array allocation. They have to be performed on distinct
> member functions.
Marcelo, I think your proposal is interesting. I would like to suggest
some changes to achieve the same goal.
I think we should make this feature a bit more transparent. Hopefully,
now we have a layer between the container and the allocator,
allocator_traits. Instead of "use_node_allocation" my suggestion is to
have two new allocator_traits members:
//Calls a.allocate_node() if possible. Otherwise it
//calls a.allocate(1u). All memory allocated with this
//function must be deallocated with deallocate_node(a, p)
static pointer allocate_node(Alloc &a);
//Requires: p shall be allocated by a call to allocate_node(a)
//Calls a.deallocate_node(p) if possible. Otherwise
//calls a.deallocate(p, 1u).
static void deallocate_node(Alloc &a, pointer p);
Containers allocating a single node can use the new function if desired.
I don't think we should require the use of the new function, it could be
a QOI feature. Calls to a.allocate(n) should continue to work on node
allocators.
There is existing practice in Boost.Container with this approach, (not
using allocator_traits, since it didn't exist when implementing N2045)
which will be helpful to push your proposal forward.
Best,
Ion
PS: Maximum performance is achieved when allocating several nodes at
once, the so called "burst allocation" in N2045. This needs an
alternative interface, 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 22 Jan 2016 10:38:43 +0800
Raw View
--Apple-Mail=_4F8299FA-4B94-476B-A308-591E16DF450B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9321, at 4:47 AM, Marcelo Zimbres <mzimbres@gmai=
l.com> wrote:
>=20
> 2016-01-20 4:13 GMT-02:00 David Krauss <potswa@gmail.com <mailto:potswa@g=
mail.com>>:
>=20
>> Taking a quick look at the libc++ and libstdc++ implementations, they
>> allocate individual nodes and arrays of pointers. So you can implement a=
rray
>> mode as a partial specialization of the allocator template on pointer ty=
pes.
>=20
> The partial specialization trick may work, but it requires me to go
> deeper in the internal details of how unordered containers are
> implemented, which is unnecessary since I can distinguish allocation
> types with allocate overloads.
If the library calls a special overload, then the user doesn=E2=80=99t need=
to arrange for it to be called, yes. Your solution adds complexity to the =
library implementation and to the Allocator concept specification, though. =
Also, it doesn=E2=80=99t allow for a gradual transition: If the library doe=
sn=E2=80=99t call allocate(), node allocation will never occur. So, let=E2=
=80=99s look for a way that fits better with the status quo.
Reliance on library details can be eliminated by an is_node_type predicate,=
either as a member or a metafunction. For example:
template< typename T, bool =3D T::is_node_type >
struct my_alloc {
T * allocate( std::size_t n );
void deallocate( T * p, std::size_t n );
};
template< typename T >
struct my_alloc< T, true > {
T * allocate( std::size_t must_be_one );
void deallocate( T * p, std::size_t must_be_one );
constexpr std::size_t max_size() const
{ return 1; }
};
Advantages:
1. Scales to cooperate with unsupporting libraries. The hackish introspecti=
on can be #ifdef=E2=80=99ed in.
2. Avoids having member functions that shouldn=E2=80=99t (or can=E2=80=99t)=
be instantiated. There=E2=80=99s no my_alloc<node>::allocate(std::size_t) =
or my_alloc<node*>::allocate().
3. Library support is accomplished simply by adding static constexpr bool i=
s_node_type =3D true to node types, no need for SFINAE to switch between al=
locate() and allocate(1) (matching the deallocate overload every time).
4. No quietly lurking bugs from library ABI breakage. A dynamic library bui=
lt without is_node_type support won=E2=80=99t link against a program built =
with, because the default argument is baked into the allocator type. On the=
other hand, in your solution the alternative functions always exist, so th=
e implementation will happily generate and call deallocate(p) even though t=
he dynamic library called allocate(1).
However, this still doesn=E2=80=99t look like the best solution. You can=E2=
=80=99t write a node allocation pool without knowing the node type. The pro=
posal should address getting the node type from the container type. And giv=
en that, the allocator can just partially specialize on the node type, no i=
s_node_type needed.
It would be nice to see a complete prototype.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_4F8299FA-4B94-476B-A308-591E16DF450B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=
=E2=80=9321, at 4:47 AM, Marcelo Zimbres <<a href=3D"mailto:mzimbres@gma=
il.com" class=3D"">mzimbres@gmail.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><span style=3D"font-family: Helvetic=
a; font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !imp=
ortant;" class=3D"">2016-01-20 4:13 GMT-02:00 David Krauss <</span><a hr=
ef=3D"mailto:potswa@gmail.com" style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px;" class=3D"">potswa@gmail.com</a><span style=3D"=
font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-al=
ign: start; text-indent: 0px; text-transform: none; white-space: normal; wi=
dows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none;=
display: inline !important;" class=3D"">>:<br class=3D""></span><br sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;" class=3D"">Taking a quick look at the libc++ =
and libstdc++ implementations, they<br class=3D"">allocate individual nodes=
and arrays of pointers. So you can implement array<br class=3D"">mode as a=
partial specialization of the allocator template on pointer types.<br clas=
s=3D""></blockquote><br style=3D"font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px; float: none; display: inline !important=
;" class=3D"">The partial specialization trick may work, but it requires me=
to go</span><br style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px; float: none; display: inline !important;" clas=
s=3D"">deeper in the internal details of how unordered containers are</span=
><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; orphans:=
auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-=
style: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px; float: none; display: inline !important;" class=3D"">imple=
mented, which is unnecessary since I can distinguish allocation</span><br s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; orphans: auto;=
text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cla=
ss=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style:=
normal; font-variant: normal; font-weight: normal; letter-spacing: normal;=
orphans: auto; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-w=
idth: 0px; float: none; display: inline !important;" class=3D"">types with =
allocate overloads.</span><br style=3D"font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-t=
ransform: none; white-space: normal; widows: auto; word-spacing: 0px; -webk=
it-text-stroke-width: 0px;" class=3D""></div></blockquote><div><br class=3D=
""></div><div>If the library calls a special overload, then the user doesn=
=E2=80=99t need to arrange for it to be called, yes. Your solution adds com=
plexity to the library implementation and to the Allocator concept specific=
ation, though. Also, it doesn=E2=80=99t allow for a gradual transition: If =
the library doesn=E2=80=99t call <font face=3D"Courier" class=3D"">allocate=
()</font>, node allocation will never occur. So, let=E2=80=99s look for a w=
ay that fits better with the status quo.</div><div><br class=3D""></div><di=
v>Reliance on library details can be eliminated by an <font face=3D"Courier=
" class=3D"">is_node_type</font> predicate, either as a member or a metafun=
ction. For example:</div><div><br class=3D""></div><div><font face=3D"Couri=
er" class=3D"">template< typename T, bool =3D </font><span style=3D=
"font-family: Courier;" class=3D"">T::is_node_type</span><span style=3D"fon=
t-family: Courier;" class=3D""> ></span></div><div><font face=3D"Co=
urier" class=3D"">struct my_alloc {</font></div><div><font face=3D"Courier"=
class=3D""> T * allocate( std::size_t n );</font></div><div><=
font face=3D"Courier" class=3D""> void deallocate( T * p, std:=
:size_t n );</font></div><div><font face=3D"Courier" class=3D"">};</font></=
div><div><font face=3D"Courier" class=3D""><br class=3D""></font></div><div=
><font face=3D"Courier" class=3D"">template< typename T ></font></div=
><div><font face=3D"Courier" class=3D"">struct my_alloc< T, true > {<=
/font></div><div><span style=3D"font-family: Courier;" class=3D""> &n=
bsp; T * allocate( std::size_t must_be_one );</span></div><div><font face=
=3D"Courier" class=3D""> void deallocate( T * p, std::size_t&n=
bsp;must_be_one );</font></div><div><font face=3D"Courier" class=3D"">=
<br class=3D""></font></div><div><font face=3D"Courier" class=3D""> &=
nbsp; constexpr std::size_t max_size() const</font></div><div><font face=3D=
"Courier" class=3D""> { return 1; }</font></div>=
<div><font face=3D"Courier" class=3D"">};</font></div><div><br class=3D""><=
/div><div>Advantages:</div><div>1. Scales to cooperate with unsupporting li=
braries. The hackish introspection can be <font face=3D"Courier" class=3D""=
>#ifdef</font>=E2=80=99ed in.</div><div><br class=3D""></div><div>2. Avoids=
having member functions that shouldn=E2=80=99t (or can=E2=80=99t) be insta=
ntiated. There=E2=80=99s no <font face=3D"Courier" class=3D"">my_alloc<n=
ode>::allocate(std::size_t)</font> or <font face=3D"Courier" class=3D"">=
my_alloc<node*>::allocate()</font>.</div><div><br class=3D""></div><d=
iv>3. Library support is accomplished simply by adding <font face=3D"Courie=
r" class=3D"">static constexpr bool is_node_type =3D true</font> to no=
de types, no need for SFINAE to switch between <font face=3D"Courier" class=
=3D"">allocate()</font> and <font face=3D"Courier" class=3D"">allocate(1)</=
font> (matching the <font face=3D"Courier" class=3D"">deallocate</font=
> overload every time).</div><div><br class=3D""></div><div>4. No quietly l=
urking bugs from library ABI breakage. A dynamic library built without <fon=
t face=3D"Courier" class=3D"">is_node_type</font> support won=E2=80=99t lin=
k against a program built with, because the default argument is baked into =
the allocator type. On the other hand, in your solution the alternative fun=
ctions always exist, so the implementation will happily generate and call <=
font face=3D"Courier" class=3D"">deallocate(p)</font> even though the dynam=
ic library called <font face=3D"Courier" class=3D"">allocate(1)</font>.</di=
v><div><br class=3D""></div><div>However, this still doesn=E2=80=99t look l=
ike the best solution. You can=E2=80=99t write a node allocation pool witho=
ut knowing the node type. The proposal should address getting the node type=
from the container type. And given that, the allocator can just partially =
specialize on the node type, no <font face=3D"Courier" class=3D"">is_node_t=
ype</font> needed.</div><div><br class=3D""></div><div>It would be nice to =
see a complete prototype.</div><div><br class=3D""></div></div></body></htm=
l>
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_4F8299FA-4B94-476B-A308-591E16DF450B--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 22 Jan 2016 12:50:57 +0800
Raw View
--Apple-Mail=_3727A367-C06D-4655-9BCD-45472CA04863
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9322, at 10:38 AM, David Krauss <potswa@gmail.co=
m> wrote:
>=20
> It would be nice to see a complete prototype.
I mean, for any proposal in this space, it would be nice to see a complete =
example, including both the user=E2=80=99s node-friendly allocator and the =
library support. It=E2=80=99s hard to extrapolate to the big picture, and a=
prototype shouldn=E2=80=99t be too much to ask.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_3727A367-C06D-4655-9BCD-45472CA04863
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=
=E2=80=9322, at 10:38 AM, David Krauss <<a href=3D"mailto:potswa@gmail.c=
om" class=3D"">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><div class=3D""><span style=3D"font-family: Helvetica; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px; float: none; display: inline !important=
;" class=3D"">It would be nice to see a complete prototype.</span></div></b=
lockquote></div><br class=3D""><div class=3D"">I mean, for any proposal in =
this space, it would be nice to see a complete example, including both the =
user=E2=80=99s node-friendly allocator and the library support. It=E2=80=99=
s hard to extrapolate to the big picture, and a prototype shouldn=E2=80=99t=
be too much to ask.</div><div class=3D""><br class=3D""></div></body></htm=
l>
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_3727A367-C06D-4655-9BCD-45472CA04863--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Sat, 23 Jan 2016 13:39:34 +0100
Raw View
2016-01-21 22:19 GMT+01:00 Ion Gazta=C3=B1aga <igaztanaga@gmail.com>:
> Marcelo, I think your proposal is interesting. I would like to suggest so=
me
> changes to achieve the same goal.
>
> I think we should make this feature a bit more transparent. Hopefully, no=
w
> we have a layer between the container and the allocator, allocator_traits=
..
> Instead of "use_node_allocation" my suggestion is to have two new
> allocator_traits members:
>
> //Calls a.allocate_node() if possible. Otherwise it
> //calls a.allocate(1u). All memory allocated with this
> //function must be deallocated with deallocate_node(a, p)
> static pointer allocate_node(Alloc &a);
>
> //Requires: p shall be allocated by a call to allocate_node(a)
> //Calls a.deallocate_node(p) if possible. Otherwise
> //calls a.deallocate(p, 1u).
> static void deallocate_node(Alloc &a, pointer p);
That is what I am doing, with two small differences:
1) Instead of having the two new names in the allocator_traits:
allocate_node/deallocate_node, I am simply overloading
allocate/deallocate. I do not know what is the better approach, but in
essentially, there is no difference.
2) I did not think of falling back to allocate(1), whenever
allocate_node() is not available. This is indeed a good idea as
node-based containers could use allocate_node regardless of whether
the allocator provides allocate_node or not. This helps me cover your
last comment.
> Containers allocating a single node can use the new function if desired. =
I
> don't think we should require the use of the new function, it could be a =
QOI
> feature. Calls to a.allocate(n) should continue to work on node allocator=
s.
In my proposal I do not rule out array allocation inside node-based
containers, they remain untouched. But I do need a guarantee that node
allocation is used whenever the user desires so. This allows me to
have simple solutions, for simple problems i.e. do not provide array
allocation at all in my allocator. Think of how simple it would be to
write an allocator for the simple use case:
std::array<char, 20 * node_size > buffer =3D {{}};
my_allocator alloc(buffer);
std::list<int, my_allocator<int>> l(alloc);
I would need only a couple of lines of code for that. A massive
simplification if compared to the allocators i could find in the
literature.
Additionally, if anyone feels the need of using array + node
allocation together inside node-based containers, it would still be
possible, given your suggestion of falling back to allocate(1) when
allocate_node is not available.
> There is existing practice in Boost.Container with this approach, (not us=
ing
> allocator_traits, since it didn't exist when implementing N2045) which wi=
ll
> be helpful to push your proposal forward.
That would be great. I am already using boost::node_allocator as a
reference in my proposal.
Marcelo
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Sat, 23 Jan 2016 15:11:07 +0100
Raw View
2016-01-22 3:38 GMT+01:00 David Krauss <potswa@gmail.com>:
>
> If the library calls a special overload, then the user doesn=E2=80=99t ne=
ed to
> arrange for it to be called, yes. Your solution adds complexity to the
> library implementation and to the Allocator concept specification, though=
..
Any new feature would demand an increase in complexity. In this case
the added complexity is minimal, the library implementation has to
decide which overload gets called given a typedef be true or false.
> Also, it doesn=E2=80=99t allow for a gradual transition: If the library d=
oesn=E2=80=99t call
> allocate(), node allocation will never occur.
Yes, I need a way to ensure allocate() gets called.
> So, let=E2=80=99s look for a way that
> fits better with the status quo.
>
> Reliance on library details can be eliminated by an is_node_type predicat=
e,
> either as a member or a metafunction. For example:
>
> template< typename T, bool =3D T::is_node_type >
> struct my_alloc {
> T * allocate( std::size_t n );
> void deallocate( T * p, std::size_t n );
> };
>
> template< typename T >
> struct my_alloc< T, true > {
> T * allocate( std::size_t must_be_one );
> void deallocate( T * p, std::size_t must_be_one );
>
> constexpr std::size_t max_size() const
> { return 1; }
> };
The problem I see:
allocate( std::size_t must_be_one ) is not better than
allocate()/allocate_node(): You get a hard-coded 1 that is redundant
and will be ignored inside the function anyway (the function handles
only one node at time, no need to specify that).
But now with a constexpr max_size function, I can avoid a typedef in
the allocator. However, that would demand to change
std::allocator_traits definition of max_size to be constexpr as well
which would be breaking, as far as I can see.
> Advantages:
> 1. Scales to cooperate with unsupporting libraries. The hackish
> introspection can be #ifdef=E2=80=99ed in.
>
> 2. Avoids having member functions that shouldn=E2=80=99t (or can=E2=80=99=
t) be instantiated.
> There=E2=80=99s no my_alloc<node>::allocate(std::size_t) or
> my_alloc<node*>::allocate().
>
> 3. Library support is accomplished simply by adding static constexpr bool
> is_node_type =3D true to node types, no need for SFINAE to switch between
> allocate() and allocate(1) (matching the deallocate overload every time).
>
> 4. No quietly lurking bugs from library ABI breakage. A dynamic library
> built without is_node_type support won=E2=80=99t link against a program b=
uilt with,
> because the default argument is baked into the allocator type. On the oth=
er
> hand, in your solution the alternative functions always exist, so the
> implementation will happily generate and call deallocate(p) even though t=
he
> dynamic library called allocate(1).
>
> However, this still doesn=E2=80=99t look like the best solution. You can=
=E2=80=99t write a
> node allocation pool without knowing the node type. The proposal should
> address getting the node type from the container type. And given that, th=
e
> allocator can just partially specialize on the node type, no is_node_type
> needed.
Yes, I need the node-type to write portable buffer sizes (actually
only the node size). I was thinking of that as a future proposal
(together with a node allocator itself).
And now, even if the node type is exposed on node based containers, so
that specializations can be easily done, you still need means to tell
the library to call allocate(n) with n =3D 1 (supposing I cannot make
max_size constexpr).
> It would be nice to see a complete prototype.
I do have a prototype in my github. If this proposal gets aligned with
boost containers, than it would not be only a prototype but a well
tested concept, given the wide spread use of boost.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 24 Jan 2016 12:15:32 +0800
Raw View
--Apple-Mail=_21695EF3-77E4-49D8-9AFB-953115523880
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9323, at 10:11 PM, Marcelo Zimbres <mzimbres@gma=
il.com> wrote:
>=20
> Any new feature would demand an increase in complexity. In this case
> the added complexity is minimal, the library implementation has to
> decide which overload gets called given a typedef be true or false.
Adding SFINAE to every node allocation and deallocation is not minimal, if =
a simpler solution exists.
> The problem I see:
>=20
> allocate( std::size_t must_be_one ) is not better than
> allocate()/allocate_node(): You get a hard-coded 1 that is redundant
> and will be ignored inside the function anyway (the function handles
> only one node at time, no need to specify that).
A constant argument to an unused parameter in an inlined function is very l=
ikely to have zero impact.
> But now with a constexpr max_size function, I can avoid a typedef in
> the allocator. However, that would demand to change
> std::allocator_traits definition of max_size to be constexpr as well
> which would be breaking, as far as I can see.
Without any proposal regarding constexpr, the user can already specialize a=
n allocator for nodes, as long as it knows about the library=E2=80=99s inte=
rnal node types.
Still, what would constexpr break? It=E2=80=99s possible to write a program=
which observes that allocator_traits::max_size is not currently constexpr,=
but that=E2=80=99s not something that necessarily needs to be preserved. A=
dding constexpr might not properly even be a proposal, but rather a defect =
report that std::deque currently can=E2=80=99t respect max_size when it=E2=
=80=99s smaller than the calculated array extent.
Let=E2=80=99s forget about constexpr, since deque is outside the scope of t=
his discussion, and just say that max_size returns 1, which essentially ref=
lects the same thing as Nevin=E2=80=99s assert.
> Yes, I need the node-type to write portable buffer sizes (actually
> only the node size). I was thinking of that as a future proposal
> (together with a node allocator itself).
It would be better for the proposal to provide for users writing their own =
node allocators. At the least, there should be single-threaded and multithr=
eaded versions. Allocation of the free-block stack is another question.
Exposing the node type itself would also work, and that might better serve =
portability. The user can map from node types to node sizes, but not vice v=
ersa.
> And now, even if the node type is exposed on node based containers, so
> that specializations can be easily done, you still need means to tell
> the library to call allocate(n) with n =3D 1 (supposing I cannot make
> max_size constexpr).
Are you aware of an implementation passing n !=3D 1, or any reason to do th=
at? This seems very speculative. Note that n !=3D 1 is different from alloc=
ating several nodes at once, in which case they may be deallocated in any o=
rder.
> I do have a prototype in my github.
Ah: https://github.com/mzimbres/rtcpp/tree/master/rtcpp/memory <https://git=
hub.com/mzimbres/rtcpp/tree/master/rtcpp/memory>
> If this proposal gets aligned with
> boost containers, than it would not be only a prototype but a well
> tested concept, given the wide spread use of boost.
That depends on how many projects are using what particular features in Boo=
st.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_21695EF3-77E4-49D8-9AFB-953115523880
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=
=E2=80=9323, at 10:11 PM, Marcelo Zimbres <<a href=3D"mailto:mzimbres@gm=
ail.com" class=3D"">mzimbres@gmail.com</a>> wrote:</div><br class=3D"App=
le-interchange-newline"><div class=3D""><span style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !im=
portant;" class=3D"">Any new feature would demand an increase in complexity=
.. In this case</span><br style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline !importan=
t;" class=3D"">the added complexity is minimal, the library implementation =
has to</span><br style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px; float: none; display: inline !important;" clas=
s=3D"">decide which overload gets called given a typedef be true or false.<=
/span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: nor=
mal; font-variant: normal; font-weight: normal; letter-spacing: normal; orp=
hans: auto; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width=
: 0px;" class=3D""></div></blockquote><div><br class=3D""></div><div>Adding=
SFINAE to every node allocation and deallocation is not minimal, if a simp=
ler solution exists.</div><br class=3D""><blockquote type=3D"cite" class=3D=
""><div class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; float: none; display: inline !important;" class=3D"">=
The problem I see:</span><br style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;" class=3D""><br style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; orphans: auto; text-align: start; text-indent:=
0px; text-transform: none; white-space: normal; widows: auto; word-spacing=
: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display:=
inline !important;" class=3D"">allocate( std::size_t must_be_one ) is not =
better than</span><br style=3D"font-family: Helvetica; font-size: 12px; fon=
t-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px;=
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px=
; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"=
class=3D"">allocate()/allocate_node(): You get a hard-coded 1 that is redu=
ndant</span><br style=3D"font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px; float: none; display: inline !important;" class=
=3D"">and will be ignored inside the function anyway (the function handles<=
/span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: nor=
mal; font-variant: normal; font-weight: normal; letter-spacing: normal; orp=
hans: auto; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width=
: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; float: none; display: inline !important;" class=3D"">=
only one node at time, no need to specify that).</span><br style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div><=
/blockquote><div><br class=3D""></div><div>A constant argument to an unused=
parameter in an inlined function is very likely to have zero impact.</div>=
<br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><span s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; orphans: auto;=
text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; floa=
t: none; display: inline !important;" class=3D"">But now with a constexpr m=
ax_size function, I can avoid a typedef in</span><br style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: n=
one; display: inline !important;" class=3D"">the allocator. However, that w=
ould demand to change</span><br style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !i=
mportant;" class=3D"">std::allocator_traits definition of max_size to be co=
nstexpr as well</span><br style=3D"font-family: Helvetica; font-size: 12px;=
font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
0px; -webkit-text-stroke-width: 0px; float: none; display: inline !importa=
nt;" class=3D"">which would be breaking, as far as I can see.</span><br sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""></div></blockquote><div><br class=3D""></div><div>Without any proposa=
l regarding <font face=3D"Courier" class=3D"">constexpr</font>, the user ca=
n already specialize an allocator for nodes, as long as it knows about the =
library=E2=80=99s internal node types.</div><div><br class=3D""></div><div>=
Still, what would <span style=3D"font-family: Courier;" class=3D"">con=
stexpr</span> break? It=E2=80=99s possible to write a program which ob=
serves that <font face=3D"Courier" class=3D"">allocator_traits::max_size</f=
ont> is not currently <font face=3D"Courier" class=3D"">constexpr</font>, b=
ut that=E2=80=99s not something that necessarily needs to be preserved. Add=
ing <font face=3D"Courier" class=3D"">constexpr</font> might not properly e=
ven be a proposal, but rather a defect report that <font face=3D"Courier" c=
lass=3D"">std::deque</font> currently can=E2=80=99t respect <font face=
=3D"Courier" class=3D"">max_size</font> when it=E2=80=99s smaller than the =
calculated array extent.</div><div><br class=3D""></div><div>Let=E2=80=99s =
forget about <font face=3D"Courier" class=3D"">constexpr</font>, since <fon=
t face=3D"Courier" class=3D"">deque</font> is outside the scope of this dis=
cussion, and just say that <font face=3D"Courier" class=3D"">max_size<=
/font> returns 1, which essentially reflects the same thing as Nevin=E2=80=
=99s <font face=3D"Courier" class=3D"">assert</font>.</div><div><br class=
=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><span styl=
e=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-vari=
ant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; te=
xt-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;" class=3D"">Yes, I need the node-type to =
write portable buffer sizes (actually</span><br style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"fon=
t-family: Helvetica; font-size: 12px; font-style: normal; font-variant: nor=
mal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; di=
splay: inline !important;" class=3D"">only the node size). I was thinking o=
f that as a future proposal</span><br style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inl=
ine !important;" class=3D"">(together with a node allocator itself).</span>=
<br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
" class=3D""></div></blockquote><div><br class=3D""></div><div>It would be =
better for the proposal to provide for users writing their own node allocat=
ors. At the least, there should be single-threaded and multithreaded versio=
ns. Allocation of the free-block stack is another question.</div><div><br c=
lass=3D""></div><div>Exposing the node type itself would also work, and tha=
t might better serve portability. The user can map from node types to node =
sizes, but not vice versa.</div><br class=3D""><blockquote type=3D"cite" cl=
ass=3D""><div class=3D""><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px; float: none; display: inline !important;" class=
=3D"">And now, even if the node type is exposed on node based containers, s=
o</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; o=
rphans: auto; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px; float: none; display: inline !important;" class=3D"=
">that specializations can be easily done, you still need means to tell</sp=
an><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; fon=
t-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px; float: none; display: inline !important;" class=3D"">the=
library to call allocate(n) with n =3D 1 (supposing I cannot make</span><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px; float: none; display: inline !important;" class=3D"">max_size=
constexpr).</span><br style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;" class=3D""></div></blockquote><div><br class=3D""></di=
v><div>Are you aware of an implementation passing <font face=3D"Courie=
r" class=3D"">n !=3D 1</font>, or any reason to do that? This seems very sp=
eculative. Note that <font face=3D"Courier" class=3D"">n !=3D 1</font> is d=
ifferent from allocating several nodes at once, in which case they may be d=
eallocated in any order.</div><br class=3D""><blockquote type=3D"cite" clas=
s=3D""><div class=3D""><span style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px; float: none; display: inline !important;" class=
=3D"">I do have a prototype in my github. </span></div></blockquote><div><b=
r class=3D""></div><div class=3D"">Ah: <a href=3D"https://github.com/m=
zimbres/rtcpp/tree/master/rtcpp/memory" class=3D"">https://github.com/mzimb=
res/rtcpp/tree/master/rtcpp/memory</a></div><div class=3D""><br class=3D"">=
</div><blockquote type=3D"cite" class=3D""><div class=3D""><span style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">If this proposal gets aligned with<=
/span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: nor=
mal; font-variant: normal; font-weight: normal; letter-spacing: normal; orp=
hans: auto; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width=
: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; float: none; display: inline !important;" class=3D"">=
boost containers, than it would not be only a prototype but a well</span><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px; float: none; display: inline !important;" class=3D"">tested c=
oncept, given the wide spread use of boost.</span><br style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></bloc=
kquote></div><div class=3D""><br class=3D""></div><div class=3D"">That depe=
nds on how many projects are using what particular features in Boost.</div>=
<div class=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_21695EF3-77E4-49D8-9AFB-953115523880--
.
Author: =?UTF-8?Q?Ion_Gazta=c3=b1aga?= <igaztanaga@gmail.com>
Date: Sun, 24 Jan 2016 21:55:55 +0100
Raw View
On 23/01/2016 13:39, Marcelo Zimbres wrote:
>
> 1) Instead of having the two new names in the allocator_traits:
> allocate_node/deallocate_node, I am simply overloading
> allocate/deallocate. I do not know what is the better approach, but in
> essentially, there is no difference.
One reason for a different name (it's a matter of taste) is that
function names should reflect that both operations have different
semantics, apart from the storage size. If memory expansion (realloc) is
added in the future, it should only work with storage allocated with
allocate(n) but not with storage allocated for nodes. This allows node
allocations to avoid extra bookeeping data to mark the storage as
non-expandable (typically simple segregated storage).
In any case, if the proposal goes forward, I guess the committee will
find the best name for the "node" operations.
Best,
Ion
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Sun, 24 Jan 2016 20:46:32 -0200
Raw View
2016-01-24 2:15 GMT-02:00 David Krauss <potswa@gmail.com>:
>
> Without any proposal regarding constexpr, the user can already specialize=
an
> allocator for nodes, as long as it knows about the library=E2=80=99s inte=
rnal node
> types.
I will add that to my proposal. Knowing the containers node type is
indeed very useful to avoid the tricks I have been doing to guess the
node size.
> Still, what would constexpr break? It=E2=80=99s possible to write a progr=
am which
> observes that allocator_traits::max_size is not currently constexpr, but
> that=E2=80=99s not something that necessarily needs to be preserved. Addi=
ng
> constexpr might not properly even be a proposal, but rather a defect repo=
rt
> that std::deque currently can=E2=80=99t respect max_size when it=E2=80=99=
s smaller than the
> calculated array extent.
If libraries begin to get static information from max_size i.e.
whether its 1 or not, than all custom allocators that implement
max_size as non-constexpr would be broken (static information cannot
be read out of them). That means, as you said, libraries will have to
detect whether max_size is constexpr or not. All custom allocators
that may want constexpr max_size (node allocators for example), will
have to specialize the std::allocator_traits, since the default is
non-constexpr (my proposal does not need that). The whole picture I
see would be something like this
1) Libraries have to begin to pay attention to max_size, which is fair
enough. (They are not doing it now AFAIK)
2) std::allocator_traits specializations may offer a constexpr max_size.
3) Libraries have to detect that feature.
4) If they are constexpr, check if max_size is 1 and call allocate(n)
accordingly.
I do not think it would be reasonable to standardize this. However, I
like pretty much your idea if it were indeed possible to have a
constexpr max_size.
> Let=E2=80=99s forget about constexpr, since deque is outside the scope of=
this
> discussion, and just say that max_size returns 1, which essentially refle=
cts
> the same thing as Nevin=E2=80=99s assert
>
> Yes, I need the node-type to write portable buffer sizes (actually
> only the node size). I was thinking of that as a future proposal
> (together with a node allocator itself).
>
>
> It would be better for the proposal to provide for users writing their ow=
n
> node allocators. At the least, there should be single-threaded and
> multithreaded versions. Allocation of the free-block stack is another
> question.
>
> Exposing the node type itself would also work, and that might better serv=
e
> portability. The user can map from node types to node sizes, but not vice
> versa.
>
> And now, even if the node type is exposed on node based containers, so
> that specializations can be easily done, you still need means to tell
> the library to call allocate(n) with n =3D 1 (supposing I cannot make
> max_size constexpr).
>
>
> Are you aware of an implementation passing n !=3D 1, or any reason to do =
that?
> This seems very speculative. Note that n !=3D 1 is different from allocat=
ing
> several nodes at once, in which case they may be deallocated in any order=
..
n is a runtime parameter that can take any value, so I cannot simply
assume that n =3D 1 always, on all c++ libraries. It is definitely not
portable to rely on that. That said, yes, I have never seen anyone
using n !=3D 1.
Marcelo
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Wed, 27 Jan 2016 18:39:35 -0200
Raw View
2016-01-24 18:55 GMT-02:00 Ion Gazta=C3=B1aga <igaztanaga@gmail.com>:
> One reason for a different name (it's a matter of taste) is that function
> names should reflect that both operations have different semantics, apart
> from the storage size.
I do agree.
> If memory expansion (realloc) is added in the future,
> it should only work with storage allocated with allocate(n) but not with
> storage allocated for nodes. This allows node allocations to avoid extra
> bookeeping data to mark the storage as non-expandable (typically simple
> segregated storage).
I think this is another good reason for adding support for node allocation.
Marcelo
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Wed, 27 Jan 2016 18:45:42 -0200
Raw View
I would like to thank you all for the valuable feedback. There are
many points in my proposal that need improvements. I will fix them and
come back for a second round.
Best,
Marcelo
2016-01-27 18:39 GMT-02:00 Marcelo Zimbres <mzimbres@gmail.com>:
> 2016-01-24 18:55 GMT-02:00 Ion Gazta=C3=B1aga <igaztanaga@gmail.com>:
>
>> One reason for a different name (it's a matter of taste) is that functio=
n
>> names should reflect that both operations have different semantics, apar=
t
>> from the storage size.
>
> I do agree.
>
>> If memory expansion (realloc) is added in the future,
>> it should only work with storage allocated with allocate(n) but not with
>> storage allocated for nodes. This allows node allocations to avoid extra
>> bookeeping data to mark the storage as non-expandable (typically simple
>> segregated storage).
>
> I think this is another good reason for adding support for node allocatio=
n.
>
> Marcelo
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 28 Jan 2016 09:33:57 +0800
Raw View
--Apple-Mail=_91D3FF87-91A9-42AB-B0B3-B70EA110A5A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9325, at 6:46 AM, Marcelo Zimbres <mzimbres@gmai=
l.com> wrote:
>=20
> If libraries begin to get static information from max_size i.e.
> whether its 1 or not, than all custom allocators that implement
> max_size as non-constexpr would be broken (static information cannot
> be read out of them).
I suggested constexpr max_size only as an alternative to adding the use_nod=
e_allocation member. Both would add the same static information. Both impos=
e the same awareness requirement on libraries. (When I characterized this a=
s a breaking change, you disagreed. But now you=E2=80=99re saying the same =
thing.)
To be clear, neither should be necessary if node classes are tagged as oppo=
sed to node allocators, and we=E2=80=99re allowed the assumption that array=
allocation of a node class never happens. This approach seems much more ec=
onomical.
> n is a runtime parameter that can take any value, so I cannot simply
> assume that n =3D 1 always, on all c++ libraries. It is definitely not
> portable to rely on that. That said, yes, I have never seen anyone
> using n !=3D 1.
This seems like a pretty critical detail. Things can be a lot simpler if n!=
=3D1 is ruled out for node-based containers.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_91D3FF87-91A9-42AB-B0B3-B70EA110A5A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=
=E2=80=9325, at 6:46 AM, Marcelo Zimbres <<a href=3D"mailto:mzimbres@gma=
il.com" class=3D"">mzimbres@gmail.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><div class=3D"">If libraries begin t=
o get static information from max_size i.e.<br class=3D"">whether its 1 or =
not, than all custom allocators that implement<br class=3D"">max_size as no=
n-constexpr would be broken (static information cannot<br class=3D"">be rea=
d out of them). </div></div></blockquote><div><br class=3D""></div><div>I s=
uggested <font face=3D"Courier" class=3D"">constexpr max_size</font> only a=
s an alternative to adding the <font face=3D"Courier" class=3D"">use_node_a=
llocation</font> member. Both would add the same static information. Both i=
mpose the same awareness requirement on libraries. (When I characterized th=
is as a breaking change, you disagreed. But now you=E2=80=99re saying the s=
ame thing.)</div><div><br class=3D""></div><div>To be clear, neither should=
be necessary if node <i class=3D"">classes</i> are tagged as opposed to no=
de <i class=3D"">allocators</i>, and we=E2=80=99re allowed the assumption t=
hat array allocation of a node class never happens. This approach seems muc=
h more economical.</div><br class=3D""><blockquote type=3D"cite" class=3D""=
><div class=3D""><div class=3D"">n is a runtime parameter that can take any=
value, so I cannot simply<br class=3D"">assume that n =3D 1 always, on all=
c++ libraries. It is definitely not<br class=3D"">portable to rely on that=
.. That said, yes, I have never seen anyone<br class=3D"">using n !=3D 1.<br=
class=3D""></div></div></blockquote></div><br class=3D""><div class=3D"">T=
his seems like a pretty critical detail. Things can be a lot simpler if&nbs=
p;<font face=3D"Courier" class=3D"">n!=3D1</font> is ruled out for nod=
e-based containers.</div><div class=3D""><br class=3D""></div></body></html=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_91D3FF87-91A9-42AB-B0B3-B70EA110A5A6--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Thu, 28 Jan 2016 17:41:00 -0200
Raw View
2016-01-27 23:33 GMT-02:00 David Krauss <potswa@gmail.com>:
>
> On 2016=E2=80=9301=E2=80=9325, at 6:46 AM, Marcelo Zimbres <mzimbres@gmai=
l.com> wrote:
>
> If libraries begin to get static information from max_size i.e.
> whether its 1 or not, than all custom allocators that implement
> max_size as non-constexpr would be broken (static information cannot
> be read out of them).
>
>
> I suggested constexpr max_size only as an alternative to adding the
> use_node_allocation member. Both would add the same static information. B=
oth
> impose the same awareness requirement on libraries. (When I characterized
> this as a breaking change, you disagreed. But now you=E2=80=99re saying t=
he same
> thing.)
>
> To be clear, neither should be necessary if node classes are tagged as
> opposed to node allocators, and we=E2=80=99re allowed the assumption that=
array
> allocation of a node class never happens. This approach seems much more
> economical.
I will implement your ideas on my project before I push my proposal
forward. That way we can compare the better approach.
> n is a runtime parameter that can take any value, so I cannot simply
> assume that n =3D 1 always, on all c++ libraries. It is definitely not
> portable to rely on that. That said, yes, I have never seen anyone
> using n !=3D 1.
>
>
> This seems like a pretty critical detail. Things can be a lot simpler if
> n!=3D1 is ruled out for node-based containers.
This is what I think. If rule out is not possible, I would at least
like to switch off array allocations inside node-based containers. For
reference, my first thoughts on this problem are on this thread in
C++-embedded:
http://www.open-std.org/pipermail/embedded/2014-December/000335.html
Best,
Marcelo
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.