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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-09-12 10:55:13

Thorsten Ottosen wrote:
>"Reece Dunn" <msclrhd_at_[hidden]> wrote
>| Thorsten Ottosen wrote:
>|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.?

Possibly. I'd need to look into this.

>| >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?

"extended". A better name is probably needed and should be consistent 
throughout (i.e. for boost::io::wrappedfmtex, etc.) The problem is how to 
keep close to the original so that you know what it does and also tells you 
that this variant controls the delimeter type, since you can't reuse the 
original name due to overload resolution issues.

>| 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.

It is (in a round-about way). I have fixed in my local docs to say: "This 
uses const char * as its delimeter storage type."

>| >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& );

Great! I will replace boost::io::range and boost::io::range_t with this 
post-review.

>| >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.

Done in local docs.

>| >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).

Nope. I'll update post-review.

>| >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:
>| [snip]
>
>yeah, I know, but at least say pair_fmt instead of pairfmt etc.

Yes. This is better.

>| I am not sure what you mean by concatenation.
>
>the contraction of X_fmt to Xfmt.

Okay. I'll look at revising the affected names.

>| 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.

Great.

Regards,
Reece

_________________________________________________________________
Check out Election 2004 for up-to-date election news, plus voter tools and 
more! http://special.msn.com/msn/election2004.armx