[ Sorry, gmane was down on Friday and I could not get access to another
nntp access point during weekend ]
Eric Niebler
Markus Werle wrote:
So what we really need together with the tutorials and the documentation is a wiki about the design and evolution of boost.
Design rationales are good. A wiki might work, but a better place might be in a "Rationale" section in each Boost library's documentation.
The advantage of a wiki (or any other public read/write access documentation) is that not only the designer of some boost part is in the role of an author for his design rationales but others can easily contribute. More important than the design rationale for boost::XXX is the design rationale for some of the building blocks of it, and since these are used across several distinct library parts, we really need design rationales for _techniques_ used in boost, a meta-boost design rationale. (Common tricks like deep_copy in all its flavours etc.) I sometimes come across a discusion which I feel to be important enough to be cut'n'pasted to a CMS, let it be wiki or joomla or whatever you like ...
Then Eric Niebler could explain in depth why he needs "static, aggregate initialization" in proto (see <http://thread.gmane.org/gmane.comp.parsers.spirit.devel/2886/focus=2890 ) and why mpl does not fit for proto.
Static initialization in proto is important so that when DSEL authors declare their global primitives like _1, there are no global initialization order problems.
The only problem I had using MPL with proto was compile-time
My skills are not such that this piece of information suffices as explanation about what was suboptimal and what was fixed. Going back to your code again ... maybe I catch the idea sometimes. Never saw that trick before. What is better in static type call(Expr const &expr) { type that = {proto::arg(expr)}; return that; } than static type call(Expr const &expr) { type that = proto::arg(expr); return that; } ? performance
problems when using MPL lambdas. In order to keep compile times down, I've replaced as much template meta-programming in proto as possible with preprocessor meta-programming.
Could you publish an article about that? Your article "Conditional Love: Foreach Redux" (http://www.artima.com/cppsource/foreach.html) is a good example about cool things that are hidden in some innocent looking piece of code. Reading the header file never would have exposed the things that matter (at least to me).
And proto is a bit of a special case since TMP-heavy libraries are built on top of proto, so the TMP overhead of proto itself should be as small as possible. MPL is a very nice abstraction, but it's not free. Ditto for Fusion.
This raises 2 questions for me: 1. Could these issues be fixed for mpl and fusion or are you really forced to create your own enhanced versions? 2. If you build your own high performance versions of typelist etc.: isn't fusion and/or mpl a good place to add them instead to "hide" them in proto - below xpressive? <cite url="http://thread.gmane.org/ gmane.comp.parsers.spirit.devel/2886/focus=2890"> > [...] proto::basic_expr<> is the central data container of proto. > It's functionality very much resembles a fusion sequence </cite>
And yes, I measure compile time performance and don't optimize prematurely.
I do not question what you are doing. I am simply looking forward to profit from the fact that you've been already there in compiler hell and are willing to give us some good advice how to survive when we go there, too. I am probably asking too much here. It's only that I am not able to extract this knowledge from source code ... Markus P.S.: Apropos proto: are you planning to introduce a glommable disambiguation mechanism [Geoffrey Furnish]?