Re: [boost] GIL Image Processing Library - Fusion and TinyVector

From: Andy Little (andy_at_[hidden])
Date: 2006-10-19 21:01:36

"Joel de Guzman" <joel_at_[hidden]> wrote in message

> Andy, thanks for your analysis. Here are my thoughts:
>
> 1) Compilers will get better. That is implied in your statement that
>    the problem you have with VC7.1 (internal structure overflow) is
>    no longer present with VC8.
>
> 2) Fusion can and will be improved. Have you seen the latest code
>    by Eric Niebler on segmented iterators and algorithms?
>
> 3) A tuple is a struct and a struct is a tuple. You can definitely
>    mix hand-rolled structs and fusion tuples at will and provide
>    algorithms "overloads" for optimization.
>
> There's great benefit with generic programming. Certainly there
> are obstacles that hinder progress and we generic programmers
> try to solve those as best we can. It's a journey. Anyway, thank
> you very much for your initial efforts!

Hey.  Its only really VC7.1 that prompted me to go for a handrolled version.
Overall I would be happier sticking with Fusion, but.... (Also bear in mind that
the quan::fusion Matrix version was as you say an initial effort and a Fusion
Matrix might be better done much differently).

In general though, wading in Deep... I have a feeling that the "everything's a
list" approach and
following STL, as favoured by STL and Fusion may not be the best model to follow
for compile time programming. This is no disrespect to MPL or Fusion.... (That
said I can't quantify why that is, but speed of compilation and compiler
resources are a rough equivalent to memory use and runtime speed performance)

IMO  MPL particularly has some problems, however bearing in mind that MPL
represents some kind of leap into a brave new world of template metaprogramming,
this is only to be expected , and therefore MPL is a great achievement, and much
respect to Alexsey Gurtovoy, but I cant help feeling that it Shouldnt be the
final word, and I would hope for a more Open analysis of MPL's good and bad
points, without just getting the feeling that I am getting criticised for
attacking a helpless baby.

The "fusion" of compile time and runtime progranmming  is a complicated , but
powerful beast, but more satisfactory, more 'whole' than TMP only.  Fusion is
built on MPL. That causes me problems, simply in the boost::type error messages.
IMO this is indicative of the major problem in MPL.... there are no types. IMO
types are important at compile time as runtime.

I have a feeling that Fusion may be headed the same way as MPL, IOW its built
top down ("the compile time STL") rather than bottom up.

The bottom up approach would  start form applications (IOW real world use)
and then "find" the generics.  Unfortunately Boost  can distort that view AFAICS
because of its nearly standardisation, and I find that problematic.

 IMO reinventing the wheel is good because each iteration makes the wheel a
little rounder, but premature standardisation leaves us paring away at a mostly
square wheel.

OTOH .. what do I know :-)

As far as optimisation is concerned... as you say, VC8 is sweet, but on its own
turf only, but bear in mind that GCC must work on a large range of platforms, so
it is unreasonable to expect it compete head to head  with VC8's in VC8's native
territory.  I do hope that ConceptGCC will be finished though so it conforms to
its docs... then hopefully VC.XX will want to catch up with Gcc in that
department ;-)

And if you're thinking that the above makes no sense... ..........

Yeah  maybe ;-)

regards
Andy Little