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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-10-02 11:25:23

> > Hmmm - I've been trying to configure my MS Outlook to do this and its
> > driving me crazy.
> :-( I think Gennadiy has managed to convince Outlook to work fine over
NNTP.
> Thunderbird works fine either way.

OE actually.

> >> 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.
> >
> >>Basically, I want every call I define to have a 'dump'
> >>method which can be called from debugger. So, I need output facilities
> >>available in every translation unit.
> >
> >>> If function output formatters is helpful for making output more easily
> >>> presentable, fine. Though G. Rozenthal's, experiment makes me doubt
> >>> this.
> >
> >>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. 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).

Regards,

Gennadiy.