Boost logo

Boost :

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2003-10-20 09:07:42


Pavol,

"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20031020135432.GD946_at_lenin.felcer.sk...
> I would like to sumariza the current discussion regarding
> the copy vs. mutable namining in the string_algo library.
>
> This discussion starts to be typical example of bicycle shed problem,
> and I think it is time to come to conclusion.
>
> So far there has been following proposals:
>
> 1. Leave it as it is. Copy variants has suffix _copy, mutable none.
>
> 2. Change the naming so that copy variants are default, and mutable
variants have suffix _inplace
>
> 3. Use some kind of proxy object "in_place" which would change the
behaviour of an
> algorithm from copy to mutable semantics
>
> 4. Various other syntaxes like:
>
> mutate(s) % trim(3,12), blah(whatever), foo(bar)
> mutate(s) = trim(3,12), blah(whatever), foo(bar)
> s ^= trim(3,12), blah(whatever), foo(bar)
> s = trim(3,12), blah(whatever), foo(bar)
>
> 5. Declare common class for all algorithms a.k.a enhanced std::string
>
>
> In my personal opinion, only first two points are acceptable. Other
variants bring only
> confusion and complexity to a very simple problem. Why to make thinks
complicated, when
> there is a simple solution?
>
> Now to show in detail what are pros and cons of the 1. and 2. approach
>
> 1.
>
> +/- Inplace variant is default
> - Does not explicitly identify that the algorithms is mutating
> + Favors more effective inplace variants
> + Being the inplace a better variant for common task, this approach
simpyfies the usage.
>
> 2.
>
> +/- Copy variant is defaul
> + Does explicitly identify that the algorithm is mutating
> - Favors slower, less effective variants
> - More verbose, under assumption, that mutating version is commonly
used.
>
>

It looks like my suggestion was missed for using namespaces rather than
adding
suffixes.

#include <boost/string_algo.hpp>

void SomeInplaceStringFnc()
{
    using namespace boost::string_algo;

    trim(to_upper("SomeStuff") ); // error - not defined in this namespace

    using namespace in_place; // I'm an in_place kind of guy

    ::FunctionOperatingOnAString( trim(to_upper("SomeStuff") ) )

    std::string str1(" hello world! ");

    std::string str2 = copy::ireplace_first( str1, "hello", "goodbye" );
}

+ Doesn't play favorites for defaults
+ Does explicity identify the less used mutating/copying usage
+ Doesn't play favorites over performance/safety
+ Doesn't presuppose what is the common task for every user and every
application.

other pluses

+ Uses a common C++ facility in it's intended fashion.
+ Reduces complexity of both usage and implementation.
+ Makes structure of code and documentation more consistent.

-- 
Jeff Flinn
Applied Dynamics, International

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk