- Boost - lists.boost.org

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

Can anyone help with this one?
by Thomas Don Aratari 12 Jun '04

12 Jun '04

Hello, I'm trying to upgrade my boost to 1_31 but I keep getting the following tokenizer error. I am using Forte 8.0 (CC: Sun C++ 5.5 Patch 113817-03 2003/10/14). Here is the code snip: (passing in sString to be tokenized) typedef boost::tokenizer<boost::char_separator<char> > tokenizer; boost::char_separator<char> seperator(sDroppedDelimiters, sKeptDelimiters, boost::keep_empty_tokens); tokenizer tokens( sString, seperator ); for (tokenizer::iterator tok_iter = tokens.begin(); tok_iter != tokens.end(); ++tok_iter) vInVector.push_back( *tok_iter ); "/home/dev/cm/THIRD_PARTY/boost/include/boost/iterator/iterator_facade.hpp", line 623: Error: Could not find a match for boost::iterator_core_access::equal<boost::iterator_core_access::Facade1, boost::iterator_core_access::Facade2>(const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::is_convertible<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>>). "MDSStringHelpers.cxx", line 183: Where: While instantiating "boost::operator!=<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>(const boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&, const boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&)". "MDSStringHelpers.cxx", line 183: Where: Instantiated from non-template code. Any ideas how to fix or has anyone else seen this? Thanks Tom

1 0

Re: New C++ Zine (Print version?)
by Chuck Allison 12 Jun '04

12 Jun '04

Hello Dave, Saturday, June 12, 2004, 11:01:35 AM, you wrote: brlbo> "Chuck Allison" <chuck(a)freshsources.com> wrote in message brlbo> news:15110019883.20040611130022@freshsources.com... >> [...] >> 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. brlbo> Is it likely there will be a print edition in the future? If so, is there a brlbo> timetable for it's appearance? brlbo> Dave We have discussed having a periodic (annual?) print anthology (a la C++ Gems), but of course, we haven't even launched yet, so we're getting ahead of ourselves. With sufficient success/resources, the answer is "yes". -- Best regards, Chuck

1 0

Re: Announcing a New C++ Zine
by Chuck Allison 12 Jun '04

12 Jun '04

Hello Alexander, I'm sorry, but that page is just a sample page. Bjarne's article is not an official posting. We haven't launched yet. If you want to discuss the content of Bjarne's comments, you can email him directly, but it has nothing to do with The C++ Source. Sorry if I didn't make it clear that that page was just a sample. I meant to. Saturday, June 12, 2004, 11:01:35 AM, you wrote: brlbo> Chuck Allison wrote: brlbo> [...] >> viewing at http://www.artima.com/cppsource. The idea is to have brlbo> Quoting from http://www.artima.com/intv/elegance.html. Few comments brlbo> follow. brlbo> <quote author=Bjarne Stroustrup> brlbo> I don't put in specific features for concurrency, because you can put brlbo> them in a library. brlbo> </quote> brlbo> You can't do that without threaded memory model, to begin with. brlbo> <quote> brlbo> C was designed with the principle that you should be able to write brlbo> its standard library in the language itself. That same principle brlbo> guided the design of C++. brlbo> </quote> brlbo> Show me the the standard C++ impl of atomic<> for a rather simple brlbo> thing like brlbo> class swap_based_mutex_for_windows { // noncopyable brlbo> atomic<int> m_lock_status; // 0: free, 1/-1: locked/contention brlbo> auto_reset_event m_retry_event; // "slow" bin sema/gate brlbo> public: brlbo> // ctor/dtor [w/o lazy event init] brlbo> void lock() throw() { brlbo> if (m_lock_status.swap(1, msync::acq)) brlbo> while (m_lock_status.swap(-1, msync::acq)) brlbo> m_retry_event.wait(); brlbo> } brlbo> bool trylock() throw() { brlbo> return !m_lock_status.swap(1, msync::acq) ? brlbo> true : !m_lock_status.swap(-1, msync::acq); brlbo> } brlbo> bool timedlock(absolute_timeout const & timeout) throw() { brlbo> if (m_lock_status.swap(1, msync::acq)) { brlbo> while (m_lock_status.swap(-1, msync::acq)) brlbo> if (!m_retry_event.timedwait(timeout)) brlbo> return false; brlbo> } brlbo> return true; brlbo> } brlbo> void unlock() throw() { brlbo> if (m_lock_status.swap(0, msync::rel) < 0) brlbo> m_retry_event.set(); brlbo> } brlbo> }; brlbo> regards, brlbo> alexander. -- Best regards, Chuck

1 0

Re: static sized strings (struct hack)
by Bill Seymour 12 Jun '04

12 Jun '04

