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

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2009-03-02 11:19:14

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 02 March 2009, Matt Calabrese wrote:
> Hmm? Why is that? On the contrary, I would say a #define here is simply
> good practice. A raw 256 is only providing a default at a level where you
> have little-to-no knowledge of what such a default should be. Allowing the
> default to be overridden via a #define lets a user easily override that
> value based on his own requirements, and do so without having to directly
> modify any boost code (often just from command line arguments to the
> compiler or from project settings in an IDE) and without having to use a
> metafunction/template alias/wrapper to make a new default for his or her
> domain. I see all of this as much more preferable to a strict default value
> of 256.
>
> I'm all about avoiding the preprocessor when there are better alternatives,
> but here it seems to be the ideal solution and offers the most flexibility
> at no cost.

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;

where DEFAULT_CAPACITY is the macro?  That would seem to be more flexible, as 
you could define multiple macros used by different auto_buffers that serve 
different purposes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmsBwIACgkQ5vihyNWuA4WBpQCfZaGxJjvHrAiT3nKMgA9JQBCP
Y08AniaUQeEiZTNjDgcfQ8uUbXpFqrQy
=EWeO
-----END PGP SIGNATURE-----