June 2004 - Boost - lists.preview.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

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

Some remarks on PP docs
by David Abrahams 12 Jun '04

12 Jun '04

techniques.html: It is usually okay to use a standard macro name like BOOST_PP_DEF for this kind of code because the macro is both defined and undefined in the immediate site of its use. I was really confused by the use of the word "standard". This would be clearer: It is usually okay to reuse a single generic macro name like BOOST_PP_DEF throughout your code because the macro is both defined and undefined very close to its point of use. Although I don't know why you'd want to advocate that over using a descriptive name. ------ A clearer divider between examples would be a *huge* help visually. An <hr> would be enough, for example. Example - Use BOOST_PP_EMPTY as an unused parameter in local macro instantiations. #define BOOST_PP_DEF(cv) /* ... */ \ template<class base> \ cv() typename implement_subscript_using_begin_subscript<base>::value_type& \ implement_subscript_using_begin_subscript<base>::operator[](index_type i) cv() { \ return base::begin()[i]; \ } \ /**/ ?? Where is BOOST_PP_EMPTY used in this example? I think I know what you mean, but really, you need to show it! How: BOOST_PP_EMPTY() expands to nothing and can be used as an unused parameter. Note: BOOST_PP_EMPTY with the () never gets expanded. This sounds self-contradictory. Just above you said it expands (to nothing)! The () is necessary to invoke a function-like macro. No duh; I think stating the obvious that way only adds confusion. Caveat: You cannot safely use concatenation while using BOOST_PP_EMPTY(). That's way too vague and general. I certainly can use concatenation and BOOST_PP_EMPTY "together", for many reasonable definitions of that word! I think you need to be more specific, or strike it. ------ The BOOST_PP_ENUM_PARAMS example could benefit greatly from a side-by-side format in a table showing the expansion on the right. In fact, that would help all the examples, but in particular if you're just getting acquainted with the library at this point you may not have any idea what some of those macros do. You're advocating that people use them here, but unless the reader has some idea of what they generate, it's lost on her. Showing not-even-correct details of BOOST_PP_REPEAT's implementation doesn't help here. I'd strike it. Furthermore, BOOST_PP_ENUM_PARAMS and its variations use BOOST_PP_REPEAT. BOOST_PP_COMMA_IF(I) expands to a comma if I != 0. BOOST_PP_INC(I) essentially expands to "I+1," and BOOST_PP_DEC(I) essentially expands to "I-1.". I'd strike that too. You haven't said a word about BOOST_PP_INC/DEC yet, so the reader is left wondering why you're giving their implementation details. ----- Example - Use BOOST_PP_REPEAT and a token look-up function to eliminate categorical repetition. Is this really better than iterating over a SEQ of categories in any way other than efficiency? ----- Example - Use BOOST_PP_REPEAT to avoid O(n*n) repetition. It's unclear to me how that example avoids O(n*n) repetition. It certainly seems to have that complexity, and that appears to be intrinsic to the code it generates. Maybe you mean Example - Use BOOST_PP_REPEAT for O(n*n) repetition. Or something? ----- BOOST_PP_IF enables convenient generation of lists using BOOST_PP_REPEAT. This statement, without an example, is too vague to be helpful. ----- Implementation details of BOOST_PP_IF don't help: How: BOOST_PP_IF is defined for the entire repeat range (psuedo code): #define BOOST_PP_IF(c, THEN, ELSE) BOOST_PP_IF ## c(THEN, ELSE) #define BOOST_PP_IF0(THEN, ELSE) ELSE #define BOOST_PP_IF1(THEN, ELSE) THEN #define BOOST_PP_IF1(THEN, ELSE) THEN ^ especially since they appear to be wrong. I think the point is that BOOST_PP_IF works on first arguments other than 0 or 1. If so, you should just say that it works on numeric arguments up to N (whatever N is). --------- Example: Use arithmetic, logical, and comparison operations when necessary. With no commentary, and no generated code, this example is really useless. I mean, of course you'd use arithmetic, logical, and comparison operations "when neccessary". -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 6

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

