Vladimir Prus wrote:
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 (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