Re: [boost] Re: Review request : format

From: Karl Nelson (kenelson_at_[hidden])
Date: 2001-12-20 12:09:38

> --- In boost_at_y..., Karl Nelson <kenelson_at_e...> wrote:
> > How is the execption to be handled?  What good does it do to raise 
> it?
> > Can you provide a reasonable code where raising an exception when
> > strings are being provided from an outside source will make 
> > a critical difference to the coder?
> > 
> 
> Exception handling is one more little agrument against traiting 
> format as manipulator. Look:
>   cout << "hex: "
>        << hex
>        << i
>        << endl;
> You expected that this code will not throw exception even in stress 
> memory conditions. You know that operator<<'s whether set flags or 
> put characters directly to the stream buffer. This can be implemented 
> safely (and I beleive it is).
> Next "equivalent" example:
>   cout << start_format ( "%s%x" )
>        << "hex: "
>        << i
>        << stop_format
>        << endl;
> is completely different story. Characters are accumulated in format 
> object and then outputed to cout. It really can throw! Users of 
> ostreams expected that they can safe pass to ostream most 
> manipulators and build-in types and they fail here.

True.  But this isn't the type of expection I am talking about.  

I am saying throwing an exception for

   cout << format("%1 %2") << a << endf;
   cout << format("%1 %2") << a << b << c << endf;

Is the same as this....

   string a;
   ...
   cout << hex << a << endl;

Just because that isn't want the user wanted (they wanted a hex number 
but they are giving a string).  This is not justification for an exception.
It should just print the wrong thing.

> 
> How are you going to implement this code?
>   cout << start_format ( "hex: %x" );
>   cout << i;
>   cout << stop_format
>        << endl;

Given stream has states and state expansion, but they don't appear
to given it enough thought to handle this case I can't.  But
I think clearly stating "the format manipulator restores the 
state at the end of the statement, thus further input of arguments is
not possible."  covers that problem. 

 
> I think most of us agree that we should somehow distinguish output to 
> stream and output to format. I prefered do not mix ostream and format 
> at all. Samuel Krempp prefered another operator. We all care about 
> clear functionality.

I just don't see this as clear.  It imposes a new operator to service
which is one directional in nature.  << >> have some sense of direction.
Thus if I wanted to make arguments return the size of the field I could
do code like this....

   string a="boxes";
   string b="boats";
   cout << format("%s %-s\n")  << a >> i  // get the field width
                               << setwidth(40-i) << b;

    ----------------------------------------   
    boxes                              boats

--Karl