Re: [boost] format input/output

From: Samuel Krempp (krempp_at_[hidden])
Date: 2002-01-22 11:50:42

On Tue, 2002-01-22 at 10:34, Yitzhak Sapir wrote:
> 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)?

well, this "problem", is a MSVC-specific problem. 
The overload is legal C++, and the above code too.
It is not very useful, since users will most certainly provide 
ostream& operator<<(ostream&, const myclass& x) 
rather than
ostream& operator<<(ostream&, myclass& x)

So, for MSVC, I simply plan to ban user objects for which the operator<<
is not const towards the object.

> 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

I think you should split this subject into a separate message, because
traits people will certainly not see that.
Moreover, the boost list has quite a big traffic, so I think that
sending one mail for each subject you address help maintain a nice, 
threaded, organisation of the discussions.

> 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

nope, 'format' sticks to ouptut-only.

I think the input aspect of things was almost implcitly ignored, and
only once soemone evoked it, saying that apaprently a 'scanf' equivalent
was not as much needed, and so format concentrated on output.

Personnally I think formatted input has very different issues, and it
would be hard to address correctly both objectives at the same time.

about 'format' not expliciting it is only output oriented, well, it's
true the name is not as explicit as 'printf'.

But it won't be a problem for later finding a name for a formatted input
library, one can forge the name from 'parser', or the like.

> 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

Oh, it could. 
In the 'argument feeding' step, you can store references to each of the
given arguments into a container of polymorphic objects.
I mean, you define an abstract base class 'ReferenceBase', in which you
define 
virtual void read(istream&) =0;

Then
template<class T>
class Reference : public ReferenceBase {
T& ref_;
public :
Reference(T& x) : ref_( x) {}

virtual void read (istream& is ) {
        is >> ref_ ;
}	
}

Then, your class (let's call it Scanf, to avoid ambiguities with format)
can store the references to all given arguments into a
std::vector< shared_ptr< ReferenceBase> >

and at the end, when the cin >> Scanf(" ... ")  
happens, you do your things and ditribute pieces of the input into each
argument by calling the read method on the elements of the vector.

I had though of this approach for format (outputting), but it brought
only problems (if you want the user to be able to pass manipulators
among the arguments, it's getting awful) for no advantage. 

But I guess it would be a possible solution for an input library.

> 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.

Even if input and output could share the same style of usage, the 2
aspects should not be implemented in the same class, so the 2 classes
would need distinct names.

printf / scanf would cause collisions when using boost and std
namespaces at the same time
Printf / Scanf  does not follow the guidelines

format / parse, or input, or reader, .. 

One thing I believe, is that the name 'format' fits ouput better than
input, and that the Boost.Format library has the right to take it !

> 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).

even when using ostream as a comparison, the results of the benchmark
run by rogeef on MSVC looked awful ( format was around 10 times slower
than stream, while on my machine, the ratio is around 1.5 ..)
So if you tell me that their ostream is itself quite slow, I'll
understand why the number of iterations I used for the timing loop was
too high for his taste.
The stream library performances are not the only cause of that, the
ratio above 10 means MSVC had problems with the design.
(I'm hoping it's just that all the inlined big functions that are
responsible for this)
enough talking of performances..

-- 
Samuel