Re: [Boost-users] [mpl] insert not inserting?

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2007-04-02 16:06:48

[ Sorry, gmane was down on Friday and I could not get access to another
nntp access point during weekend ]

Eric Niebler <eric <at> boost-consulting.com> writes:

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

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;
}

?

> The only problem I had using MPL with proto was compile-time
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]?