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

Subject: Re: [boost] [Preprocessor] Adding variadic macros support
From: Hal Finkel (half_at_[hidden])
Date: 2010-11-27 22:10:49

On Sat, 2010-11-27 at 16:55 -0500, Matt Calabrese wrote:
> 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.
> 

I agree, especially since one can generally use an external
(standards-compliant) preprocessor with your compiler of
choice/necessity, you just need to change your build procedure. Was this
not one of the motivating factors behind Wave in the first place?
Furthermore, libraries like Boost.MPL which provide pre-preprocessed
headers essentially use an external preprocessor anyway.

 -Hal