RE: [boost] Re: Suggestion to change a config.hpp macro

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-03-13 06:32:05

Daryle Walker wrote:
> Using a ',' over a '=' is more than looks; the ',' would go 
> in the macro as an argument separator. The '=' is a convention 
> that the user would have to maintain themselves. 

May be it's just a poor wording, but for me the above sentence doesn't make
any sense. The '=' is not a convention (a convention for what??);
BOOST_STATIC_CONSTANT macro takes 2 arguments - (1) a cv-unqualified type of
the constant and (2) its init-declarator; the '=' symbol is an essential
part of the init-declarator, and it is a "convention" to the same extent as
using the same character in the following code is:

void foo() {
  int i = 0; // ???
}

> The ',' is enforceable by the preprocessor; any
> mistakes with '=' would result in strange errors at 
> regular-compile-time

I don't see how using 3-arguments form is "enforceable by the preprocessor"
and how using the 2-argument one is not. It's true that if you provide not
enough arguments for a macro call, the compiler will say you about it, but
the same is if you will provide too many of them:

BOOST_STATIC_CONSTANT(bool, value, true); // error: too many arguments in
macro invocation
BOOST_STATIC_CONSTANT2(bool, value2 = true); // error: too few arguments in
macro invocation

And IMO the argument is ill-founded anyway, as the omitting the '=' token in
the init-declarator argument of BOOST_STATIC_CONSTANT is the same kind of
error as the omitting of it in any other place like the 'foo' function
above. With the same validity one can argue that BOOST_STATIC_CONSTANT2 is
error-prone because it provide poor/misleading diagnostics for the code like

BOOST_STATIC_CONSTANT2(bool, value2 = is_same<T1, T2>::value); //  Comeau
C/C++ 4.2.44, error: too few arguments for class template "is_same".

> I noticed that extra parentheses were needed in some 
> expressions because of precedence interactions between
> the '=' and the values that involved other operators. 

This is not true. Macros are unfolded using a simple text-substitution
mechanism, and whatever the number of the original macro's parameters is,

BOOST_STATIC_CONSTANT(bool, value = T::value | U::value); or
BOOST_STATIC_CONSTANT2(bool, value, T::value | U::value);

the resulting code will always look like

static bool const value = T::value | U::value;

and for such code the above (cited) statements don't make any sense.

> Since the comma is handled by the preprocessor, 
> the parentheses
> aren't needed.  (The parentheses aren't explicitly needed, my 
> version of the
> macro adds some automatically, so that can't be messed up either.)
> 

I am not sure that problem you are trying to solve here. The only situation
that requires using of parentheses in macro invocation I am aware about, is
when comma as a part of the initializer's assignment expression, e.g.

BOOST_STATIC_CONSTANT(bool, value = is_same<T1, T2>::value);
or
BOOST_STATIC_CONSTANT2(bool, value, is_same<T1, T2>::value);

and in this case ANY form of the macro will require the extra inner
parentheses around the causative expression:

BOOST_STATIC_CONSTANT(bool, value = (is_same<T1, T2>::value));
BOOST_STATIC_CONSTANT2(bool, value, (is_same<T1, T2>::value));

> I was just looking at the code and thinking "They divide it 
> into two parts, but there are really three parts.  

I see it differently. It's not like the number of macro parameters is
determined by the finest possible granularity of splitting the target
expression into parts; such approach often just don't make sense and in many
cases it also compromises readability/usability of the macro; IMO the
BOOST_STATIC_CONSTANT macro is exactly such case; I think that the
motivation for its current form is completely well-formed and that the
suggested alternative does not offer any claimed advantages over it, but
compromises its readability and expressiveness.

> I'm worried about sacrificing safety for readability.

There are no "safety" issues with the current form, so 

> I see it the other way.  I didn't know the macro was that 
> old; I thought it was brand new.  The newness would justify a quick 
> and total change, instead of lengthening the problem through a 
> transition period.  

I appreciate your concerns, but I still think they are unfounded. 

Aleksey