Boost :

ramey_at_[hidden]

-- 
>> 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 (http://teng.sourceforge.net/),
which 
>> is also a similiar domain -- it's too about formatting objects.
>I will try to take a look at it next week.
>> 
>> 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.
> 
> 
>> 2. A mechanism to iterate over elements of composite type. After some
though, 
>> I believe that the mechanism should be boost::serializaton.
>This sounds nice, but I don't know how achievable it is.
>Basically, when writing a composite type, you might want to write things 
>in-between. Like, for a pair, you might want to write:
> [first, second]
>or
><<first | second>>
> (where first and second are the members of the pair)
>Same goes for each composite type.
>I'm not very familiar with boost::serialize - still it is something to 
>think about ;)
The serialization library provides formatting/recovery for all composite
types with no special effort by the programmer.  This is usually suitable
for the type of output file being used.  In cases where it isn't, the
output/input can be overloaded on a type by type basis.  In practice few
have found it necessary or valuable to do this.
>> 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
>Yes, it would be nice.
For objects of the type being discussed, (i.e. no pointers, no class
versioning, no memory tracking of duplicates, etc) the serialization library
has no extra runtime overhead.  I would be very surprised if the
serialization library did not result in smaller and faster code than the
libraries being discussed.
>> 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 
>> outfmt.
The serialization library has all that and much, much more. 
>I would need to delve further into boost::serialize to have an oppoinion 
>- and the unfortunate thing is that I won't have any available time soon :(
Too bad, it would have consumed much less time than has been already spent
on this topic
If function output formatters is helpful for making output more easily
presentable, fine. Though G. Rozenthal's, experiment makes me doubt this.
If the purpose is to save and restore the state of some assortment of class
instances - it's the same as the serialization system and should evaluated
as an alternative with a full blown comparison.
I believe the demos and documentation in the serialization package show that
it to be much, much easier to use than the proposed library for this
purpose.
Robert Ramey