Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2003-12-21 07:07:50

"David Abrahams" <dave_at_[hidden]> wrote in message

>."compile time is a precious
> > resource when using MPL" or something similar I think in the MPL
> > leaflet on the files section.
> Compile time is a precious resource when doing any metaprogramming.
> In fact using MPL can effectively reduce compilation times over ad-hoc
> metaprogramming techniques, because optimizations have been applied to
> various parts of the library... but whether it will be faster or
> slower is still dependent on the problem being solved and your
> approach to it.

Ok I should have said metaprogramming. Apologies.

> > It is also mentioned in my Templates the complete guide book
> > Vandevoord & Josuttis I am waiting for David Abrahams book to come
> > out. I am sure there will be some useful info on the subject in it.
> Yes.
> > Dont get me wrong MPL is an important subject and the consensus
> > appears to be that you have made a good start. But there is a point
> > where compile times severely affect the way I code. It is no fun
> > and expensive having to work with slow compile times.
> I'm not sure from the above (and especially your mention of
> Vandevoorde & Josuttis, which doesn't discuss the MPL) whether you're
> talking about MPL itself or any metaprogramming at all.

Ok . If MPL was called
or CTCPPALTCPPSTL etcetera...
I would probably stick to the word metaprogramming.
I take the point. I am talkng about metaprogramming in general.
I will take care of the distinction in future.
I will say there is a danger that MPL will over time be used as a coverall
for metaprogramming.
(Yep I'm doing that... not helping to avoid it... Apologies again )

> Do you have
> an a priori reason to think that using the MPL is going to make
> compilation times longer than doing it some other way?

Yes. IF the other way involves less metaprogramming of any kind.
Use it If you need it... "you never get something for nothing".
Although you may/will come a great deal closer as compilers and the language
itself evolve.
Yep I am thinking short term.... and from my own coding style. I remember
the old days when MSVC1.0 took an inexhorable time to
compile anything(40Mhz 386).It affects the way you go about things. These
days I tend to use C+ on my compiler like an interpreted... not a style I
recommend to anyone else.
I have looked at mpl vectors and lists for my physical quantity type.
I have rejected the idea(currently), because it is unnecessary complexity
for my (current) needs.(need to learn,compile time...debug)
 I am using some metaprogramming and spent a small amount of time on trying
to optimise compile times.
 Even that smallish amount of metaprogramming Will affect compile
times....non-boost critics will point this out to Me too.
(Hence I am awaiting your book. the MPL optimisation techniques will
presumably be applicable to other metaprogramming )

> > (If people bang on about it the MPL guys may take notice... ;-) )
> Do you think Aleksey and I haven't given compilation time a lot of
> attention already?

No.I would imagine when designing metaprogramming algorithms
that compile time is forefront in your mind at all times.
Metaprogramming is amazing. It allows you to mould program entities in what
I can only describe as an artistic way.
but it is something which compilers and the language will have to catch up
Compile time is major hurdle in bringing it to light.
Point out the problems up front at every opportunity so people are
prepared.(Yep as a philosophy for progress...debatable)
My note is to Mathias. He has got a correct implementation.
Now he needs as he rightly points out to optimise it.
He would benefit greatly from you guys expertise in doing that.
I would find a write up.( Sorry Matthias I am criticising again... but
documentation really helps me) of the optimisation process from
Matthias point of view would be useful to me and perhaps many others who are
trying to get to grips with MPL and metaprogramming in general.
As a test case it would be good to time a compile(s) of an unoptimised and
optimised version of YANL.
To see how and how much improvement in compile time can be achieved.
(But hey complex... time v benefit, I appreciate that)

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at