|
|
Boost : |
From: Jaakko Jarvi (jajarvi_at_[hidden])
Date: 2002-10-10 09:45:43
Posting on behalf of Ellis Cohen,
---------- Forwarded message ----------
Date: Wed, 09 Oct 2002 15:06:10 -0700
From: Ellis Cohen <ellisc_at_[hidden]>
> Date: Tue, 8 Oct 2002 15:12:01 -0700
> From: "Paul Mensonides" <pmenso57_at_[hidden]>
> To: "Boost mailing list" <boost_at_[hidden]>
> Subject: Re: [boost] Preprocessor: compiler/library/user bug?
>
> > #define BOOST_PP_DEF(I,_) BOOST_PP_COMMA_IF(I)
> BOOST_PP_CAT(d_,PPV_NAME(I))(BOOST_PP_CAT(other.d_,PPV_NAME(I)))
> > BOOST_PP_REPEAT(FOO_CNT, BOOST_PP_DEF, _)
> > #undef BOOST_PP_DEF
>
> All of this looks fine except it needs to be updated slightly to
> work with 1.29.
> As far as the 1.28 interface is concerned, the code is fine.
> What happens when
> you do this by itself:
>
> #define X(I) BOOST_PP_CAT(other.d_,PPV_NAME(I))
>
> X(0) // ?
Result is exactly the same -- the diagnostic message is
Warning (anachronism) 823: "boost_bug.C", line 23 # Redundant preprocessing
concatenation operation results in two valid preprocessing tokens. Depending
on this implementation defined behavior will result in non-portable code.
X(0)
^
but the output is correct --
other.d_some_value
> To update the above code to 1.29, you have to add an extra parameter to
> BOOST_PP_DEF in the above (then you can ignore it):
>
> #define BOOST_PP_DEF(Z,I,_) BOOST_PP_COMMA_IF(I) ...
I'll keep it in mind, but I can't move to 1.29 just now.
------------------------------
> Date: Wed, 09 Oct 2002 09:49:00 +0300
> From: "Vesa Karvonen" <vesa_karvonen_at_[hidden]>
> To: boost_at_[hidden]
>
> > > preprocessing concatenation operation results in two valid
> > > preprocessing tokens
> [...]
> > > BOOST_PP_CAT(other.d_,PPV_NAME(I))
> [...]
> Paul Mensonides:
> >It is a valid concatenation of the preprocessing token "d_" and the
> >preprocessing token "some_value" that yields the single, valid
> >preprocessing token "d_some_value". "other." shouldn't matter
> >anymore.
>
> 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?
It would be logical, but it would be incorrect. My problem description is
based on the first use of the Boost preprocessor library for a particular
project with this compiler, and there is no prior history.
> 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?
>
> (It was my intention to point out the only code snippet, that has some
> correlation with the error 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 had no prior history with the Boost preprocessor library.
I'm just coming "up-to-speed" on Boost, and I didn't know
along which axes to explore variations, to try and isolate
the cause of the diagnostic.
> (I can't perform this test, because I don't have the compiler in question.)
>
> 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?
>
> -Vesa Karvonen
------------------------------
> Date: Wed, 9 Oct 2002 00:50:02 -0700
> From: "Paul Mensonides" <pmenso57_at_[hidden]>
> To: "Boost mailing list" <boost_at_[hidden]>
> Subject: Re: # [boost] Preprocessor: compiler/library/user bug?
>
> ----- 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) // ?
See above.
> > (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.
Some test results:
BOOST_PP_CAT(class T, 0)
Warning (anachronism) 823: "boost_bug.C", line 24 # Redundant preprocessing
concatenation operation results in two valid preprocessing tokens. Depending
on this implementation defined behavior will result in non-portable code.
BOOST_PP_CAT(class T, 0)
^^^^^^^^^^^^
class T0
BOOST_PP_CAT(other.d_, fred)
Warning (anachronism) 823: "boost_bug.C", line 26 # Redundant preprocessing
concatenation operation results in two valid preprocessing tokens. Depending
on this implementation defined behavior will result in non-portable code.
BOOST_PP_CAT(other.d_, fred)
^^^^^^^^^^^^
other.d_fred
BOOST_PP_CAT(a.b, 0)
Warning (anachronism) 823: "boost_bug.C", line 28 # Redundant preprocessing
concatenation operation results in two valid preprocessing tokens. Depending
on this implementation defined behavior will result in non-portable code.
BOOST_PP_CAT(a.b, 0)
^^^^^^^^^^^^
a.b0
In all three cases, the result is as desired, but the diagnostic is still output
by the compiler.
> 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))
I did try this modification, and it did stop the diagnostic messages.
Ellis Cohen
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk