|
Boost : |
From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-06-30 11:01:58
> I wouldn't mind $, but I've done a bit of shell programming, so it's not
> foreign to me.
like almost everybody, I guess.
I think $1 's meaning is quite evident for any programmer.
then it's only about esthetics..
And also, telling users not to display their amount of cash without care
"$$ 200", not "$ 200" , and always remember to escape $ ..
> I like the function approach, mostly because that's what I've been using for
> the last 6 months :-) I think that the code just looks more obvious with
> what it's doing. It's also easy to learn and understand. I also see the
okay, I can imagine you're used to it by now.
But :
cout << format(" $1 $2 $3", x, y, z) << endl;
cout << format(" $1 $2 $3") %x %y %z << endl;
once you know what this funny % operator does here, both forms are very,
very similar, aren't they ?
> advantages of the non-function approach. format could support both.
> format could be a generator function (like std::back_inserter). If it's
> called with one char * argument it generates the format class that will
> apply the % arguments, and if it's called with more than one argument, it
> will generate the function type format class that wouldn't work with the %
> operator.
it could be made..
but, except for the format-string processing code, the 2 designs have
little in common..
if both of the designs give exactly the same features, why put them both ?
I believe the only difference in what is possible with the 2 forms, is
that the functional one imposes restrictions..
so I'm more and more convinced in the operator approach.
(by the way, I realised we could even overcome the fact that we get
arguments one by one in the operator approach.
If needed, we can put them one by one in a
vector<baseForAll*>
whith a derived type for any type T :
oneType<T> : public baseForAll {
T& var;
public:
template<class Stream>
virtual void print(Stream& os) { os << var; }
}
then we process the arguments when we have them all..
( eerr, I have one doubt about the life of temporary objects appearing in
a sequence of binary operators.
They cant die before the last operator called return, can they ? no, it
can not be, obviously.
It would ... be too cruel. :-)
So really *everything* is possible with the oeprator approach.
so we have to either leave the function-format aside once and for all,
or get back to functions, only functions..
I dont think we'd benefit from providing the 2.
Would you really, really be sad if you had to type
format("$1") %x
instead of
format("$1",x) ?
-- Sam
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk