[boost] format input/output

From: Yitzhak Sapir (ysapir_at_[hidden])
Date: 2002-01-22 04:34:30

I am new to the list, and at the moment no more than just a user,
although I have comments/suggestions on other things too
(bgl/bind/functional/etc) that I'll send once I get to listing them all
out properly but for now, since this issue is coming up for discussion,
I'd like to ask a question, which may have been asked or dealt with, but
I don't know where.  And I am not sure doing a search on "format" in the
group would get me to the post I needed in the archives so here are my
comments/questions.

1) to solve this problem:
> template<typename T> operator[](constT&) definition is moved in.
> template<typename T> operator[](T&) declaration is excluded 
couldn't you use call_traits?  template <typename T> operator[]
(call_traits<T>::param_type)?
isn't that what boost::call_traits is for?  (At this point I'll offer my
call_traits comment, as it seems a proper place.  The ob_call_traits
seems to be broken for long&, with respect to being able to remove the
double reference problem (which breaks compiles).  The first template
boolean parameter checks for is_pointer || is_size<=long &&
is_arithmetic, or something like that, which obviously means that a
long& gets treated like a void*  (its size is <= long, and it is an
arithmetic type) or any other pointer, meaning it goes over to simple
call traits, and when it tries to compile simple_call_traits<long&> gets
a double reference in the definition of
simple_call_traits<long&>::reference, and so can't compile
simple_call_traits<long&>.  I don't know what the rationale was for that
long compile-time first switch but I just edited it to simply
"is_pointer" and I had very little problems and much happiness with it
ever since).

Secondly, at first I was thinking the second definition (above, in the
two lines that caused the compile to break) was in order to implement
formatted input, and then it occured to me (slightly before I went back
to the documentation to see this was the purpose of the library), that
this entire format deals only with printing.  However, there is a much
similar issue with reading formatted input.  Wouldn't people also want
to read formatted input in a text-based way instead of messing with
manipulators, but rather use a short concise formatted string?
Understandably, this wasn't one of the issues taken upon when designing
the library, but, given that the class is named format and not
format_output, I think this issue should be dealt with.  Now, whether
the function is argument-based or operator-based as far as getting its
parameters, I see no way how this:
int x;
std::cin >> boost::format(" some input format ") % x;
would work.  Although you'd expect it to work, if it could do input.  It
would be terrible if we had to pass &x just like we used to do in scanf.
But the template definition won't pick x& as the input parameter value
(although this is the conceptual choice it should make).  I think the
only way around this would be to define an input_format and an
output_format.  If the name format is chosen now, then when someone in
some time from now implements an input format, we'd end up with "format"
for output and "input_format" for input which sounds like a kludge.  Why
not just start it out right and label this as output-only format?  If
this was already discussed, I'm sorry for bringing it up again.  Just
point me to the proper message #'s in the archives and I'll read the
outcome myself.

In general, I'd like to see such a format available, but on MSVC it
would be terribly inefficient with their packaged iostreams (which
simply redirects the call to printf).