$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-07-29 12:54:38
"David Abrahams" <dave_at_[hidden]> wrote in message
news:020701c236b4$95f8d100$6801a8c0_at_boostconsulting.com...
> MWCW is just wicked fast at template instantiation, period. That doesn't
> show a preference for one or the other structure, though.
What I meant is exactly the same. There is no clear relationship between the
task at hand and the C++ compile-time structure to be used. Then why bother.
>> The way C++'s template engine is structured, however,
> leads
> > me to think that dot-lists are just fine.
>
> It's structured differently in different implementations.
I was actually referring to the offering in terms of language, not
implementation. So to rephrase: C++'s template engine works very naturally
to dot-typelists, and is not natural with others.
> Until very recently, MWCW had a hard-coded limit on template nesting
depth.
> If you want to support CWPro 7.2, you might need to use long type vectors
> in lieu of type lists just to avoid running into those limits. You can do
> as much loop unrolling as you want to; it won't help if you can't even
> represent your inputs or results.
Let's think we did not need to support bad compilers for a second. Would
separation of data structures and algorithms still be a design decision for
MPL?
> > An s-expression is a tree alright. You wouldn't have to flatten it in
> order
> > to process it. LISP provides many examples of elegant tree processing,
> and
> > all it uses as data structures is the dot list.
>
> Yes, but you need to flatten it in order to *treat it as a sequence* if
all
> of your sequence algorithms are hard-coded to work on slists.
I'm completely at a loss. S-expressions *are* trees.
[snip]
> Hmm, either way you now you have support for different data structures...
It's a wonder LISP programmers never felt the need for that... and they do
trees all the time.
Andrei