From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-03-09 18:32:21
>From: "Vladimir Prus" <ghost_at_[hidden]>
> Terje Slettebø wrote:
> > Right. There was a suggestion for allowing generic formats, though,
> > the same format for all instantiations of a template. The question is
> > to do it. The current version stores the format for each specific type,
> > 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
> > hard to use the latter, as it could be hard to find the right type to
> > 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
> > 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
> > setting generic format
> Oh... so here's the gotcha! I definitely don't like this syntax for
> 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
> 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
> > > 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
> > > 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
> > as you wanted, as shown with the 2D-array, which of course is an array
> > arrays.
> I think that nested containers should be handled in a more explicit way.
> can't we allow to explicitly set braces/delimiters for container at
> nesting level:
> cout << io::set_format<vecS,1>(...)
> would change delimiters only for top-level container. The question is that
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk