From: Daryle Walker (darylew_at_[hidden])
Date: 2006-07-08 18:34:36
On 7/3/06 9:08 AM, "Jeff Garland" <jeff_at_[hidden]> wrote:
[SNIP discussion with Marc Mutz over the "trim" name]
> Hopefully this won't make you mad, but your prior email made me realize that
> the mutating functions should return a self reference so now you can write:
> s.trim().to_upper().append(" more stuff ");
> The other thing it made me realize is that it would be handy to have
> additional overloads on the number of parameters in append/insert_at. So in
> the next version you'll be able to write:
> double dbl = 1.12345;
> int i = 100;
> s.append(dbl, " a string ", i);
> //"1.12345 a string 100"
I don't think this is a good idea. Could this be implemented any more
s.append( dbl ).append( " a string " ).append( i );
You would have to do the memory allocations in piecemeal in either case.
And no matter how many parameters are given, users would have to resort to
chaining whenever they go above your arbitrary limit. There would be little
gain over the cost of having to drag in tuples and advanced programming.
The "append" method could have an alternative version with a second
parameter, that of a locale so the user can control the string conversion.
The single-parameter version would just use the default locale.
> I'll probably do something like boost.tuple and support up to 10 arbitrary
> parameters. And at the suggestion of someone else, I'm also adding
> boost.format into the mix:
> s.append_formatted(dbl, "-some string-", i, "%-7.2f %s %=5d");
> //"1.12 -some string- 100 "
Unless you are limiting the method to be exactly four parameters, how would
it know that the last parameter is a format string and not a direct argument
(that looks like a format by coincidence)?
> So I'm afraid I'm making it more mutable, not less ;-)
You still have to evaluate each potential method, and not make your class a
dumping ground of mixed quality.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk