Re: container memory control for C++
Daniel Svensson ha scritto:
1; Default constructed containers as well as basic_string must not
allocate any memory.
Neither speed nor memory overhead should be forced upon stl users unless
needed. This would result in higer performace without inpact on existing
code.
This is a quality-of-implementation issue, which IMHO need not be
mandated by the standard. I expect any sensible library implementor to
already do that unless there is *very* good reason for doing otherwise
and in that case I say we should trust the implementor. BTW, I assume
with "memory" you mean "heap memory", because otherwise you would
actually forbid techniques like the "small string optimization".
2; I would like to see the following functionallity available for
containers like vector and dequ.,
deque do not have a concept of capacity. Providing these functionalities
may actually hinder the implementation of deque without a significant
gain. I would consider them only for vectors.
- function: void set_capacity(size_t n);
- postcondition: (capacity() == n)
Works as reserve when n >= size().
When n<size() the conatiner will shrink and the new size will be
min(n,size()).
Notice that calling reserve(n) actually has the post-condition
capacity() >= n and changing the size won't change the capacity. So if
you want the == in the post-condition you need to be more explicit in
the definition.
Frankly, I don't find this one so useful, because it's too general. I
have never encountered a case where I would need such power (I guess
that 99.9% of the times all you need is trim(), below). Moreover, I find
it error prone, because it has a completely different semantic according
to n being less than greater than size() (it destroys elements in the
former case but does not add elements in the latter!).
Better force the programmer to make a explicit choice, as in:
if(n < v.size())
v.resize(n);
else
v.reserve(n);
- function: void free();
- postcondition: (size() == capacity() == 0)
This would be the same as calling set_capacity(0);
The EASTL version is named reset, but free reflects it's intention better.
I agree that it is useful, as it essentially replaces the hackish
swap-trick. I don't like the name free() as it sounds more like a noun
to me (like empty(), which actually sounds like a verb ;). reset() is
better because it's used with a similar semantic in smart pointers, that
can be seen as degenerate containers.
3; The following functionality would also be useful, but not as much as
those already discussed.
- function: void trim();
- postcondition: (capacity() == size())
This is the same as calling container.set_captacity( container.size() );
This looks actually more useful than set_capacity(), because it covers
the most common scenario and is not error prone. It replaces the "second
form" of the swap trick "std::vector<T>(v).swap(v)", but it's more
efficient because it would exploit move constructors, while the swap
trick would always make copies.
Just my two eurocent,
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]