[boost] Re: Re: Formal review of "Output Formatters" librarybeginstoday

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-09-12 10:17:38

"Reece Dunn" <msclrhd_at_[hidden]> wrote in message
news:BAY24-F40qFXfyY0QUU00057091_at_hotmail.com...
| Thorsten Ottosen wrote:
| >Here are some general comments:
| >----------------------------------
| >
| >0. I think the library should be put in the directory
| >"boost/output_format"
| >I hate cryptic names.
|
| Or "boost/ioformat" since it also has input capabilities :). There was talk
| when I was developing the library about moving it into the "boost/io"
| directory, but that seems to be getting a little crowded ;)

anyone will do...but please don't concatenate names.

| >2. In this example
| >
| >       int a[] = { 5, 4, 3, 2, 1 };
| >       std::cout << boost::io::formatob( boost::io::range( a, a + 5 ));
| >       std::cin  >> boost::io::formatob( boost::io::range( a, a + 5 ));
| >       // output: [ 5, 4, 3, 2, 1 ]
| >
| >it might be good to support a range version with the posibility to
| >
| >1. throw if there is too few elements
| >2. default initialize if there is too few elements
|
| You mean when reading in the input?

yes.

|The default behaviour is to set the
| input stream fail bit, so you can check that.

Ok, I guess that goes in hand with the bahavior of the standard library
(although I prefer throw by default).

could syntax like

std::cin >> io::throw_on_error() >> io::formatob( ... )
std::cin >> io::default_init_rest() >> io::formatob( ... )

be supported too.?

| >3. cryptic name: formatob.hpp && formatobex; should be format_object and
| >whatever the latter really means
|
| I was going for ease of typing :). maybe
| boost::io::format/boost::io::formatex. The latter allows you to control the
| delimeter type being used, so you can do:

yeah, what does "ex" mean?

| I was thinking here about performance. The default type is const char *
| which should be fairly flexible without providing compy penalties.

seems reasonable...just mention this stuff in the docs.

| >5. A lot of boost::io::range() can be replaced with one Taking a Single
| >Pass
| >Range
|
| You mean from your Boost.Range library? This is something that I am
| considering, but don't know enough of the library to do this yet.

Ok, basically you can replace

foo( std::pair<iterator,iterator> );
foo( T (&array)[sz] );
foo( const standard_container& )
foo( builtin-strings );

with one function taking a Range

foo( const Range& );

| >6. STL IO: It is not obvious how insertion is done? With push_back or by
| >overwriting elements?
|
| The container is cleared and insert is used to insert the elements into the
| container.

ok, a small comment about it would be good.

| >7. why is it necessary with
| >            boost::io::formatob( boost::io::range( a, a + 5 ));
| >    could we not just say
| >            boost::io::range( a, a + 5 );
|
| Because the boost::io::range_t class (created by boost::io::range) does not
| provide input/output functionality. It is a holder for a range [first,
| second) so that boost::io::formatob can process it. This is if you either
| specify a std::pair (boost::io::formatob treats this as a 2-ary type and not
| a range holder) or a (first, last) pair of values (since boost::io::formatob
| accepts a single object).

hm...it seems to me that boost.range has all you need:

class iterator_range or class sub_range +
function make_iterator_range( a, a + 5 );

I could probably benefit you code to use this instead (unless I'm overlooking
something).

You can look at the range docs in the main cvs in /libs/range/doc

| >9. I would prefer basicfmt_t to be basic_format_type or perhaps
| >basic_fmt_type
| >if the "fmt" shorthand is used consistently etc. That is, all the cryptic
| >     concatenation should be removed.
|
| That would make things fairly long-winded. For example:
|
|    std::pair
|    <
|       std::pair< int, std::vector< char > >,
|       std::list< std::complex< float > >
|    > mct;
|
|    std::cout << boost::io::format_object( mct,
|       boost::io::pair_format
|       (
|          boost::io::pair_format
|          (
|             boost::io::basic_format(),
|             boost::io::container_format()
|          ),
|          boost::io::container_format( boost::io::nary_format())
|       )
|    );
|
| compared to:
|
|    std::cout << boost::io::formatob( mct,
|       boost::io::pairfmt
|       (
|          boost::io::pairfmt( boost::io::basicfmt(),
| boost::io::containerfmt()),
|          boost::io::containerfmt( boost::io::naryfmt())
|       )
|    );

yeah, I know, but at least say pair_fmt instead of pairfmt etc.

| I am not sure what you mean by concatenation.

the contraction of X_fmt to Xfmt.

| Okay, I will bear that in mind. FYI, the above function returns:
|    formatob_t< T, DelimeterType, typename deducer< T, DelimeterType
|  >::type::outputter >
| ! My rationale for not supplying the return types was to not consume more
| space and not confuse readers. Marking them *implementation defined* would
| be a good idea.

yeah, that would be sufficient.

br

Thorsten