Re: [boost] [utility] new auto_buffer class --- RFC

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2009-03-02 14:12:52

On Mon, Mar 2, 2009 at 11:19 AM, Frank Mori Hess <frank.hess_at_[hidden]>
 wrote:

> If a user wanted the default stack capacity for some auto_buffer to be set
> via
> macro, couldn't they just do
>
> boost::auto_buffer<int, DEFAULT_CAPACITY> buf;

One could say the same for default function or template arguments in any
context. Of course you could always have the user explicitly pass a
"default" with every use, but that in many ways defeats the purpose of
having a default to begin with. If in the general sense it is an
implementation detail, especially one which may require knowledge of the
underlying implementation to set "correctly," an appropriate implicit
default is much better than having a user explicitly specify the same
constant over and over. A general user should not have to be concerned with
explicitly passing the default around. I do, however, agree that no default
is better than a fixed 256 default. It should be easily customizable if need
be.

Direct support for a #define makes it easy for users to have some
implementation-defined default during the development and
then non-intrusively be able to go back and tweak the default if it turns
out to be a problem. They can always wrap auto_buffer or use metafunction
calls, etc. but those both require unnecessary effort to simply configure a
default, where in most compilers configuring it via a #define means simply
passing a command line argument. It also makes it easy for someone to go
back and change the default if throughout their code they were using
auto_buffer directly rather than a wrapper, but then later on in development
realized that the default was insufficient for their needs. Without the
#define, you pretty would always be wrapping auto_buffer or explicitly
passing a default everywhere in order to be "future-safe" if there is any
chance that you may need to change the default for some reason (I.E.
compiling for a platform where you have a much smaller stack).

On Mon, Mar 2, 2009 at 11:18 AM, Felipe Magno de Almeida <
felipe.m.almeida_at_[hidden]> wrote:

> I rather have no default at all. It avoids ODR violations by defining
> different
> defaults for different libraries, and there's no reason why one number
> would
> be a better default than the other.
> If someone wants to create a specific default, it can derive from
> auto_buffer.

Doesn't a similar issue exist with certain other libraries in boost that
offer customization of limits? You have to be careful to not violate ODR
with any kind of configuration like this, but the functionality is at least
still there. To be clear, I wouldn't propose supporting the use of different
macro definitions in the same program, for that you should fall back to
using a meta function or template alias, etc. This is intended for
per-program use.

As well, you can error on at least some issues that may arise by having
the namespace the template is defined in be dependent on the value of the
#define, then pull that template into namespace boost via using to allow
easy usage. This has the benefit of making calls not link if a function is
defined in one translation unit with one #define but invoked from another
translation unit with another #define since the namespace the "using"
resolves to would be different in each case.

Example:
_____________________

namespace boost { namespace BOOST_PP_CAT( auto_buffer,
BOOST_AUTO_BUFFER_DEFAULT_SIZE ) {

// Definition here

}

using BOOST_PP_CAT( auto_buffer, BOOST_AUTO_BUFFER_DEFAULT_SIZE
)::auto_buffer;

}

_____________________

It's still hairy overall and the user should again avoid using 2 different
defines in the same program, but at least a way is offered to specify a
default. If no one else is with me on this, I am in support of no default at
all rather than a fixed one.

-- 
-Matt Calabrese