Re: [boost] Re: formatting manipulator for UTF-8

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-08-19 12:38:22

----- Original Message -----
From: "Karl Nelson" <kenelson_at_[hidden]>

> Yes, that is a definite difference in strategies. My general philosophy
> has always been strict adherence to a standard even if it is poor is
> better than cutting something yourself.  However, this is very open for
> debate.
>
> Now in regards to mine.  The prinf specifiers are made very fuzzy.
> %s means any literal.  %d means anything with the decimal formatted.
> %x means anything with numbers printed as hex.   Thus the print
> indicators are more about how shall I format this and not really what
> type the item is.

Okay, that's pretty easy to remember, but of course it doesn't exactly
correspond to the 'C' standard for printf. Whether it is a good idea to do
something which is reminiscent of a standard but does not strictly adhere
is, I think, open to argument.

> > I'm not sure how compelling it is to be able to format more than 9
> > arguments. One upside of the boost system is that it is clear exactly
which
> > arguments go with a particular format string.
>
> It certainly is not very compelling as I could count on one hand all
> the times I had more than 9 arguments (though I can remember it
happening).
> A more direct problem is that I think that the current implementation
> may always require pass by value.  Thus you must specialize each
> subset of const T& and T& for a given number of arguments.
>
> Thus for 4 arguments you would need
>   T&, T&, T&, T&
>   const T&, T&, T&, T&
>   T&, const T&, T&, T&
>   T&, T&, const T&, T&
>   T&, T&, T&, const T&
>   const T&, constT&, T&, T&
>   T&, const T&, constT&, T&
>   T&, T&, const T&, constT&
>   T&, constT&, T&, const T&
>   const T&, T&, T&, const T&
>   ....

Okay, so 2^9 is "only" 512 signatures... ;)

> Okay you get the point.  I have tried something similar for
> a general create template, when I was trying to make new private
> for a class by allow GC for items through create.

Yes, but I don't think that really applies in this case. There really is no
excuse for modifying an argument to output formatting, is there?

> The problem comes down to C++ needs a
>   template <class T&>  foo(T t);
> which means T is always a reference type.
> Without this anything which tries to do format(...) with templates
> will fail.

Oops, you lost me with this part.

> > For some of us, being able to handle wide characters (unicode) was an
> > important design criterion.
>
> Yes.  I agree.  I just don't know that I would be qualified to extend
> my stream properly to cover that meaning.  It is a large can of
> worms.

It shouldn't be too much of a challenge, AFAICT.

> I would tend to believe that my format should just be
> overloaded for wide uses or charT specials and leave the default
> something like this.  wformat???

Whoops, I'm lost again.

> > I think if you review the boost discussions, you'll see that I suggested
> > this as a way of keeping the format string associated with its arguments
as
> > described above.
>
> Right.  I did notice that.  But it wasn't discussed why
> making the format a normal manipulator was bad.

I don't think it's bad, but it may be impossible to do with ordinary
streams. After all, a normal manipulator is a function. I think format() has
to carry state with it.

> > > Other manipulators do
> > > not count as arguments in my.  They do in his.
> >
> > Yes, I don't love this arrangement. Actually, I don't mind having the
> > feature, but for ease-of-use I would prefer to see a different form of
> > manipulators which enclosed the argument to which they applied. For
example:
> >
> > boost::format("%1 != %2", fixed(boost::setprecision(5, 1.9999)),
2.0000);
> >
> > where fixed and setprecision(5) are being applied only to 1.9999 above.
>
> Well mine of course escapes that unless you want variable width
> specifiers.
>
>  cout <<format("%.5f != %f") << 1.9999 << 2.0000;
>
> (whether this is implemented properly currently is open to question.
> I was still early in the testing.)

The problem with this is that normally you want manipulators to be
associated with the arguments to be formatted. Normally, the choice of
manipulations won't be affected by i18n issues (I think). So putting it in
the format string may be the wrong choice.

> > > His as functions
> > > has ordering preferences, mine being a stream can not.
> >
> > I don't understand what you mean by "has ordering preferences".
>
> format( foo, bar )  has a clear start and stop because ().  Mine
> is quite fuzzy, though endf serves that purpose.

Okay, I understand now.