Rob Stewart: > > From: John Nagle <nagle(a)animats.com> > > > From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > >> class fs_base > > >> { > > >> size_t len; > > >> szie_t capacity; // needed for buffer-safe operations > > >> CharT str[ 1 ]; > > >> // string manipulation functions > > >> > > >> fs_base( size_t c ): capacity( c ){} > > >> }; > > >> > > >> template< size_t n > > > >> class fixed_string: public fs_base > > >> { > > >> CharT data[ n ]; > > >> fixed_string(): fs_base( n ){} > > >> }; > > > > Are you assuming that "data[n]" physically follows > > "str[1]" in memory, and that "data[n]" can be addressed > > by subscripting "str[1]" out of range? ... > > Oh, right. It was C99 that blessed the struct hack. Oh well. > Well, yes; but the struct hack is not what the code above tries to do. What C99 says is that you can malloc sizeof(fs_base) plus some extra, then address str[2] to str[whatever up to malloc'd size]. Even in C99 (and even if C understood the C++-specific stuff in the above), there is no relationship between fs_base::str and fixed_string::data (except that they don't overlap). --Bill Seymour

2 1

More Math Functions
by Paul A Bristow 12 Jun '04

12 Jun '04

|-----Original Message----- |From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf |Of Tom Brinkman |Sent: 03 June 2004 00:54 |To: boost(a)lists.boost.org |Subject: [boost] Boost Mathematicians |What is the current status of all Boost mathmatical, |statistical and econometric libraries currently in |development? |The collection of boost math libraries that are |currently included in the library are world-class and |provide a wonderful foundation to build-upon. |However, many areas of advanced statistical and |mathmatical inference are not currently being \addressed by any of the boost libraries. I have been off-line for some time, but have now caught up with this discussion a bit. Strongly support your views and need these things yesterday ;-) Apart from messing about with Microsoft Windows problems, I have been preparing a formal proposal for C and C++ Standard Library TR-2 of a list of Math 'Special' Functions (additional to those from Walter Brown which have been accepted into TR-1). This list will include all the usual statistical suspects - including Student's t, Chi sqr, and F, so that at last it will be possible easily write C++ to provide the probability that means of two series of measurements differ. (The key function is the incomplete beta; it is also the most difficult to write well). Fortunately I have persuaded Stephen Moshier, author of the Cephes function library (in C) to make this available under Boost licence terms. So implementors will have no excuse to hide behind (the reason why these functions were omitted by Walter Brown). It should be possible to produce a working (and I believe rather good) implementation with little more than renaming the functions. This might be submitted for a Boost library. I hope to expose a revised draft to the rigours of Boost and C++.std newsgroup Real Soon Now. Paul Paul A. Bristow Prizet Farmhouse, Kendal UK LA8 8AB +44 1539 561830 07714 33 02 04 pbristow(a)hetp.u-net.com

1 0

Paul Mensonides:
by Vesa Karvonen 12 Jun '04

12 Jun '04

[boost] Re: Some remarks on PP docs Date: Fri, 11 Jun 2004 16:36:19 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Paul Mensonides: >Chaos, as opposed to Order, intentionally encourages better >understanding of the actual language being used (which is not Chaos, but >the preprocessor) rather than trying to hide it as much as possible. I've discussed this with you earlier, but I'd still like to point out that the intention behind the design of Order has not been to "hide as much as possible" or to discourage "better understanding", but rather to *provide* a language that definitely *is* easy to understand and convenient to use. A person unfamiliar with Boost.PP should be able to learn to use something like Order and use it for productive, even non-trivial, work (which is usually C or C++ code generation) in significantly shorter period of time than it takes to learn how to do similar things with Boost.PP (or Chaos). I also noticed other, IMO, misleading comments on Order [vs Chaos], but I don't have the time to comment on those at the moment. -Vesa Karvonen _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Re: Some remarks on PP docs
by Vesa Karvonen 12 Jun '04

12 Jun '04

David Abrahams: >I'm writing an appendix on the PP lib for the MPL book today. I think >that'll demonstrate that it's possible to provide a reasonable gentle >and high-level introduction without exposing too many ugly details. That would be great! >- Fundamental PP Abstractions > - Macros > - Non function > - Function macros > - Tokens > - Sequences of tokens not including un-parenthesized commas Data structures are an important topic and their representation isn't fundamentally PP *library* specific. You might want to present the information on the representation of data structures (and simple macros like a projection operator for tuples and some sequences operations) here when you discuss fundamental PP abstractions. I would also probably discuss how to implement primitives like IF and WHILE using preprocessor macros at this point. The purpose being to show that the preprocessor is capable of significant computation. I would also emphasize that the purpose of explaining the techniques is not that people would roll their own versions, but simply to deepen their understanding of the preprocessor. >Well, if you really have a conforming C99 preprocessor, you could use >Paul M's Chaos, which I think is both easier to use and *way* more >efficient than the current Boost PP. >From what I know, Chaos is essentially an extended Boost.PP (meaning that Chaos is essentially a combinator library), with a single recursion backend (enabled by stricter requirements on preproprecessor conformance), which makes it more orthogonal. However, Chaos still shares many problems with Boost.PP, the main issues being that code will be highly verbose and very intricate. The verbosity and intricacy probably do not matter that much when one only performs simple repetition using the canned library macros. -Vesa Karvonen _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 5