Boost logo

Boost :

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,
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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk