Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-09-20 12:23:43

Vladimir Prus wrote:

Hi Volodya,

> >>Do you provide the ability to use different separators for sequences,
> >>and maps?
> >
> > In the review version of the library, there are two sets of default
> > values: one for n-ary types formatting as "( a, b )" and one for the
> > sequence types, formatting as "[ a, b, c ]". In the version I am
> > rewriting, I only have one set of default formatting: "[ a, b, c ]".
>That's bad, I'd rather prefer different formatting styles for sets and

Hmm. Note that this is for the default values, i.e. you can set the
formatting you want when constructing a format object construct.

> >>Then I don't understand why you can
> >>set different default style for those kinds of object, and cannot
> >>selectively
> >>override the style
> >
> > Because the way I am storing it on the stream is based on decoration
> > (open; close; separator) and not on the format object type.
>Why? Is there any specific difficulty with using format object type (or
>"kind") as key?

The current implementation in the post-review version that I am developing
uses a simplified approach in dealing with pword -- it assumes that the type
is const CharT * and is not allocated (i.e. is a string literal).

It would be possible to do based on format object type, but that would
increase the complexity of the code.

> > A wrapper_decorator is one that only has open and close decoration
> > Thus, it wraps the object associated with it (via a format object):
> >
> > template< class OutStream, typename T >
> > OutStream & write( OutStream & os, const T & elem )
> > {
> > return( os << open << elem << close );
> > }
>Is this a method of 'wrapper_decorators'?

It is a method of the format object used when writing to a stream.

> >>I agree that you might want to store and then restore STL container from
> >>file, and the library addresses this need to. But I don't understand why
> >>you would want to customize the formatting style. Basically, you either
> >>should
> >>the data to user, or not. In first case, you need a single usable style.
> >>For
> >>the second case, you might need another "compact" style. I don't see the
> >>point of customization.
> >
> > It is currently possible to state what style formatting an object takes
> > using the decorate function (format in the review implementation). Thus:
> >
> > // review implementation:
> > std::cout << io::formatob( vec ).format( "( ", " )" ); // ( a, b, c,
> > )
> >
> > Here, the separator is not set and thus takes the default value (the one
> > provided by one of the mechanisms outlined above).
>Ok, aside from naming, the above is fine.

The naming issue has been discussed earlier in the review. In the
post-review version, the above example is:

   std::cout << io::object( vec ).decorate( "( ", " )" ); // ( a, b, c, d )

(I know the review is still in process, but I have been working to address
the issues in the review version of my library.)

> > You might want to customize formatting for various reasons. One example
> > if you have:
> > std::list< std::string > names;
> > and want to write that out as a HTML ordered list. You can do the
> > following:
> >
> > std::cout << io::formatob( names ).format( "<ol><li>", "</li></ol>",
> > "</li><li>" );
>Is this a practical use case?

Reviewers have requested the ability to generate XML/HTML. This is to show
that it is possible to do that within the existing framework.

>Well, you can print 'names' this way, but if
>you want to print 'Person', you'll need much more powerfull tools. Anyway,
>if the overhead is small, no problem.

If Person supports << on a stream, you can do:

   std::list< Person > people;
   std::cout << io::formatob( people ).format( "<ol><li>", "</li></ol>",
"</li><li>" );

> > It is also
> > possible to provide a basic form of message localization, reading a
> > std::map< std::string, std::string > in from a file. E.g.:
> > [snip]
>That's more like an artificial example, I think. For practical uses, the
>message catalog would have to contain comments, at least, and that again
>requires much more complex parser.

This is true. Although, you could write a custom state object to skip
comments and then bind that to the formatter.

>I'll try to write a complete review soon,
>so stay tuned ;-)

(What frequency are you broadcasting at ;))


It's fast, it's easy and it's free. Get MSN Messenger today!

Boost list run by bdawes at, gregod at, cpdaniel at, john at