
Paul A Bristow wrote:
* There is a terribly central spelling mistake which nobody seems to noted so far:
A _delimiter_ does de-limit things and has nothing to do with deli_s or meter_s! A global search in replace in code and docs is vital.
<blush>
* I strongly dislike abbreviations and concatenations. It is MUCH easier to read/understand and consistent with STL styling to use full words and _s, if a bit longer to type. naryfmt really must qualify for some prize. nary_format or n_ary_format. "Boost prefers clarity to curtness".
I have been giving this some thought. What I am looking at at the moment is something like: std::pair < std::pair< int, std::vector< char > >, std::list< boost::math::quaternion< float > >
mct;
namespace io = boost::io; namespace fmt = boost::io::format; std::cout << io::object( mct, fmt::pair ( fmt::pair( fmt::basic(), fmt::container()), fmt::container( fmt::nary()) ) ); With io::delimiter holding one of the delimiter values. io::wrapped_delimiter will replace io::openclose_formatter in holding open/close delimiter pairs and io::sequence_delimiter replaces io::formatter.
| 3. What is your evaluation of the documentation? OK -
Though I am not a fan of background coloured boxes for code - I think the font change is enough.
One thing I would REALLY REALLY like is a Boost 'Standard' way of colouring and indenting code similar to Visual Studio IDE - though I don't feel their colour scheme is quite as good mine!
What do you think about the new Boost.quickdoc? The docs for quickbook are available at http://tinyurl.com/64el7, and the source is at http://tinyurl.com/4tdjj. Thanks to Eric and Joel for this great tool.
| 8. Do you think the library should be accepted as a Boost library? Yes - but with some name changes.
See above.
And I would like to see active work by all authors to ensure that this interacts with the filtering, range, more_io libraries before the first actual full release (in 1.33?) so that the documentation cross-references too, including examples of combinations of these techniques.
I am willing to co-operate.
I can understand that authors are unwilling/unable to work together until they are sure which other libraries can be assumed a part of Boost, and I think we must accept (and flag up) that there will probably be changes, perhaps major, while interworking is perfected. The three recent IO contributions, with serialisation, are prime candidates for mutual refinement.
Sure. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/