Boost logo

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
whith a derived type for any type T :
oneType<T> : public baseForAll {
        T& var;
        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) ?


Boost list run by bdawes at, gregod at, cpdaniel at, john at