11 Jun '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > David Abrahams wrote: > >>"Reece Dunn" <msclrhd(a)hotmail.com> writes: > >> > David B. Held wrote: > > It should be fairly easy to adapt the ReST/SpiritDoc/whatever > > translation phase to generate BoostBook instead of HTML. > >Yeah, especially since docutils (ReST) already contains a DocBook >generating backend. It can also be done with XSLT from the ReST XML >generator. But ReST doesn't contain ways to represent many of the >C++-specific logical elements of BoostBook, IIUC. These could always be added in by the author after the BoostBook files have been generated, if you are planning to migrate from ReST/SpiritDocs to BoostBook. This was the idea, to give the user a tool/toolset to help migrate to the BoostBook 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. > >> > >>And it requires writing in XML :-( or translating to it :-|. > > > > XML is essentially a stricter version of HTML. > >I thought the main thing was that it is extensible. It is. You can have any element and attribute structure you want; this is how it is extensible. What I was referring to is that XML emposes stricter formatting rules than HTML, requiring attributes to be quoted and all tags to have corresponding closing tags (the open/close tag being a special case). This might be new to people familiar only with HTML and so may make mistakes, resulting in an invalid XML file. Automating this conversion process will help ensure a valid XML file to work from. > > The main problem I see is porting the existing HTML-based docs to > > BoostBook. The others can be generated using a BoostBook generator > > (not sure how easy it will be for each format). > >There's no advantage to translating into BoostBook, AFAICT, unless >we're going to stick in its special logical elements. We can always >just use a common .css if you just want a similar look. I thought one of the ideas behind BoostBook was to have a documentation format that will eventually become Boost-wide. If this is the case, then having tools like what I'm suggesting will help speed up the migration process. If not, then what you are suggesting is also fine. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Thread lib (good reason for static)
by Peter Danford 11 Jun '04

11 Jun '04

[This is from an email about the impact of not having a static Threads lib available anymore. I wanted to post this here to see if anyone else has similar experiences since I have only seen posts about the problem of distributing RTL dlls so far - not computation time impact.] Hello, I was reading some some of the posts about your thread implementation and the removal of the static RTL option. I understand the technical reason for this, but I wanted to submit another compelling reason (for me) for the need for static RTL linkage even if this means loosing some of the features under win32. Some of the software I develop deals with different types of analysis (such as scientific and financial). The runs can take as much as 20 hours to complete. If I do nothing but change to link with dynamic RTL, the run time is increased on average of 35%. This means and additional 7 hours of run time! So dynamic RTL is really undesirable. Do you see any way of making a more limited static Boost.threads available in the next Boost release? [Above I say "limited" because some of the features of the Thread lib must be implemented via dll to work under win32.] Peter --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger

10 46

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

11 Jun '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > David B. Held wrote: > >>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. > >And others; we used ReST for the iterator library. It should be fairly easy to adapt the ReST/SpiritDoc/whatever translation phase to generate BoostBook instead of HTML. > > 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. > >And it requires writing in XML :-( or translating to it :-|. XML is essentially a stricter version of HTML. The main problem I see is porting the existing HTML-based docs to BoostBook. The others can be generated using a BoostBook generator (not sure how easy it will be for each format). I have a Spirit-based HTML parser that does basic correction (not as good as HTMLTidy) that is event based (like SAX for XML) and can be used to generate XHTML. It should be possible to adapt this to generate a BoostBook document that can be used as the basis for migrated docs. The SpiritDoc processor tool is freely available and should be easy to migrate to BoostBook output. Other generators can be produced for ReST, etc. NOTE: The output of these should be seen as a basis for the actual docs as they won't be able to properly detect things like the licence info, author name or library name/category; these will need to be edited by the document provider. (It all depends on how this information is encoded in the base text. If there is a markup pattern, then it should be possible to identify this and extract the information.) Let me know if I should take a look into seeing how feasible this is. Having a common document format will help maintain a consistent navigation/look. Also, it should be possible to generate frames as an alternate look by editing the BoostBook stylesheets and with a little wizardry it should be possible ot turn this on or off, depending on your preferences like it is currently possible to select Spirit or DocBook navigation styles. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

feature request: file lock
by Jordi Vilar 11 Jun '04

11 Jun '04

Hi, I propose the inclussion of the following set of private members to the boost::filesystem::fstream class: private: void do_lock(); bool do_trylock(); bool do_timedlock(const xtime& xt); void do_unlock(); void do_lock(cv_state& state); void do_unlock(cv_state& state); this will enable additional classes: namespace boost { namespace filesystem { class scooped_lock; class scooped_try_lock; class scoped_timed_lock; } } with an interface like boost::thread::scooped_lock and sccoped_try_lock. What do you think about this? If you want to proceed and need help, please let me know, I can provide an implementation for Windows (NT and above) and posix (I'm currently working on this functionality). Cordially, Jordi Vilar

1 0

program_options and optional
by Neal D. Becker 11 Jun '04

11 Jun '04

Seems natural to use boost::optional with program_options. Has anyone tried this? For example, consider this: int main (int argc, char** argv) { namespace po = boost::program_options; optional<double> x; po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("x", po::value<double>()->notifier (var(x)=_1)) ; To set the optional<double> x, this uses boost::lambda. Is there a more direct approach?

2 1

Re:[boost] [serialization18] conflict definition of "is_abstract" with type traits library(in cvs)
by Robert Ramey 11 Jun '04

11 Jun '04

Allen Yao wrote: > The file is_abstract.hpp in serialization18 and is_abstract.hpp in type > traits library (in cvs) have conflict definitions of "boost::is_abstract". > May Ramey fix this. For now, I just comment out the latter in order to use > serialization18. I am aware of this. serialization #18 is meant to be compatible with boost 1.31. >In addition, I am confused with the ".ipp" files in libs/serialization/src/ >in serialization18. It is strange to write >#include <libs/serialization/src/basic_binary_oprimitive.ipp> // for serialization18 >in user code instead of >#include <boost/serialization/basic_binary_oprimitive.ipp> // for serialization17 >I wonder why these files can not be just named ".hpp" It is my practice to distinguish between header files containing declarations to be included by "users" of the library (*.hpp) from function implementations (*.cpp) and template implementations (*.ipp). I moved the *.ipp files to the src directory because they seemed no need for library users to ever include them when building with the library. Since then it has occurred to me that they may be included when one makes a new archive when deriving from an existing one. Accordingly, these *.ipp files will be moved to boost/archive/impl in the next version. This system is helpful to me - I don't know what other peoples views are on this. > when will we see the serialization library in boost cvs, please? I have made changes to address all issues raised in the recent review. I'm now making changes to permit builds on all the compilers I have. I hope to upload a version compatible with 1.31 "real soon now". I will then build against my cvs tree. Then I will request authorization to check in. It will take a little time. Robert Ramey

1 0

MSVC 7.1 and BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Maxim Yegorushkin 11 Jun '04

11 Jun '04

I think the following condition in visualc.hpp is incorrect #if _MSC_VER <= 1310 # define BOOST_NO_MEMBER_TEMPLATE_FRIENDS #endif I've checked that MSVC 7.1 supports memeber template syntax. And, AFAIR, MSVC 7.0 supports it too, but I haven't got it to check. Should the condition for BOOST_NO_MEMBER_TEMPLATE_FRIENDS macro here and in other places in visualc.hpp be changed to #if _MSC_VER < 1300? Or am I missing something? -- Maxim Yegorushkin

2 1