Re: [boost] Re: Re: Re: Re: Adding Loki to Boost (reprise)

From: joel de guzman (djowel_at_[hidden])
Date: 2002-04-13 00:49:03

----- Original Message ----- 
From: "Aleksey Gurtovoy" :

> Joel de Guzman wrote:

> > But why should we pay for the inadequacies of compilers?
> 
> The above is not only about "inadequacies of compilers", it's also about
> compile-time performance. And you don't have to. Remember, it's
> _implementation_ of 'count_if' we are talking about here. If your compiler
> is ideal, and you believe that you don't need something like recursion
> unrolling (believe me, you do :), you are free to contribute an
> implementation of the algorithm like the one Peter has posted here; it can
> be incorporated conditionally. IMO it doesn't worth it, though.

Fair enough. Please regard my observations and questions as just,
umm, observations and questions... I will find some time and inspect
MPL fully. That way, I might be able to view things in your perspective.

> > I firmly believe that we should push these compilers hard to
> > send a strong message to the compiler makers not to be lax.
> 
> I definitely think that compiler vendors need to be pressed towards the
> better comformance. But the above sounds like it's library's fault that it
> does work under deficient compilers. Do you seriously think so? How about
> Phoenix? By that criteria it's guilty as well :).

No it's not the library's fault. What I was just trying to say is that the
interface should not be driven by the implementation. "Simple is
beautiful. Keep it simple but not simpler." That has always been the
mantra of design in general. Peter and Andrei's count_if versions
side by side with MPL's count_if version *seem* to indicate (OK,
arguably) that MPL's interface is more complicated due *in part*
(Ok, not in whole) to compiler deficiencies. We are talking about
interface here, BTW. I am sure everyone agrees that the authoring
of meta-algorithms is very much a part of the interface.

> FWIW, _none_ of the current compilers is not able to handle MPL without all
> workarounds, so if you want the "ideal" implementation (whatever it is),
> than this discussion is meaningless, because you first should wait for that
> ideal compiler to appear.

Agreed. We live in an an imperfect world. I am not an "idealist".
Some compromises are OK if they are really inevitable. 

> > I am having the impression now that MPL's interface was designed
> > in part to get around these limitations?
> 
> Why? Were we discussing the 'count_if' interface here? I believe not.
> 
> > If so, this is not a good sign.
> 
> It is not so.
> 
> >
> > > 5) (IMO) The above is too low-level, and harder to parse and understand
> when
> > > the original 'fold' version.
> >
> > Sorry, but I do not agree. Peter's and Andrei's versions are
> > easier to understand. At least for me (no offense meant :-)
> 
> Are you familiar with functional programming?

What's the point of this question? To gauge my level of competence
to form an opinion?

I rest my case :-)

Regards,
--Joel