From: Daryle Walker (darylew_at_[hidden])
Date: 2001-03-12 16:25:11
on 3/12/01 1:37 AM, Aleksey Gurtovoy at alexy_at_[hidden] wrote:
> Daryle Walker wrote:
>> My question is: why do we make the user explicitly add the "="? What's wrong
>> with (excuse any line-wrap my e-mail client adds):
> A counter question - what's wrong with '='? You either have to write ',' or
> '=', and IMO '=' is much more appropriate here.
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. The ',' is enforceable by the preprocessor; any
mistakes with '=' would result in strange errors at regular-compile-time. I
noticed that extra parentheses were needed in some expressions because of
precedence interactions between the '=' and the values that involved other
operators. 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.)
>> Is there some subtle point of macro definitions that keeps this from working,
>> or did we make a silly oversight?
> It's not an oversight, it's the explicit choice; before I wrote the original
> BOOST_MPL_STATIC_CONSTANT macro that was a prototype of the one Dave later
> added to 'config.hpp', I was experimenting with both forms, and I found '='
> form to be more explicit and natural. As Dave already mentioned, it matches
> the "ideal" declaration of static member constant, and often it's more
I was just looking at the code and thinking "They divide it into two parts,
but there are really three parts. We could make the macro into three parts
so the relation between the second and third parts is enforced.".
>> If it was an oversight, can we change the macro to this form?
> If the only reason for the change asked is personal aesthetic preferences, I
> am against it. IMO the questioned using of '=' is well justified and using
> of ',' is not, so please leave it as is.
I'm worried about sacrificing safety for readability.
>> Yes, I know that I'm asking for an incompatible change, but the macro is only
>> a few days old, so I don't think that there's too much code to change.
> First, IMO there are no reasons for the change, and there are reasons
> against it. Second, the macro in its final form was added to 'config.hpp'
> about 4 weeks ago, and personally I've been using its prototype for more
> than 2 months. For me there are more important things to do in spare time
> than making quite a number of code changes that are not justified at all.
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've already
uploaded a sample that changes Boost to the new method; so the
implementation is not an issue. This wouldn't help if you have private code
using the macro, though.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk