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. > Overloading of class templates might have helped, here. E.g.: > > std::cout << io::set_format<std::vector<std::pair<char,int> >(...); // Set > specific format (io::format is a class template) > std::cout << io::set_format<std::vector>(...); // Set generic format for > std::vector (io::format overloaded with a version taking template template > parameter, and specialised for std::vector) Yes, it would definitely have helped. > 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. 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>(...) ; > > >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. - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost