[boost] Re: string algorithms review

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-10-19 04:37:04

Thorsten Ottosen wrote:
> "Daniel Frey" <daniel.frey_at_[hidden]> wrote in message
> news:bmrejk$uas$1_at_sea.gmane.org...
> -Of course. I would still vote "yes" if the mayority decides that the
> -current default is the prefered one..
> 
> I think it would be wrong to change something just because of votes. If it
> should be changed, then let it be because
> there are compelling reasons for it.

I voted for inclusion of the library, not for a single feature. But 
anyway, I think we are faced with a very subjective decision for the 
default behaviour.

> So far, we have one reason that it
> should stay the way it is
> 
> 1) similarity with std algorithms
> 
> Personally I also think it reads more clearly:
> 
>     trim( s ); // a bit like s.trim();
> 
> would you really expect a verb in the imperative not to change input (or
> object-) state?

s.trim() is what IMHO would be an intuitive interface to changes s's 
state. Sadly, it's not possible to provide it. It's the old question 
whether or not a function should modify its arguments. Of course you are 
right that the STL uses a different notion, but that's not the one and 
only argument as you seem to suggest. From my experience (and I would 
like to hear whether others share this view), users don't expect x to 
change when they write f(x). For x.f(), they know it depends and the 
name of f usually tells them whether x is modified or not. It's simply 
easier to read code that way. I also asked a colleague yesterday to 
verify my views and he agreed. The most problematic portion of the 
current interface is in fact, that it allows you to write:

std::string s = "Hello, world!";
std::string t = trim( s ); // Ouch!

If the chaining (which is a reasonable feature when judged on its own) 
is allowed, the compiler cannot detect the above as an error (which it 
usually is if someone write such code, right?). If modifying algorithms 
would return void, the above could be prevented, but this is not a good 
option as chaining is useful. Think of a poor maintainance programmer 
that has to read through a large piece of code which contains a line 
like above. It's IMHO very hard to find these kinds of errors...

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de