>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
