Subject: Re: [boost] [preprocessor] [config] Support for variadic macros
From: Wolf Lammen (ookami1_at_[hidden])
Date: 2010-08-06 09:58:44
> > Variadic macros are part of the C99 standard. Judging from the
> > preprocessor sources, their developers Mr Mensonides (and perhaps Mr
> > Karvonen) seem to have painfully avoided breaking any rule of the
> > C90 standard. For example, there are never empty macro arguments
> > passed, although this would have simplified code in several instances.
> > So, using variadic macros will break downward compatibility.
> I'm not sure I understand what you are saying.
Well, perhaps I should have written: Variadic macros are covered by C99 or later only, not by C90. So, whereever you want to introduce them, you have to provide a parallel C90 implementation, unless you want to exclude all non C99 conformant compilers.
IMHO, if you use variadic macros to optimize internal processing for a subset of compilers, this is ok. But you must not expose them on the outside interface of BOOST_PP (such as to declare a new type), because that wouldn't be portable.
And I am not sure whether BOOST_PP_ARRAY already covers much of the preprocessor type you had in mind.
> I wasn't suggesting to use variadic macros in BOOST_PP_TUPLE_*, I
> meant new macros _like_ BOOST_PP_TUPLE_*.
> there are only 6 or so TUPLE macros, and their predominant use is
> probably: converting a tuple to a sequence.
Side note: I noticed they are often used as a sort of preprocessor struct, where you have cheap random access to 'members'.
> that would effectively introducde a new "data type" to the PP library:
> a variadic tuple.
> I'm sure I'm not the first to suggest this, but with the workaround
> submitted to that microsoft site MSVC can be supported (along with all
> compilers implementing (conforming) C99 variadic macros)
> > If you think it is time to leave C90 behind, it might be worth
> no I don't.
-- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 Â¿/mtl.!* http://portal.gmx.net/de/go/dsl
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk