Re: [boost] [Preprocessor] Adding variadic macros support

Subject: Re: [boost] [Preprocessor] Adding variadic macros support
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-11-27 16:55:08

On Sat, Nov 27, 2010 at 11:57 AM, Edward Diener <eldiener_at_[hidden]>wrote:

> What are the chances that you would be willing to propose Chaos for Boost
> even though it would work with only a subset of compilers, and specifically
> not with VC++ ? I personally think this would still be valuable for the
> authors of Boost libraries and for end-users, but I could understand your
> unwillingness to do so or other Boost developers and/or end-users
> unwillingness to accept Chaos into Boost because it does not work for a
> number of C++ compilers. But IMO that Chaos would provide easier
> preprocessing programming for even a subset of C++ implementations would
> make it worth using.
>

Seconding this. I know that not supporting VC++ is a no-go, but I'd hope
that we could make an exception here. Boost is intended to target
standards-compliant compilers, and if VC++ is horribly broken in one area
then it's their problem. If Chaos were accepted, Boost.Preprocessor should
likely still exist for backwards compatibility and for non-compliant
preprocessors. Chaos would just be pushed as the main preprocessor
metaprogramming library whereas the Boost.Preprocessor library as a whole
would then be considered one big workaround. Just as Boost.Function has the
interface workaround for compilers that can't handle the function type form,
Chaos would have Boost.Preprocessor.

Also, while Microsoft has said in the past that they have no plans to fix
their preprocessor I wouldn't consider that to be the final word, no matter
how many times they say it. Perhaps if a library like Chaos were in Boost
their sentiment would change -- it wouldn't be the first time Boost has had
such an effect. I understand that they don't want to break code that used to
work, but even that can be dealt with if they really wanted to. For
instance, I'd imagine that it should be possible for them to make pragmas
that affect how macro definitions would be treated by the preprocessor. By
default everything would work in the old, broken way, but if a library like
Chaos were to need more compliant preprocessing then it could "push" a flag
specifying more compliant behavior before its macro definitions and then
"pop" at the end of the header. Any macro definitions that were written with
the compliant preprocessor activated would work as expected when invoked
(regardless of what flags are set at the call-site) and any macros that were
written without it would exhibit the old, broken behavior upon invocation,
meaning that everyone's old code would still work right out of the box. This
also lets people use their non-compliant code in the same translation unit
as a library like Chaos without the user ever having to deal with specifying
different compiler options or pragmas himself. Whether or not Microsoft
would actually take the time to do something such as that is questionable,
but until a library like Chaos is in Boost I'd imagine the chances are much
less.

Out of curiosity, just how much of Chaos can VC++ handle at this point? Is
it really entirely unusable as in almost nothing is supported? Is it all of
the looping constructs?

If lambdas are syntactically easier to use I would still encourage you to
> keep them in Chaos. While I am never against techniques which increase
> compile-time speed I strongly feel that ease of use in programming is far
> more important than waiting longer for a compilation to finish.
>

Again, seconding this. Unless we are talking about an order of magnitude
difference I'd imagine that the use of lambdas outweigh the cost.
Particularly when prototyping, it is a huge advantage to be able to quickly
write concise code that works. I've been doing a relatively large amount of
preprocessor metaprogramming lately (the libraries I've been working on,
AutoFunction and Generic, are now about 17,000 lines combined, the vast
majority of which are internal macros used in the implementation of just a
handful of top-level macros) and I'd likely be able to go much faster with a
library such as Chaos. Once all my tests were passing I could go back and
replace lambda expressions with hand-written macros if compile times proved
to be a problem. At the moment I find myself constantly rewriting small
portions of code during development that ends up being fairly tedious due to
the amount of boiler-plate that is necessary when working with
Boost.Preprocessor.

So, please, submit Chaos for review. I don't know how many other people feel
about the problem of supporting non-compliant compilers, but I think the
benefits are too numerous for a library like Chaos, especially given that
preprocessor metaprogramming is sort of niche anyway.

-- 
-Matt Calabrese