>From: "Vladimir Prus" <[EMAIL PROTECTED]> > Terje Slettebų wrote: > > > Right. There was a suggestion for allowing generic formats, though, using > > the same format for all instantiations of a template. The question is how > > to do it. The current version stores the format for each specific type, as > > you say. Volodya suggested a couple of ways it could be done, partial > > specialisation, or storing the template name in a map. However, it could be > > hard to use the latter, as it could be hard to find the right type to look > > up, when outputting, given that you have specific types, not templates. > > Uhm... I meant that the right type should be explicitly written down: > > template<class T> > ostream& operator<<(ostream&, const vector<T>& v) > { > const composite_format& cf = composite_format::get("vector"); > } > > not nice, but should work.
Ah, I see. That would work. > > If partial specialisation was used instead, you'd still need to specify the > > full type (even if only the generic format is set), and then, how to > > differentiate between specific and generic format? For example: > > > > std::cout << io::set_format<std::vector<std::pair<char, int> >(...); // > > Uses partial specialisation of class template set_format for std::vector, > > setting generic format > > Oh... so here's the gotcha! I definitely don't like this syntax for setting > format for *all* vectors. Me neither. It looks like it sets it for a specific type. > Maybe, we can go even simpler way: introduce > separate classes for all container kinds. BGL already has vecS, setS, and so > on. The syntax for setting format will be > > cout << io::set_format<vecS>(...) ; Yeah, that could be a way. > > > >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. > > > > Right. Well, as mentioned, the current version uses format for specific > > types, so in that case, you could format each part of the nested container > > as you wanted, as shown with the 2D-array, which of course is an array of > > arrays. > > I think that nested containers should be handled in a more explicit way. Why > can't we allow to explicitly set braces/delimiters for container at certain > nesting level: > > cout << io::set_format<vecS,1>(...) > > would change delimiters only for top-level container. The question is that the > same code can be called both from top-level and when outputting some > container. It would be possible to just reset nesting level, and restore it > after outputting. Yeah, like with I/O state savers. I'll do some more experimentation with this, and others are free to do the same with the code, of course. I haven't yet updated it much, from the version at Yahoo Files, since it hasn't really been certain what the design should be. Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost