June 2004 - Boost - lists.boost.org

Announcing a New Online C++ Zine
by Chuck Allison 14 Jun '04

14 Jun '04

Hello Boosters, David Abrahams suggested I could send you an announcement on this list. For some time now (since last October, actually) a group of C++ luminaries have been discussing the virtues and possibilities of a peer-reviewed source for the C++ community. We have decided on the name "The C++ Source", and a preliminary page is available for viewing at http://www.artima.com/cppsource. The idea is to have seasoned C++ professionals review submissions to ensure that the publications are of high quality and of interest. There will also be tutorials, news, lots of stuff. The Editorial Board currently is: David Abrahams J. Stephen Adamczyk Andrei Alexandrescu Matthew Austern Pete Becker Walter Bright Steve Clamage Greg Colvin Jim Coplien Stephen Dewhurst Howard Hinnant Bjorn Karlsson William Kempf Andrew Koenig Martha Masinton Scott Meyers Thomas Plum Dan Saks Jerry Schwarz Jeremy Siek Bjarne Stroustrup Herb Sutter Matthew Wilson Leor Zolman (Like, wow!) I am writing to invite you to consider writing for The C++ Source. In fact, the first installments to appear later this month include an article by Booster Bjorn Karlsson. The chances that anything of interest to you will be of interest to the C++ community at large, and will make a positive contribution to daily C++ development. If you have any ideas, proposals, or suggestions, please email me at chuck(a)freshsources.com. Thanks! -- Best regards, -- Chuck Allison

5 5

RE: [boost] Re: Documentation
by Reece Dunn 14 Jun '04

14 Jun '04

John Nagle wrote: >Robert Ramey wrote: >>As far as writing documentation is concerned I found the the "standard" >>boost position at: >> >>C:\boost_1_31_0\more\writingdoc\index.html > > I'm having trouble reading your C: drive. Try replacing "C:\boost_1_31_0" with either http://www.boost-consulting.com/boost or the directory where your copy of Boost is located, e.g.: http://www.boost-consulting.com/boost/more/writingdoc/index.html HTH Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] Documentation
by Reece Dunn 14 Jun '04

14 Jun '04

David B. Held wrote: >Ok, if the Boost style documentation is too simple, and docs like >Spirit are too cute, what is a nice, happy median? Have you looked at the BoostBook generated docs :). Let me know what you think of the current L&F: I have updated this a while ago to try and bridge the gap between the two looks (the docs now have Spirit-style navigation). See http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/doc/html/ind… for the new-stle docs. >If we're going >to demand uniformity in licensing, should we also demand more >uniformity in documentation? I agree on this. At the moment, we have the docs written in HTML, those in BoostBook format (like Boost.Any and the BBv2 docs) and the Spirit docs which have their own format. As far as I understand it, the BoostBook tool is relatively new and has a learning curve, so it will take some time to migrate the docs to this format. As for the Spirit docs, they have their own sourceforge area as well as being a part of Boost, so forcing them to change doc format wouldn't be fair. However, since the Spirit docs are in a special text format that is "compiled" into HTML using Spirit, it should be easy to create a BoostBook back-end and have the docs in boost in this format and the ones on the sourceforge area in the existing format. With this in mind, it might be beneficial to create a HTML to BoostBook converter (possibly using Spirit) to allow easier migration to the BoostBook format. >I think a single documentation style >across Boost would make it even easier to learn new libraries. I >recently found it very difficult to find the information I wanted about >the Boost.Test library, as well as Boost.Preprocessor. What can >be done about these issues? I think the BoostBook format would go a long way to resolving these issues, once the docs are all in this uniform format. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

6 6

config tests breaking change imminent
by John Maddock 14 Jun '04

14 Jun '04

Following our recent discussion on file naming conventions, I've submitted a Sourceforge support request to have all the *.cxx files in libs/config/test renamed to *.ipp. When this change takes place the config tests will be broken until further notice (but probably only for a day or two). Regards, John.

2 1

Re:[boost] Re: Re: config and .cxx extensions
by Robert Ramey 14 Jun '04

14 Jun '04

Jeff Flinn wrote: > If it's VisualStudio, you can add the extensions to the registry to act > like headers or source(compilable) files. I would bet most others have a > similar facility. Please tell us how to do that. I looked for this and couldn't find it. I would like to tell my Visual.Net IDE to treat *.ipp file like *.hpp and *.cpp for editing purposes. Robert Ramey

3 2

Re: Documentation
by Robert Ramey 14 Jun '04

14 Jun '04

