Subject: Re: [boost] [explore] Library Proposal: Container Streaming
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2009-12-01 12:22:38
> Michael Caisse wrote:
> > I've been trying to think of when I might use such a library. Without
> > the symmetry (input as well as output) I can think of few instances
> > where this functionality might come in handy. Other than potential
> > debug output, what else do you envision? What am I missing?
> Yes, I mostly think of this for debug output. But that does come up
> a lot. Similar to debug output would be testcase output. Something
> the customer still does not see, but is certainly useful. An example
> of something in production code might be printing a container out as
> an html table.
*verbatim["<li>" << stream << "</li>"]
<< "</ol>", // format description
'\n', // delimiter
c // data
) << std::endl;
(ok, not a table, but a list, but you get the idea) where c could be any
container type holding any data type.
And with some preparation it is easily possible to create a special html
framework allowing to write this as:
> > I'm also finding little improvement over the following example
> > based on your samples. Here I am using Karma to produce the same
> > output as Explore. It is a bit more verbose; however, it is
> > more flexible.
> In BoostCon 2007, we wanted something that worked like 'print(c)' where
> 'c' is any container. Other languages have this capability. We did
> consider using Karma during that conference and somebody presented
> this. It was decided to not be simple enough. The code samples you
> provided are compelling, but it's not as dead simple as 'print(c)' or
> the more C++ oriented 'cout << c'.
'cout << c' just doesn't work because of the need to use UB (extending
namespace std). So you will end up writing
cout << explore::format(c);
which would have the Karma equivalent of (Boost V1.41):
cout << karma::format(*stream, c);
or even (post V1.41):
cout << karma::format(auto_, c); or
cout << karma::format(c);
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk