Terje Slettebų wrote: > > >From: "Vladimir Prus" <[EMAIL PROTECTED]> > > 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 :) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost