From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-09-13 12:27:34
Paul A Bristow wrote:
>* There is a terribly central spelling mistake which nobody seems to noted
> A _delimiter_ does de-limit things and has nothing to do with deli_s or
> A global search in replace in code and docs is vital.
>* I strongly dislike abbreviations and concatenations. It is MUCH easier to
>read/understand and consistent with STL styling to use full words and _s,
>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
std::pair< int, std::vector< char > >,
std::list< boost::math::quaternion< float > >
namespace io = boost::io;
namespace fmt = boost::io::format;
std::cout << io::object( mct,
fmt::pair( fmt::basic(), fmt::container()),
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
>| 3. What is your evaluation of the documentation? OK -
> Though I am not a fan of background coloured boxes for code - I think
>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.
>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
Want to block unwanted pop-ups? Download the free MSN Toolbar now!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk