On Nov 27, 4:09 pm, Stephen Howe
<sjhowe...@dialREM.pipexREM.coREM.ukREM> wrote:
On Sat, 06 Nov 2010 21:11:19 -0400, "Daniel T." <danie...@earthlink.net> wrote:
Either the committee should take shrink_to_fit out of deque's interface,
or it should also add reserve() and capacity() to deque.
Doesn't this make sense to you?
It make sense to me. I think reserve() and capacity() should be added to deque.
But I also think shrink_to_fit() should be added to all the other containers.
A std::list could easily have a pointer to deleted nodes for
a list object, waiting to be recycled in the event of an
insert(). shrink_to_fit() would make the number of deleted
nodes 0.
I would think such an implementation of a basic standard-library
doubly linked list would be rather perverse. Sure, it's not illegal by
standard, but I still think that's definitely not what a coder wants
or intends when he uses a std::list. "Caching", if I may use the term,
for vector and deque makes sense. That makes push_back amortized
constant time work. Caching nodes inside of a specific list object
doesn't make much sense to me as a general purpose container. It seems
to be a rare use case which requires that, and it seems a job better
suited to the template argument allocator of the list.
nodes, only going to the system for larger blocks. A reserve()