On Sat, Nov 27, 2010 at 11:57 AM, Edward Diener <eldiener@tropicsoft.com>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