Re: [boost] Re: string algorithms review

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-23 13:32:57

On Thu, Oct 23, 2003 at 12:54:53PM -0400, David Abrahams wrote:
> Pavol Droba <droba_at_[hidden]> writes:
> 
> > On Thu, Oct 23, 2003 at 09:42:35AM -0400, David Abrahams wrote:
> >> Daniel Frey <daniel.frey_at_[hidden]> writes:
> >> 
> >> >  From a convenience POV, I would still prefer the copy-version to not
> >> >  have a suffix, but that's probably just a matter of taste. My main
> >> >  concern was safe use which is now addressed. Thanks.
> >> 
> >> My taste agrees.  The safer version should also be the more convenient
> >> one.
> >> 
> > If the inplace variant returns void, it could not be misused. So it
> > is safe too.
> 
> Mutating in-place, regardless of the return type, is less safe than
> making a new copy of the data.  It's one of the basic principles of
> functional programming, and why my coding guidelines recommend making
> as many things const as possible, including function arguments.
> 
>    int f(int x)
>    {
>       if (condition) { ...
>          modify(x);
>       }
>       ...
> 
>       int y = x + 3; // whoops, I forgot that x was modified
>    }
>            

I understand very well the pronciples of functional programming. But functional
language execute the program in totaly different way then imperative like C++.

In C++ making a copy means a considerable overhead, in functional languages, 
no copy is created, rather a term is reduced. So although I agree with you,
that functional approach is more sound, in performance oriented imperative
languages like C++ it is not always the best approach.

Just my 0.02p

Pavol