[boost] Re: Review of Daryle Walker's "More IO" library beginstoday, August 21, 2004.

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-08-28 03:40:53

"Daryle Walker" wrote:

 _______________________________________________________________
> > 2. docs: some introduction into the library would help.
>
> This is a collection of many little libraries; I not sure that a grand
> introduction could be made.
>
Maybe something in form of table with features and their short description.

 _______________________________________________________________
> > 3. docs: source code snippets should be syntax colorized
>
> Even if that's a good idea, these are manually-created HTML files, so you
> have to wait until some automation is added.
>
Joaquín M López Muñoz had written very nice to use (Win32 based)
tool to syntax colorize sources (based on Spirit).

_______________________________________________________________
> > 4.
> >
> > #if (defined _MSC_VER) && (_MSC_VER >= 1200)
> > #  pragma once
> > #endif
> >
> > should be put into each of headers. It has
> > positive effect on VC ad Intel C++ compilation times.
>
> I'm not using Visual C++, Windows, or even a IBM-style PC, so I don't want
> to go crazy with cross-platform conveniences that I can't check.  I do
want
> to know about cross-platform bugs, hopefully with fixes.
>
It is technique widely used in Boost and its positive effect has been
reported.

 _______________________________________________________________
> > 5. naming conventions: some names as
> >
> >      basic_constpointerbuf
> >
> >  are quite hard to read. Maybe they should
> >
> >      basic_const_pointer_buf
>
> That standard stream (buffer) classes run their name-parts together.
>
IMHO it is big enough burden to decipher standard names.
Having hard to read names in 3pp libraries makes maintenance
frustrating.

> (What happened to entry #6?)
>
I found it mistake and didn't bother to renumber.

 _______________________________________________________________
> > 7. stream_buf_wrapping.hpp: there are three hardcoded
> >  constructors like:
> >
> >   template < typename T1, typename T2, typename T3 >
> >   basic_wrapping_ios( T1 x1, T2 x2, T3 x3 )
> >
> >  for 1, 2 and 3 parameters though base_from_member
> >  supports up to 10 parameters.
>
> I wrote base_from_member, and I extended BFM after initially writing
> More-I/O.
>
> >  Boost.Preprocessor can be used here to generate
> >  contructors of all available arities.
>
> Any suggestions on how?  And should I leave the arity number available in
> BFM (as a #define) so others can mirror it?
>
Jonathan answered. There are several ways to do it via Boost.PP, though.

_______________________________________________________________
> > 10. array_stream.hpp: the template
> >
> >   template < std::size_t N, typename Ch, class Tr >
> >   class basic_array_##SuffixF
> >
> >  may contain static assert N > 0.
>
> A zero-size array will choke the compiler anyway.
>
It may be problem with GCC - this compiler may accept 0-length arrays.

 _______________________________________________________________
> > 14. array_stream.hpp: the InputIterator in
> >
> >   template < typename InputIterator >
> >   basic_array_streambuf
> >
> >  can be 'concept-checked'.
>
> How?
>
statis assert that (*InputIterator || InputIterator::value_type) is
assignable to Ch.

> And it is worth the extra code?
>
IMHO yes.

> Like other templates, the current
> code will choke if the given type does not meet the expected interface
> (although with a nearly-incomprehensible error message).
>
That's the reason.

 _______________________________________________________________
> > 15. iomanip_form.hpp: in
> >
> >   explicit  basic_ios_form( ::std::basic_ios<Ch, Tr> const &i );
> >
> >   the parameters really should not be named 'i'.
>
> Why not?
>
'i' is used as index for loops, this may confuse someone reading through
code.

_______________________________________________________________
> > 17. iomanip_general.hpp: operator>>: I find the expression:
> >
> >      return s( is ), is;
> >
> >   abominable.
>
> I don't think you have the right filename.  Anyway, the code is hard to
> misinterpret and it saves a line.
>
I use the more_io4.zip.

I once had to debug code containing such trick and would kill at that
monent.

 _______________________________________________________________
> > 20 iomanip.html: it should be explained what is "form-based".
> >
> >  The documentation should NOT be annotated code, it is
> >  very unreadable.
>
> What do you mean by that?  I've tried to imitate the Standard's way of
> describing items.  Anyway, it's hard to be precise about the
actions/effects
> without getting close to code when the functions are simple.
>
I mean documentation should not be only annotated code.
I am looking for introduction and annotated examples.

/Pavel