As far as writing documentation is concerned I found the the "standard" boost position at: C:\boost_1_31_0\more\writingdoc\index.html To be very helpful. I think it goes a long way to providing a common look and feel the boost docs. By providing a skeleton document for a boost library it also saves a lot of work. I tried to follow it as closely as possible for the boost serialization library. I think the discussions around boost documentation should focus on how this "document" document (meta-document?) should be updated. So it might a) Be a little more specific re tutorial and reference documentation sections. This is not quite as easy as one would first think as the requirements for formatting/tables of overloads are different from from function calls, etc. b) Suggest a common navigation facility. I actually liked the navigation pane used by the BOOST_PP library and have incorporated something similar in the new serialization library documentation. I find it very helpful. Robert Ramey

2 1

[Boost-bugs] [ boost-Bugs-972406 ] Tokenizer.hpp doesn't work with BOOST_ENABLE_ASSERT_HANDLER
by SourceForge.net 14 Jun '04

14 Jun '04

Bugs item #972406, was opened at 2004-06-13 22:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=972406&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tokenizer.hpp doesn't work with BOOST_ENABLE_ASSERT_HANDLER Initial Comment: Using boost-1.31.0 Tokenizer.hpp has #include <cassert> on line 23 - this prevents a custom assert function from working properly when trying to use BOOST_ENABLE_ASSERT_HANDLER. It looks like token_iterator.hpp and token_functions.hpp also do the same thing. It would be nice if these used the common boost assert mechanism instead of directly #including <cassert>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=972406&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: BGL: Shadow Warnings
by Perry Kundert 14 Jun '04

14 Jun '04

The -Wshadow warnings also affect the "spirit" parser. Attached is a patch that fixes up a number of quite verbose warnings about shadowing variables... David A. Greene wrote: > Jeremy Siek wrote: > >> Hi David, <snip> > > The option seems to be a little flaky in that it flags some things > that I don't think it should, but it's still a good debugging tool. > >> I'm currently extremely busy with school work, so it may take a while >> for me to get to this. If you want to send me a patch to fix these >> problems I'd be thankful. > > > I feel your pain. :) I'll see what I can do, but no guarantees. > > -Dave > --- boost_1_31_0-stock/boost/spirit/core/impl/match.ipp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/impl/match.ipp 2004-06-09 09:05:20.000000000 -0600 @@ -17,12 +17,12 @@ : len(-1), val() {} template <typename T> - inline match<T>::match(std::size_t length) - : len(length), val() {} + inline match<T>::match(std::size_t length_) + : len(length_), val() {} template <typename T> - inline match<T>::match(std::size_t length, ctor_param_t val_) - : len(length), val(val_) {} + inline match<T>::match(std::size_t length_, ctor_param_t val_) + : len(length_), val(val_) {} template <typename T> inline bool @@ -64,11 +64,11 @@ inline match<nil_t>::match() : len(-1) {} - inline match<nil_t>::match(std::size_t length) - : len(length) {} + inline match<nil_t>::match(std::size_t length_) + : len(length_) {} - inline match<nil_t>::match(std::size_t length, nil_t) - : len(length) {} + inline match<nil_t>::match(std::size_t length_, nil_t) + : len(length_) {} inline bool match<nil_t>::operator!() const --- boost_1_31_0-stock/boost/spirit/core/non_terminal/parser_id.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/parser_id.hpp 2004-06-09 09:17:33.000000000 -0600 @@ -100,7 +100,7 @@ : parser_id(reinterpret_cast<std::size_t>(this)); } - void set_id(parser_id id) { tag = id; } + void set_id(parser_id id_) { tag = id_; } private: --- boost_1_31_0-stock/boost/spirit/core/non_terminal/rule.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/rule.hpp 2004-06-09 09:42:46.000000000 -0600 @@ -157,8 +157,8 @@ return ptr.get(); } - rule(abstract_parser_t const* ptr) - : ptr(ptr) {} + rule(abstract_parser_t const* ptr_) + : ptr(ptr_) {} scoped_ptr<abstract_parser_t> ptr; }; --- boost_1_31_0-stock/boost/spirit/core/non_terminal/impl/rule.ipp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/impl/rule.ipp 2004-06-09 09:43:51.000000000 -0600 @@ -224,7 +224,7 @@ template <typename ParserT, typename ScannerT, typename AttrT> struct concrete_parser : abstract_parser<ScannerT, AttrT> { - concrete_parser(ParserT const& p) : p(p) {} + concrete_parser(ParserT const& p_) : p(p_) {} virtual ~concrete_parser() {} virtual typename match_result<ScannerT, AttrT>::type --- boost_1_31_0-stock/boost/spirit/core/scanner/scanner.hpp 2004-01-19 16:15:56.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/scanner/scanner.hpp 2004-06-09 09:44:41.000000000 -0600 @@ -240,22 +240,22 @@ bool at_end() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - return iteration_policy_t::at_end(*this); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + return iteration_policy_t_::at_end(*this); } value_t operator*() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - return iteration_policy_t::filter(iteration_policy_t::get(*this)); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + return iteration_policy_t_::filter(iteration_policy_t_::get(*this)); } scanner const& operator++() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - iteration_policy_t::advance(*this); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + iteration_policy_t_::advance(*this); return *this; } --- boost_1_31_0-stock/boost/spirit/dynamic/stored_rule.hpp 2004-01-19 16:15:56.000000000 -0700 +++ boost_1_31_0/boost/spirit/dynamic/stored_rule.hpp 2004-06-09 09:45:53.000000000 -0600 @@ -109,8 +109,8 @@ private: #endif - stored_rule(shared_ptr<abstract_parser_t> const& ptr) - : ptr(ptr) {} + stored_rule(shared_ptr<abstract_parser_t> const& ptr_) + : ptr(ptr_) {} shared_ptr<abstract_parser_t> ptr; }; --- boost_1_31_0-stock/boost/spirit/core/non_terminal/subrule.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/subrule.hpp 2004-06-09 09:48:16.000000000 -0600 @@ -209,7 +209,7 @@ subrule_list< subrule_parser<ID2, DefT2, ContextT2>, nil_t> > - operator,(subrule_parser<ID2, DefT2, ContextT2> const& rhs) const + operator,(subrule_parser<ID2, DefT2, ContextT2> const& rhs_) const { return subrule_list< self_t, @@ -219,7 +219,7 @@ *this, subrule_list< subrule_parser<ID2, DefT2, ContextT2>, nil_t>( - rhs, nil_t())); + rhs_, nil_t())); } typename DefT::embed_t rhs; @@ -257,10 +257,10 @@ parse_main(ScannerT const& scan) const { typedef typename parser_result<self_t, ScannerT>::type result_t; - result_t result; + result_t result_; impl::parse_subrule<result_t, ScannerT, ID>:: - do_(result, scan); - return result; + do_(result_, scan); + return result_; } template <typename ScannerT> --- boost_1_31_0-stock/boost/spirit/symbols/symbols.hpp 2004-01-19 16:15:57.000000000 -0700 +++ boost_1_31_0/boost/spirit/symbols/symbols.hpp 2004-06-09 09:49:14.000000000 -0600 @@ -114,13 +114,13 @@ { typedef typename ScannerT::iterator_t iterator_t; iterator_t first = scan.first; - typename SetT::search_info result = SetT::find(scan); + typename SetT::search_info result_ = SetT::find(scan); - if (result.data) + if (result_.data) return scan. create_match( - result.length, - symbol_ref_t(*result.data), + result_.length, + symbol_ref_t(*result_.data), first, scan.first); else

