[boost] Re: Re:Re:Re: Output formatters: different approaches

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-04 01:07:20

Gennadiy Rozental wrote:

>> >>Which experiment?
>> >
>> > I was referring to Rozenthals post:
>> > http://lists.boost.org/MailArchives/boost/msg71956.php
>>
>> And why that code makes you doubt that function output formatters are
>> helpfull? Basically, he just implemented the same idea: formatter, which
>> has some begin/end string and nested formatter for elements.
> 
> Sorry, I am not exactly follow point you both are trying to make. But code
> was trying to prove that everything submitted library doing in regards to
> output (I am not interested in input any case) could be done in 200 line
> header without need for complex metaprogramming. I believe my example
> covers all possible formats that were discussed during review. Its hard to
> imagine that one would need something more that this code provides and
> that it generic enough to be covered by library. 

When comparing your code and the proposed library, I have two points.

First, the proposed one has a lot of code to detect what kind of object is
output, for getting its elements, and so on. This adds a lot of complexity
and should be avoided -- by using serialization library to do the task.

Your implementation is indeed simple. But: it contains code which iterators
over elements of a vector. Should I define my_cool_vector, I'd have to
define an overload that your code can use. I'd prefer to defining only
overload for serialization library, and have the output library use that
automatically.

Another point about your implementation is that it does not distinguish
between sequences/maps -- which might be desirable.

> Would you want something 
> like string format ("% | %") it could be easily added, though I question
> its usability. It assumes a lot of things when applied to multivalue
> container. As for reflection framework, I would be interested in generic
> solution, but again not in a context of output formatting specifically (I
> may use it for this purpose, but not design it for this purpose).

What I'm proposing is that output library use the *existing* mechanism,
provided by the serialization library.

- Volodya