Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-12 17:19:46

----- Original Message -----
From: "Terje Slettebø" <tslettebo_at_[hidden]>

> As Dave pointed out, too, why would uniformity be an advantage? Isn't one
> for the advantages for the iterator consept at STL that you may use it with
> anything that provides iterators, including things like generators?

Why is it frowned upon to reimplement your own string class?  Why is frowned
upon to reimplement what is already done a freely available?  Uniformity is the
purpose that the C++ standard library exists at all (except for the parts that
are actually tightly integrated with the language itself!).

> If you go for a uniform way, that means people have to agree on a uniform
> way. So far, there haven't been any compelling reasons for exclusively
> selecting one sequence compared to another, which you have pointed out, too,
> as they vary in their behaviour,

I have pointed out nothing of the sort except to say that vectors outperform
lists and that both are unrealistic at large sizes.  We have no compelling
reasons (or example to that effect) to *have* more than one sequence type.
There are reasons in runtime programming--different *actual* runtime performance
characteristics and memory usage, etc..  These _do_ _not_ _apply_ to compile
time programming.  Therefore, if you want to say that emulation of the STL
analogy is good, you have to prove it by other means.

> which is yet another reason for not fixing
> it to a specific sequence. Especially as the field is quite new, as you say,
> you don't want to standardise on something, to not make a decision that
> later turns out to be bad.

What is the purpose of Boost?  Isn't it to create "existing practice"?  Why
would we want to create existing practice in an area that is largely
experimental with absolutely no concrete data saying that it is worthwhile?

> So I think the argument that this is a new field, actually works against
> fixing the framework to things like specific sequences.

Obviously.  You and I have are viewpoints, and all that is happening is that we
see things as we want to see things.

> In addition, you have the mentioned advantages that David B. Held and others
> have pointed out, that with the iterator abstraction, anything providing
> iterators may be used for the algorithms, that includes things like
> generators, too. range_c works like that. Are you disregarding this, as
> well?

Why would it be difficult to make a convertor for the specific and uncommon case
of something like range_c?  Input/output doesn't apply, random number generators
don't apply, etc..

> In my opinion, this is a strong argument for the iterator abstraction. It
> enables extension and experimentation, in this new, exciting field. MPL
> would be much less extensible, if algorithms and functions only worked for a
> fixed set of sequences, that couldn't be extended.

No it wouldn't be.  It would simply be a case of defining convertors in some
case (yet to be seen) where it is absolutely necessary.  That doesn't make it
less extensible, it just shifts the extensibility and simplifies the
implementation.

> By the way, I later found that the example program I posted (sequence
> timing), used the typeof() of g++, a non-standard extension. Doing some
> simple testing on MSVC 6.0 (which doesn't have typeof()), vector and list
> came out equally fast.

What kind of test were you doing?  In order to really see performance benefits
with a vector, you'd have to do random access of many elements at once.

Paul Mensonides