Boost logo

Boost :

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.!*

Boost list run by bdawes at, gregod at, cpdaniel at, john at