Re: [boost] Re: io operations for stl containers?

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-02-24 15:13:10

>From: "Vladimir Prus" <ghost_at_[hidden]>

Sorry for having taken so long to respond to these messages. I felt a need
for a break, to consider how it might be done.

In a way, something good came from it, as well: I've recently looked at
Boost.Tuple, and I see that they have I/O operators defined (in
tuple_io.hpp). To quote from the docs:

--- Start quote ---

Streaming

The global operator<< has been overloaded for std::ostream such that tuples
are output by recursively calling operator<< for each element.

Analogously, the global operator>> has been overloaded to extract tuples
from std::istream by recursively calling operator>> for each element.

The default delimiter between the elements is space, and the tuple is
enclosed in parenthesis. For Example:

tuple<float, int, std::string> a(1.0f,  2, std::string("Howdy folks!");

cout << a;

outputs the tuple as: (1.0 2 Howdy folks!)

The library defines three manipulators for changing the default behavior:

- set_open(char) defines the character that is output before the first
element.
- set_close(char) defines the character that is output after the last
element.
- set_delimiter(char) defines the delimiter character between elements.

Note, that these manipulators are defined in the tuples subnamespace. For
example:

cout << tuples::set_open('[') << tuples::set_close(']') <<
tuples::set_delimiter(',') << a;

outputs the same tuple a as: [1.0,2,Howdy folks!]

The same manipulators work with operator>> and istream as well. Suppose the
cin stream contains the following data:

(1 2 3) [4:5]

The code:

tuple<int, int, int> i;
tuple<int, int> j;

cin >> i;
cin >> tuples::set_open('[') >> tuples::set_close(']') >>
tules::set_delimiter(':');
cin >> j;

reads the data into the tuples i and j.

Note that extracting tuples with std::string or C-style string elements does
not generally work, since the streamed tuple representation may not be
unambiguously parseable.

--- End quote ---

Maybe these routines could be generalised, and used for any
composite/compound type, including tuples?

If it's good enough for the standard library (given that Boost.Tuple have
been accepted in the Library TR), it may be good enough for the other types,
as well. :)

> Terje Slettebø wrote:
> >>From: "Jason House" <jhouse_at_[hidden]>
> >
> >
> >>Terje Slettebø wrote:
> >>
> >>
> >>>Regarding this project. I've got doubts about the viability of it.
> >>
> >>Well, I'm glad you've given it a greater level of thought.  I really
like
> >
> > the idea
> >
> >>of the composite_format, and probably should try to do the same :)
> >
> >
> > Thanks for your feedback. I like the idea, as well. We have I/O for
single
> > objects, but no specific way for composites. The question is if we
should
> > have that. :) Maybe the reason we don't have it, yet, is that it may be
hard
> > to come up with a system that is general enough, yet easy to use.
>
> Most likely I don't need to say it again, but having fixed i/o operators
with
> fixed output format is better that have nothing. As you've noticed, my
> original motivation was debugging output, and I still find this important
enough.

You're right.

That was probably the motivation for Boost.Tuple's stream operators, as
well: A minimal, easy to use interface, with sensible defaults.

> >>>One thing is to create something useful. Another thing is to create
> >>>something useful as a _library_ component. As has been noted regarding
> >>>application and library development, application development and
library
> >>>development is typically quite different. With an application, you
> >
> > typically have quite specific requirements. With a library component,
however,
> > it's about anticipating future use. Or making something general enough
to be
> >>>useful as a library component.
>
> But you don't write library, put a seal on it, and stop. There's nothing
wrong
> with making it more flexible when users demand it. As it stands, only few
> persons are interested in the simplest facilities. Is it worth spending
time
> on completely generic/flexible solution if no-one has expressed desire for
it?

Right, again. What do you think of the Boost.Tuple approach?

In your original posting, you said:

>I was thinking about
>
>   <boost/io/vector.hpp>
>   <boost/io/set.hpp>
>
>and so on. There are basically two approaches:
>
>1. Operators use fixed format: bracked list with commas between values for
>    vector, for example.
>2. Manipulators are provided to set brackets and separators.
>
>I had implemented the second approach some time ago, but it turned out that
>was overkill. So, 1) looks better now.

Boost.Tuple uses the second approach, and it seems it can be useful to
provide the possibility to change the separators. It's still a quite simple
solution.

> >>Very true,  but some libraries are useful simply because they're simply
> > code that
> >>people would write themselves over and over... only done in a better
way.
>
> +1. I've tried to make the same point above.

You both succeeded. :)

> >>written default for this makes it all worth it for me!  The for loop has
> > no chance
> >>of being evaluated properly in a debugger, but a debugger can likely
call
> > the <<
> >>operator with less difficulty.
> >
> > Right.
>
> +1, again.

This would also be the case for the tuple approach.

Regards,

Terje