[boost] Re: string algorithms review

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-23 22:21:54

Pavol Droba <droba_at_[hidden]> writes:

> On Thu, Oct 23, 2003 at 03:10:52PM -0400, David Abrahams wrote:
>> Pavol Droba <droba_at_[hidden]> writes:
>
> [snip]
>
>> > I understand very well the pronciples of functional programming. But
>> > functional language execute the program in totaly different way then
>> > imperative like C++.
>> 
>> C++ is a multiparadigm language.  Many of us like to do functional
>> programming in C++.  See Boost.Spirit/Phoenix, Boost.Bind,
>> Boost.Lambda, FC++, Boost.MPL, ...
>> 
>
> Although it it possible to use functional style of programming, and
> it makes sense to do it so, C++ will never be a functional language.
>
> Main difference between C++ and f.e. a Haskell is not in primitives
> it provides, and the syntax it gives, rather in the way the
> computation is performed.
>
> In normal C++ program, the execution is performed in the means of
> assigments and jumps. In Haskell, it is a term rewriting.

1. Not all FP languages are lazy like Haskell

2. Ultimately it all executes on the same hardware.

>> ?? We're not talking about making a copy, since the result differs
>> from the input.  In general, you pay the same price in functional
>> languages.
>> 
>
> So there is realy NO copy performed in Haskell when evaluating the function,
> it is a transformation. And this is much closer to inplace version,
> in C++ then to copy one.

Gimme a break, man!  In pure FP languages data is immutable, so
there's no way to make inplace changes.  In Haskell you have to go
into a monad to escape this restriction.

> In copy variant, we are actualy making a copy of the input. That is
> the actualy the difference between copy and inplace variant.

If you are implementing trim by first copying the entire input and
then modifying it to trim off the parts you don't want, you really
are doing it very inefficiently... especially if most or all of the
input must be trimmed.

> There makes no sense to argue about anyone's personal
> preferences. They are "personal" for a reason after all. 

Right.  I was simply stating mine.

> So I consider the favoring of the inplace version, with a basic
> safety belt (void return), as a reasonable compromise.
>
> And the last words for this topic. Given the fact, that this
> particular issue is realy only a matter of personal preference, 

It is not *only* a matter of personal preference. I think there are
some ways in which the functional approach is objectively safer, as I
demonstrated with my example.  It is, however, mostly personal
preference.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com