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

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-08-19 17:11:30

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

> > 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.
>
> It is more than reminiscent in that if you place the arguments in
> as the type that the indicators describe you will get exactly what
> tyou expect.  It is just the what happens if the type modifiers
> don't match which is quite different.  I think just making
> the format assume best possible interpretation rather then a
> segfault is best.   (ie, "you told me to expect a hex int but gave me
> a some other type, I guess I will just set the hex flag and let you deal
> with the output.")
>
> This is actually really nice for things like complex types going
> to %f or %e.
>
>
> (Note, this is quite different from the streamprintf code someone
> posted.  There they were trying to impose some meaning on the indicators.)

I guess it's also arguable whether or not it is appropriate to absorb
nonsense silently, without throwing an exception (e.g. %x for a string). On
the other hand, your system has the advantage of giving us a non-sticky way
to specify hex formatting, which Rudiger's did not achieve. It might be nice
to add this to the boost design.

>
> [...]
> > Okay, so 2^9 is "only" 512 signatures... ;)
>
> Actualy 2&9+2^8+2^7+2^6 ... because we will want all the signature
> combinations below.

You're right 2^10 -1 is "only" 1024 signatures.

> > 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?
>
> It does actually, because otherwise you are forcing all types to have
> a T(const T&).  Many classes this may be expensive or perhaps not
> the intended meaning.  Thus by forcing copy by value you have no options.

I've been suggesting that Rudiger's code should be modified so that it
doesn't require copy construction of its arguments. In fact, his test code
doesn't compile with SGI STL or STLport precisely because of his reliance on
by-value argument passing (ofstream cannot neccessarily be copied). But it
would be easy to change the arguments to the basic_format constructors so
that they were, e.g., const A& instead of A.

> Another problem is the hidden cost of using templates.  That is every
> set of arguments will need to implement a new function.  Thus
>   format(s,int(1),int(2))
> and
>   format(s,float(1),int(2))
> share nothing.  This could get to be a very large number of functions
> for compilers that don't inline and possibly worse very large code
> for those that do.

I'm not sure that this cost is any worse than you will get in your case.
After all,
    format(s) << int(1) << int(2)
generates completely different code than
    format(s) << float(1) << int(2)

Moreover, even if you write
   format(s) << float(1) << int(2)
many times in the same program, the instances share no code.

BTW, another (weak, but not totally insignificant) argument for the usage we
have proposed is that using << to separate arguments typically causes a lot
more typing than using ,.

> <dreamland>
> If C++ wanted to deal with this problem they would allow specifications
> in the template type.  Thus rather then having to define
>
>   template <class T1, class T2, class T3>
>     void foo(T1& t1,T2& t2,T3& t2) {bar(t1,t2,t3);}
<snip>

I guess I still don't see how this applies to our scenario.

> > > 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.
>
> Well, it will be a challenge for me because the current compilers
> I target (gcc, egcs) don't have charT streams yet.   :-)

I'm sure you know, but you can get a (much more) conforming library...
www.stlport.org

> Just saying that rahter then going for the full charT specification,
> writting my class for ostream and wostream would likely cover 95%
> of all users.  Assuming STL gets implemented better in GNU world,
> a charT version could be made.

Ah. Yes, that would probably cover 99.9% of all users.

> Well I was targetting to make as close to a manipulator
> as I could.  Since "hex" affects arguments after it, I expect
> format to do the same.  Although this isn't nearly as easy to acomplish
> as one might hope.  Mine should do an okay job of hiding that it isn't.

I don't know if it's a good target to pick. I think maybe it makes your
design more complicated and reduces the clarity of code which uses it.

> Really though I think that the template one is a show stopper and
> thus manipulators are much more likely to work.  After all streams
> take one item at a time.

So far, I don't see any show stoppers here. I guess I'm confused.

> > 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.
>
> True, but placing there helps to match the standard and does
> not in any way prevent the use of other normal manipulators.  For
> example (assuming we want to make state restoring between arguments)...
>
> cout << format("%f %.3f %f") << precision(5) << a << b << c;
>
> would place b with precision 3, a with precision 5, and c with
> whatever the stream default is.

I'm beginning to be convinced that there's some value in your approach to
this part. I'm not sure whether that's just because I don't have the special
non-sticky manipulators I described earlier. Possibly not; your syntax is
much less verbose. On the other hand, it's harder to remember the meanings
of things.

-Dave

-Dave