On Mon, Mar 2, 2009 at 11:19 AM, Frank Mori Hess <frank.hess@nist.gov> 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@gmail.com> 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