Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk