Boost logo

Boost :

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-02-11 11:52:34


> "Rainer Deyke" <root_at_[hidden]> writes:
>
> |> > Okay, given the wide ranging discussion on formatting, I have
> |> > resubmitted my original format operator. (Thus placing the
> |> > code where my mouth is.)
>
> |> > http://groups.yahoo.com/group/boost/files/format3/
>
> |> > Feedback welcome!
>
> |> Overall, I like. Some comments:
>
> |> - The following should silently swallow the "foo" argument:
>
> |> cout << format("%2$s", "foo", "bar");
>
> |> Right now, it invokes undefined behavior.
>
> Why not an exception? (My own implementation treats the presence of a
> %2$ without a %1$ as an error.) Of course, he did say X/Open
> compatibility, and in X/Open printf, it is undefined behavior:-).

This is a very tough call. How would you know when a exception is
appropraite with a format operator? After all the strings are coming
in from outside source like gettext so if you throw expections that means
virtually every call to format would need to be wrapped with try/catch.
It is no fun having some internationalization version of your code
crash just because the translator garbled some string, but then is
silently displaying the wrong text much better?

Currently it implements throw only if the format string is uninterpretable.
Theoretically, I could make it throw on conversion to string when
requested...

   Ie.

   try {
      cout << format(gettext("%s %d"), name, count).throw_incomplete();
   } catch (io::incomplete_error e) {
      cerr << e.what() << endl;
   }

That way it does not throw on incorrect number of arguments when
the user does not intend it.

Second, what is reasonable here? Under Microsoft .Net they allow the
same argument to be used multiple times. Or an argument not to be
used. Should this be valid?

   cout << format("%2$d %2$x", i, i);

It is not a problem to support this, the question is just would it be
useful?

--Karl


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk