Re: [boost] Re: string algorithms review

From: Rob Stewart (stewart_at_[hidden])
Date: 2003-10-24 15:43:17

From: Ross MacGregor <ross__macgregor_at_[hidden]>
> Thorsten Ottosen wrote:
> 
> I see your point. Now that I look at the chaining aspect, I don't see a 
> great need for it anyway.

I think it encourages hard to debug code.  See below.

> What I understand is that the original inplace algorithms returned a 
> reference so that something like this would be possible:
> 
> A) func( trim(to_upper(s)) );
> 
> This saves space and is elegant but it is also a little ambiguous too 
> (is s modified?). This can lead to unpleasant side effects, so an 

I agree with the concerns.

> explicit variant is being considered:
> 
> B) func( trim_inplace(to_upper_inplace(s)) );
> 
> This is a much less ambiguous operation, but I think I would be just as 
> happy learning the single inplace set and writing the operation as:
> 
> to_upper(s);
> trim(s);
> func(s);

This version is easier to debug as you can inspect the
intermediate results easily.  With the chained version, it's
difficult to step in, step out, step in, step out, ... the right
number of times to see the intermediate result you want.

Without chaining, you can just set a breakpoint at the desired
line (probably one after you want to see the result of a call).

> Did I miss a more important aspect of chaining?
> 
>  > As for the chaining, then maybe we need some device that allows of to 
> call n
>  > function operation on eachother's result:
>  >
>  > string s:
>  > chain( &trim, &to_upper, s );
>  >
>  > ?
>  >
>  > Thorsten
> 
> Then I could write my little code snippit as:
> 
> chain( &trim, &to_upper, s );
> func(s);
> 
> Correct? This would perhaps be less error prone without the duplicate 
> prameters, but I don't find it easier to read.

That's trying too hard to provide what is questionable to have.

As for the naming issue, I'll throw my stone in the pool, too.
When I write something like this

   trim(s);

there's no way I would expect anything other than that "s" is
modified.  Why?  Because the function name says it does
something, I'm not saving a result anywhere, and side effects on
globals are anathema.

Thus, having the mutating versions return void is a perfect means
to clarify the intent of such a function.

Now, should the mutating version get the short name with the
"copying" version getting a suffix?  That does follow an
incomplete precedent in the STL, so it would make sense and I'd
be fine with that.  However, we could break with precedent and
change the tense of the verb: trimmed.  Thus

   trimmed(s);

stands out as a mistake because I'm asking for a trimmed version
of "s" without putting it anywhere.  The correct usage would be

   std::string t(trimmed(s));

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;