Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-29 06:25:01

During the review of the output formatters library, there were suggested
several alternative approaches. For example, Gennadiy thinks the library is
too complicated, and Hartmut suggests creating a library dual to Spirit --
which would be extra powerfull.

That's not all. Independently, I've talked with Vaclav Blazek, who's the
author of the Teng text template engine (, which
is also a similiar domain -- it's too about formatting objects.

It would be great if we had some common foundation, so that I could output
ptr_vector<Function> using both a simple formatter, or a flexible one, or
even some template engine.

Such foundation can be pretty simple:

1. A fixed set of type "categories" (sequence, map, tuple, something else) and
a mechanism to obtain the category for a specific type. The current library
even has some mechanism, but I'm not sure if's as simple as possible and is

2. A mechanism to iterate over elements of composite type. After some though,
I believe that the mechanism should be boost::serializaton.

Take, for example, sequences. The reviewed version of the library contains the
code to handle boost:array, vector, list, and pair. The amount of code
devoted for this is significant. If serialization library were used (it
provides 'save' and 'load' functions for those types), the implementation
would be simpler: The basic formatter could look like:

   class formatter {
       template<class T>
       void write(T &t, is_primitive) { os << t; }
       template<class T, class Category>
       void write(T &t , Category {
          os << start_delimiter<Category>();
          os << t;
                 os << end_delimiter<Category>()
       template<class T>
       formatter& operator&(const T& t) { write(t); }

The idea of the library, as I see it, is to provide object serialization, but
- without the overhead serialization library has
- with extra layout tweaks

I don't see why it's necessary to reinvent the object traversal code which is
already in boost::serialization. For example, boost::serialization support
scoped_ptr. It would not make sense to add separate support for scoped_ptr in

And, as I've already mentioned I'd like the 'serialize' approach even for
class members. Even if serialization headers which provide support for
vectors, lists and so on drag too many dependencies, I think this is fixable.

On the top of this, it's easy to provide various output facilities.

- A simple multi-line indenting formatter. No customization at all, no

- A more advanced solution which uses nested formatters (like the revieved
version), and stores formatting information in iword/pword

- An interface with template system: e.g.

   Template t(...);
    vector<Function> f;
    t["functions"] = f;

would traverse 'f' creating a tree of values which can be used in template.


- Volodya

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