|
Boost : |
Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-03-02 10:29:01
Matt Calabrese skrev:
> On Mon, Mar 2, 2009 at 9:42 AM, Mathias Gaunard <
> mathias.gaunard_at_[hidden]> wrote:
>
>> With VLAs, the buffer is on the stack whatever the capacity. With
>> auto_buffer, the buffer is on the stack only if the capacity is smaller than
>> N (which you define to be 256 by default).
>>
>
> I am wondering if there should be a default at all for N here as it seems
> like it is not really possible to make a good decision as to what that
> default value should be at the library level. If anything, I'd suggest at
> least having the default value able to be easily changed by users of the
> library with a #define. That raw, magic 256 at such a level is just a little
> scary to me.
I'm more scared by a #define that at the 256 default.
Different users (or different library implementers)
can make their own decision regarding this based on domain specific
knowledge.
For example, Boost.Format might conjecture that 99% of all strings are
less than 350 chars, and so use
boost::auto_buffer<char,350>
OTOH, in my custom project where we work with NP-Hard graph problems,
I know that N=64 is the maximum possible vertex set size I can handle.
So I can use
boost::auto_buffer<unsigned,64>
-------------------
One might speculate if the default should be the number of elements of
the stack buffer, or the total size of the stack buffer. If somebody
wrote
boost::auto_buffer< boost::array<T,100> > buffer;
this would consume quite much stack space.
Alternatively we might try to compute a reasoable default size
based on the size of the type and based on minimum and maximum default
sizes.
-Thorsten
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk