bl**********@gmail.com wrote:
I'm not sure which part of Victor's post you're replying to, since you
didn't quote it. I'm guessing it is:
bluekite2...@gmail.com wrote: new/delete, std::allocator, pool_allocator or mt_allocator??? What
r the pros and cons if each method?
std::allocator uses new/delete (usually, could be slightly
different, depending on the implementation). I don't know what
pool_allocator or mt_allocator are (read: there are no such things
in the Standard C++).
Not according to gcc document,
You didn't say you wanted it to be gcc-specific. Besides, you're
wrong.
which states:
The easiest way of fulfilling the requirements is to call operator
new each time a container needs memory, and to call operator delete
each time the container releases memory. BUT this method is
horribly slow.
Or we can keep old memory around, and reuse it in a pool to save
time. The old libstdc++-v2 used a memory pool, and so do we. As of
3.0, it's on by default
That doesn't mean that libstdc++'s std::allocator doesn't use
new/delete. It just describes how it handles the memory it has
acquired with new, and when it decides to dispose of that memory with
delete.
PS: I m designing a matrix/tensor/vector lib, all of which call
base_constructor of class Array.
If you provide for pluggable allocators, like the STL implementation
whose documentation you quoted, then you can replace std::allocator
with something more specialised /if and when/ profiling shows it
necessary, for relatively minimal upfront effort.
Note that the optimal allocator may vary depending on the context in
which your library is used, so allowing the user to tailor this to
the app probably gives the most mileage anyway.