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 ---
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
- set_close(char) defines the character that is output after the last
- set_delimiter(char) defines the delimiter character between elements.
Note, that these manipulators are defined in the tuples subnamespace. For
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]
tuple<int, int, int> i;
tuple<int, int> j;
cin >> i;
cin >> tuples::set_open('[') >> tuples::set_close(']') >>
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
--- 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
> > 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
> > objects, but no specific way for composites. The question is if we
> > have that. :) Maybe the reason we don't have it, yet, is that it may be
> > 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
> fixed output format is better that have nothing. As you've noticed, my
> original motivation was debugging output, and I still find this important
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
> >>>development is typically quite different. With an application, you
> > typically have quite specific requirements. With a library component,
> > it's about anticipating future use. Or making something general enough
> >>>useful as a library component.
> But you don't write library, put a seal on it, and stop. There's nothing
> 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
> on completely generic/flexible solution if no-one has expressed desire for
Right, again. What do you think of the Boost.Tuple approach?
In your original posting, you said:
>I was thinking about
>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
> >>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
> +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
> > the <<
> >>operator with less difficulty.
> > Right.
> +1, again.
This would also be the case for the tuple approach.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk