|
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