Boost logo

Boost :

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$
> -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: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey_at_[hidden], web:

Boost list run by bdawes at, gregod at, cpdaniel at, john at