------=_Part_37_11268377.1354124349216
Content-Type: text/plain; charset=ISO-8859-1

With the new stateful allocators in C++11, there are lots of new options to
customize the allocation methods of Standard containers. But there are a
couple of points where it falls just a smidgeon short.

Firstly, the requirements on Standard containers should not specify their
default allocator. This will make it easier for implementations to
implement memory-related optimizations. For example, it's fairly evident
that a node-based container like set or list would usually be better off
with a pool allocator by default than the general-purpose allocator in most
cases. This could be a speedup of many existing programs for free by
creating more efficient memory allocators.

Secondly, the Standard should include allocators that are optimized for
different use cases. This should be an object pool (allocates only objects
of a fixed size), a memory arena (deallocates everything in one go), and a
small object allocator. There are existing implementations of these
allocators in Boost, except arena, which I have implemented myself, so
plenty of existing implementation here. Also for consideration should be a
thread-local allocator, or an allocator intended specifically for
concurrent allocation, such as the ones found in the PPL and TBB, and
possibly other kinds of allocators if necessary.

Thirdly, the allocator interface should be extended to include a realloc()
function. The prototype is

bool realloc(pointer p, std::size_t original_size, std::size_t new_size);

The realloc function will attempt to expand the memory block pointed to by
p, of size original, in place, to the new size. If it cannot, it returns
false- else, it returns true. The realloc function shall never copy any
memory or deallocate any memory. As the conditions for realloc()'s success
are implementation-specific, any allocator which cannot reallocate should
simply return false, always. Perhaps some SFINAE mechanism could be used to
always return false, for allocators which do not define realloc() due to
being legacy.

Finally, I think that, logically, there's little reason for new to always
decay to a call to the global ::operator new(size). If a class has
overloaded operator new, then that should be used, but I think that there
should be room for implementations to use other allocation functions.
Particularly, a new T(); expression might be better served by a pool
allocator than the regular operator, as the size and alignment of T is
fixed at compile-time, and this would be especially true if T is something
like an SSE type where the general-purpose allocator doesn't really work,
as the alignment requirements are too high- or any other implementation
magic. However, I'm currently unsure if this would constitute a breaking
change, depending on the answer here<https://groups.google.com/a/isocpp.org/d/topic/std-discussion/i28_82N-smE/discussion>
..

--




------=_Part_37_11268377.1354124349216
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

With the new stateful allocators in C++11, there are lots of new options to=
 customize the allocation methods of Standard containers. But there are a c=
ouple of points where it falls just a smidgeon short.<div><br></div><div>Fi=
rstly, the requirements on Standard containers should not specify their def=
ault allocator. This will make it easier for implementations to implement m=
emory-related optimizations. For example, it's fairly evident that a node-b=
ased container like set or list would usually be better off with a pool all=
ocator by default than the general-purpose allocator in most cases. This co=
uld be a speedup of many existing programs for free by creating more effici=
ent memory allocators.</div><div><br></div><div>Secondly, the Standard shou=
ld include allocators that are optimized for different use cases. This shou=
ld be an object pool (allocates only objects of a fixed size), a memory are=
na (deallocates everything in one go), and a small object allocator. There =
are existing implementations of these allocators in Boost, except arena, wh=
ich I have implemented myself, so plenty of existing implementation here. A=
lso for consideration should be a thread-local allocator, or an allocator i=
ntended specifically for concurrent allocation, such as the ones found in t=
he PPL and TBB, and possibly other kinds of allocators if necessary.</div><=
div><br></div><div>Thirdly, the allocator interface should be extended to i=
nclude a realloc() function. The prototype is</div><div><br></div><div>bool=
 realloc(pointer p, std::size_t original_size, std::size_t new_size);</div>=
<div><br></div><div>The realloc function will attempt to expand the memory =
block pointed to by p, of size original, in place, to the new size. If it c=
annot, it returns false- else, it returns true. The realloc function shall =
never copy any memory or deallocate any memory. As the conditions for reall=
oc()'s success are implementation-specific, any allocator which cannot real=
locate should simply return false, always. Perhaps some SFINAE mechanism co=
uld be used to always return false, for allocators which do not define real=
loc() due to being legacy.</div><div><br></div><div>Finally, I think that, =
logically, there's little reason for new to always decay to a call to the g=
lobal ::operator new(size). If a class has overloaded operator new, then th=
at should be used, but I think that there should be room for implementation=
s to use other allocation functions. Particularly, a new T(); expression mi=
ght be better served by a pool allocator than the regular operator, as the =
size and alignment of T is fixed at compile-time, and this would be especia=
lly true if T is something like an SSE type where the general-purpose alloc=
ator doesn't really work, as the alignment requirements are too high- or an=
y other implementation magic. However, I'm currently unsure if this would c=
onstitute a breaking change, depending on the answer&nbsp;<a href=3D"https:=
//groups.google.com/a/isocpp.org/d/topic/std-discussion/i28_82N-smE/discuss=
ion">here</a>.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_37_11268377.1354124349216--

.