[boost] Re: io operations for stl containers?

From: Jason House (jhouse_at_[hidden])
Date: 2003-02-24 17:42:28

Terje Slettebø wrote:
> 
> >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.

I was wondering about this line of discussion earlier today... wondering
if it died on the vine or not.  I'm glad to see that it hasn't, and that
someone has been trying to think deeper into the application...

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

Well, it definitely seems like the tuples were thinking along similar
lines with a start, middle, and stop delimiters.
The documentation brings up a point about parseability of data streams.  
It doesn't quite make sense to me that there should be restriction to a
single character in order to to make things uniquely parseable.  If it's
a fixed sequence of characters, I don't see how that makes it any
significantly less parseable...  Maybe I'm missing something?

It does enable defaults and allows a way to customize each spacer
individually, which is a good addition.  I think the ability to set all
3 also is a must-have :)

The tuple functions, as provided should be extremely easy to call from a
debugger since there is no templating going on.  I think that if when
composite_format matures, there should be a way to add non-templated
calls to change defaults.
maybe:
namespace composite_format{
  namespace tuple{
    ... set_open(char x){ return composite_format_open<tuple>(x); }
  }
}

Actually that example doesn't quite work because <tuple> is not well
defined.  The previous discussion of composite_fromat (or at least the
code presented) did not allow for a generic class of types, and only
provided functionality for a very specific type.
 
> Maybe these routines could be generalised, and used for any
> composite/compound type, including tuples?

generic type = map, list, tuple
specific type = map<int,int>, map<int,float>, list<int>, etc...

I should try to think about this more than I have :(
>From what I have thought about it, allowing a generic type creates room
for unexpected behavior in output when there are composite types
containing composite types, and somewhere along the lines a *generic
type* default is overridden.  There might be a specific reason for a
bunch of lists inside of a composite type to have a specific set of
delimiters...  but it probably isn't desired for the lists inside those
lists to be forced into using the same delimiters.

There is also room for trouble when the delimiters for both a generic
type and a specific type have been set...  I'd think that in general,
the generic type would be lower precedence.  But what if the generic
type was set more recently?  Should there be two forms for setting a
generic type's delimiters?

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

I hope so :)