"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