2 1

BOOST_DEBUG like macros: current state overview
by Pavel Vozenilek 13 Jun '04

13 Jun '04

Some time ago I suggested to add support for BOOST_DEBUG and BOOST_NDEBUG macros into guidelines. I searched how individual libraries (1.31) handle debug support: ------------------------------------- * lexical_cast - uses assert() * dynamic_bitset - uses assert() * filesystem - uses assert() * graph - uses assert() * interval - uses assert() * thread - uses assert() * tokenizer - uses assert() * random - uses assert() * lambda - uses assert() * multi_array - uses assert() * signals - uses assert() * format - uses BOOST_ASSERT() * function - uses BOOST_ASSERT() * variant - uses BOOST_ASSERT * optional - uses BOOST_ASSERT * smart_ptr - uses BOOST_ASSERT and macro with somewhat misleading name BOOST_SP_ENABLE_DEBUG_HOOKS * concept_check - uses NDEBUG directly * ublas - uses its own macro BOOST_UBLAS_CHECK depending on NDEBUG. Documented * python - uses its own macro BOOST_PYTHON_INDEXING_CHECK_INVARIANT depending on NDEBUG and also NDEBUG directly. Not documented * regex - uses assert() based on BOOST_REGEX_DEBUG and jm_assert (macro too). Uses also BOOST_REGEX_DEBUG directly. No dependence on NDEBUG. Not documented. * spirit - uses macro BOOST_SPIRIT_ASSERT depending on assert() as well as handful of other library specific debug macros. Well documented. Circular Buffer, Multi Index Container and likely Serialization contain (documented) extensive support for debug mode with their specifi macros and different level modes. ------------------------------------- Documentation usually doesn't mention if/how debug support is implemented. Maybe common macros would make life of Boost user easier. /Pavel

2 2

config and .cxx extensions
by David Abrahams 13 Jun '04

13 Jun '04

Is there a good reason that the config library needs to use a "creative" choice of file extensions rather than the boost standard of ".*pp"? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

7 14