Re: # [boost] Preprocessor: compiler/library/user bug?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-10-09 02:50:02

----- Original Message -----
From: "Vesa Karvonen" <vesa_karvonen_at_[hidden]>

[...]
> > BOOST_PP_CAT(other.d_,PPV_NAME(I))
[...]

> Wouldn't it be logical to assume that BOOST_PP_REPEAT has, in fact, been
> used on the compiler in question before - without getting warning
messages?

Yes, but not necessarily BOOST_PP_CAT with multiple-token arguments.

> Wouldn't it be logical then to look for the cause of the warning in the
> parameters passed to BOOST_PP_REPEAT rather than in BOOST_PP_REPEAT?

Yes, which is why I said (and I quote)--what happens when you do this by
itself?

#define X(I) BOOST_PP_CAT(other.d_,PPV_NAME(I))
X(0) // ?

> (It was my intention to point out the only code snippet, that has some
> correlation with the error message.)

Okay, I misunderstood.  I thought you were implying that the code was
invoking undefined behavior.  You didn't exactly explain what you were
saying in that message. :)

> Wouldn't it be good engineering practice to test whether the above code
does
> indeed cause the warning message, or is the warning message caused by
> BOOST_PP_REPEAT or something else?
>
> (I can't perform this test, because I don't have the compiler in
question.)

Neither can I.

> If you are indeed correct, and the compiler in question does indeed
> incorrectly emit the warning for the code that I pointed out, then
wouldn't
> it be good engineering practice to file a defect report to the compiler
> vendor?

Yes, but the problem needs to be isolated--i.e. what's the difference
between BOOST_PP_CAT(class T, 0) and BOOST_PP_CAT(a.b, 0), etc..  This has
to be tested by someone with access to that preprocessor.  Also, the
preprocessor in question doesn't outright error, it just emits a warning and
does the right thing--which, although annoying, is better than nothing.

If, for example, BOOST_PP_CAT(class T, 0) causes the same warning, then a
much broader fix to the preprocessor is necessary.  I'd classify that as a
faulty feature set rather than a bug.  If, however, BOOST_PP_CAT(class T, 0)
doesn't cause a warning, than I'd see if the warning only reared its head
when operators (such as .) are involved or just '.' specifically.  If it's
just the period or only happens in certain border cases, I'd call it a bug.
Otherwise, I'd call it a non-standard implementation--but only in the sense
that it emits a bogus warning message.

Incidentally, the warning can be bypassed easily enough in this case anyway:

other.BOOST_PP_CAT(d_, PPV_NAME(I))

..rather than..

BOOST_PP_CAT(other.d_, PPV_NAME(I))

Paul Mensonides