map::reserve

[Liran Shaul]

I was wondering:
how come the stl map class does not have a reserve function like the
useful vector::reserve function?

I was thinking about implementing my own reserve class, by providing
my own allocator, inherting a new class from map, and add it a reserve
function that will work on my allocator and ask it to reserve memory
for future use.
however, I don't know how to call the map's Allocator instance in
order to reserve the memory. can anyone please help?

thanks,

liran

[David Hilsee]

Re: map::reserve

"Liran Shaul" <liransh@gmail. com> wrote in message
news:4c75c088.0 410160821.496b3 752@posting.goo gle.com...[color=blue]
> I was wondering:
> how come the stl map class does not have a reserve function like the
> useful vector::reserve function?[/color]

When a std::vector reallocates its storage, it can be a very costly
operation. A simple call to push_back() may cause every element in the
std::vector to be copied to a newly allocated block of memory. A call to
reserve() can avoid these unnecessary allocations and copy operations.
std::map, on the other hand, never needs to copy all of the
existing/remaining elements simply because a new element was inserted or
removed.
[color=blue]
> I was thinking about implementing my own reserve class, by providing
> my own allocator, inherting a new class from map, and add it a reserve
> function that will work on my allocator and ask it to reserve memory
> for future use.
> however, I don't know how to call the map's Allocator instance in
> order to reserve the memory. can anyone please help?[/color]

Every container has a "get_alloca tor" member function that returns a copy of
its allocator. You might be able to come up with something that retrieves
the allocator and gives it a "hint" that the map will grow in size (like
"myMap.get_allo cator().reserve (...)"), but the effort may not pay off
performance-wise. If std::map's allocations are a performance bottleneck,
then I could see how that might be a reasonable approach to make your
application faster.

--
David Hilsee

[John Harrison]

Re: map::reserve

>[color=blue]
> Every container has a "get_alloca tor" member function that returns a copy
> of
> its allocator. You might be able to come up with something that retrieves
> the allocator and gives it a "hint" that the map will grow in size (like
> "myMap.get_allo cator().reserve (...)"), but the effort may not pay off
> performance-wise. If std::map's allocations are a performance bottleneck,
> then I could see how that might be a reasonable approach to make your
> application faster.
>[/color]

Sounds like a pool allocator might be a better solution to the OP's problem.

http://www.boost.org/libs/pool/doc/index.html

john

[David Hilsee]

Re: map::reserve

"John Harrison" <john_andronicu s@hotmail.com> wrote in message
news:2tehtfF1tq 8nvU1@uni-berlin.de...[color=blue][color=green]
> >
> > Every container has a "get_alloca tor" member function that returns a[/color][/color]
copy[color=blue][color=green]
> > of
> > its allocator. You might be able to come up with something that[/color][/color]
retrieves[color=blue][color=green]
> > the allocator and gives it a "hint" that the map will grow in size (like
> > "myMap.get_allo cator().reserve (...)"), but the effort may not pay off
> > performance-wise. If std::map's allocations are a performance[/color][/color]
bottleneck,[color=blue][color=green]
> > then I could see how that might be a reasonable approach to make your
> > application faster.
> >[/color]
>
> Sounds like a pool allocator might be a better solution to the OP's[/color]
problem.[color=blue]
>
> http://www.boost.org/libs/pool/doc/index.html[/color]

I agree. I only mentioned a reserve() member function on an allocator to
indulge the OP's idea.

--
David Hilsee