Re: [boost] Re: io operations for stl containers?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-02-26 10:07:04

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