|
Boost : |
From: Chris Jefferson (chris_at_[hidden])
Date: 2008-08-07 08:56:38
2008/8/7 joel falcou <joel.falcou_at_[hidden]>:
>
>
>> Because, like many buffers, in practice I find the maximum size is
>> often a run-time constant. It is possible to get most of the
> benefits of a
>> compile-time parameter constant with a
> compiletime_int (see end of
>> e-mail).
>
> Nice trick ! So
> I think this cover my worry on this subejct :)
>
>> a)
> Implementations of std::vector behave badly in tight memory
>>
> circumstances. <snip>
>
> I wonder if some of the STL
> container and/or assorted algorithm doesn't
> need a somewhat modern
> clean-up/rewrite or are they that much "holy" that
> we
> shouldn't/couldn't provide proper alternatives with backward compatibl
> interface.
Certainly I personally feel allocators were a mistake. They seem to be
designed to badly cover a number of poorly defined use cases, but
often not the use cases I often want.
Howard previously worked on an extension to allocators which would
have fixed the majority of these problems, in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1953.html .
However, this tragically seems to have died on the vine as C++0x
approaches.
Chris
>
>> b) When you have a container which holds
> few elements, it is nice to be
>> able to check how many things it
> can hold. <snip>
> That's indeed a problem
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk