- Boost - lists.boost.org

call_once on win32
by Anthony Williams 20 Sep '05

20 Sep '05

I just committed a new version to CVS; pretty much the last version I posted with void return, but incorporating John Maddock's changes for generating the name so as to not require std::stringstream, or even strstream. This version is header only, in contrast to the older version (and current versions for other platforms), which required a C++ file. This allows the call_once function to be a template. Note, that windows.h *is not included* --- explicit prototypes are included for the required functions, following the lead of boost/detail/interlocked.hpp (which has been updated to include InterlockedExchange). Despite tendering a version that handles non-void returns, I am not sure how to do it right (destruction order for statics makes it hard), so I have left that out for now. Anthony -- Anthony Williams Software Developer

6 23

[threads] rework notes
by Matt Hurd 20 Sep '05

20 Sep '05

This should probably belong on the wiki, but I can't edit in the wiki (access denied). I've put up a rationale for the thread restructure with basic information as well here http://www.zomojo.com/thread/boost_thread_rework.xhtml Should have some code / structure in place for discussion soon. First thing to agree on is the basic directory structure and header linkage philosophy. Moving house over the next couple of days so contact will be a little sparodic. Note, I'm in Sydney so I work in a different time zone to most. matt matt(a)zomojo.com

11 15

TR1 review manager needed
by John Maddock 20 Sep '05

20 Sep '05

Before I forget (for the 20th time already!), the upcoming review of my TR1 library submission is in need of someone to act as review manager, the review is scheduled to start on September 20th, and details are as follows: Description: ~~~~~~~~ The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Functionality supported includes: Reference Wrappers Smart Pointers Class template result_of. Function template mem_fn. Function Object Binders. Polymorphic function wrappers. Type Traits. Random Number Generators and Distributions. Tuples. Tuple Interface to std::pair. Fixed Size Array. Hash Function Objects. Regular Expressions. Complex Number Algorithm Overloads. Complex Number Additional Algorithms. Functionality in TR1 but not yet available in this implementation (because they're not in Boost): Mathematical Special Functions. Unordered Associative Set (Hash Table). Unordered Associative Map (Hash Table). C99 C language additions. This library also makes changes to Boost.Config, and adds some new functionality to Boost.Math, reviewers should start with the readme.html in the root directory of the zip file. ~~~~~~~~~~~~~ Available at: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… or at: http://boost-consulting.com/vault/index.php?action=downloadfile&filename=tr… Regards, John.

6 10

[throw_exception] BOOST_NO_EXCEPTIONS and <exception>
by JOAQUIN LOPEZ MU?Z 20 Sep '05

20 Sep '05

boost/throw_exception.hpp includes <exception> when the macro BOOST_NO_EXCEPTIONS is defined. Isn't it likely that an exception-disabled platform won't provide <exception> either? Is there any rationale/compiler survey for this? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[serialization] Doc problems
by David Abrahams 20 Sep '05

20 Sep '05

Hi Robert and Jonathan, In preparing some slides for a course I'm giving, I've been reading through the serialization documentation. Although it's generally well organized and presented, there are a few problems: 1. The menu control doesn't seem to keep the browser's displayed URL in synch with the location being browsed (FireFox on Windows XP). Wasn't that a major coup of Jonathan's menu control? 2. Deserialization of derived classes through base class pointers is an incredibly important subject -- even for many first-time users -- but the instructions for handling it are buried deep in Reference > Serializable Concept > Pointers > Pointers to Objects of Derived Classes (http://www.boost.org/libs/serialization/doc/serialization.html#derivedpoint…) This material _needs_ to be in the tutorial! In fact, the material in the reference section is narrative and tutorial in nature, which seems inappropriate for a reference manual. Maybe you should just move it? 3. In that reference section, '&' is used repeatedly where only '>>' is appropriate. For example: main(){ ... base *b; ar & b; } That can only be confusing. 4. The documentation says that you can write your freestanding serialize() function in namespace boost::serialization, with the strong implication that it will work even on compilers that support ADL. But it won't work unless boost::serialization is an associated namespace of one of the arguments, as demonstrated by the following program: namespace me { class X {}; } namespace boost { namespace serialization { template <class T> int call_serialize(T const& x) { serialize(x); return 0; } void serialize(me::X); }} int y = boost::serialization::call_serialize(me::X()); As far as I can tell, there's no requirement that any of the arguments to serialize have boost::serialization as an associated namespace. 5. Archive Concept Requirements are specified in a completely new, unprecedented way. I can see why you want to write them this way, but the result is that it isn't completely clear which elements of the interface are required and which are optional. For example, there's a colon after the class name. Does the class need to be derived from something? What about the names of function and member template parameters? I know the answer to that one, but a novice might not. What about the default arguments to member functions? Is it okay to write overloads? Also, there's an extra pair of namespace closers in the second archive concept example. 6. In http://www.boost.org/libs/serialization/doc/archive_reference.html#implemen… it says: All input archives should be derived from the following template: template<class Archive> detail::common_iarchive; but that's nowhere to be found in the archive concept requirements. Which is it? Also, that "detail::" is actually nested in the boost::archive namespace, which is not at all clear from the text there. It's not clear to me why archives should live in a namespace other than serialization; if they were in boost::serialization *and* users were required to derive from one of the archive types, that would solve problem 4. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 56

Re: [boost] Scons users?
by Martin Bonner 20 Sep '05

20 Sep '05

----Original Message---- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: 20 September 2005 12:59 To: boost(a)lists.boost.org Cc: jamboost(a)yahoogroups.com; boost-users(a)lists.boost.org Subject: Re: [boost] Scons users? > Kevin Wheatley <hxpro(a)cinesite.co.uk> writes: > >> David Abrahams wrote: >>> On the Boost.Build list we were just discussing the fact that some >>> people otherwise inclined towards Boost have chosen Scons over >>> Boost.Build. It would be useful for us to understand some of the >>> reasons why, if some of you wouldn't mind letting us know. No >>> flames, please! >> >> not a flame, but some test results (Noel Llopis' Blog) shows a few >> interesting results: >> >> http://tinyurl.com/7fdns (www.gamesfromwithin.com) >> >> These are updated from previously. > > Wow, harsh. The numbers aside, I think his commentary is rather > flame-ish. Well, without the numbers, I agree. But the numbers do rather back him up (except that BoostBuild does seem to be marginally quicker than Scons on three out of four tests, whereas he describes it as "Slower even than Scons!"). Are there any known optimization oportunities in BoostBuild? Are the results an artifact of his test set up? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[mpl] Updated math sublibrary.
by Cromwell Enage 20 Sep '05

20 Sep '05

A summary of recent changes: * All math-related functionality has been moved to the boost::mpl::math namespace. * exponent<> is now exponential<>. * numeric_caster_rt<> is now runtime_value<>. For those of you who downloaded the previous version yesterday, I've made more changes since then: * monomial<> is now integral_power<>. * A few bugs in the trigonometric functions were fixed. * The euler, exponential, and square_root example programs now showcase Peder Holt's metadouble. Still to come: * Documentation! * natural_logarithm<>, followed by power<>. * An efficient big_integral<> (someday). Cromwell D. Enage ______________________________________________________ Yahoo! for Good Donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

1 0

Re: [boost] [Review] xpressive
by Eric Niebler 19 Sep '05

19 Sep '05

Daryle Walker wrote: > On 9/15/05 1:10 PM, "Eric Niebler" <eric_at_[hidden]> wrote: > >> In practice, the only reason why you might iterator over > >> all sub-matches is to print them out. Otherwise, the sub-matches are > > accessed > >> randomly, because (for example) the 1st sub-match is a date and the 3rd >> sub-match is an email address, and I'm not interested in the 2nd. See? > > <snip> > > It looks like the current setup is not STL-friendly. Most of the "what" > list is one type of thing, the in-order pieces of the regex parse. The > first item of the list doesn't match that pattern (since it's the whole > parse). I'm guessing that this "old" way wasn't a problem because people > expected 1-based arrays, so the 0-index could be special. That doesn't > work > in a 0-based array culture, like C++ (or C). C++ people would expect the > 0-index element to match the general rule of the list. This mixing of > element types mixes concerns (violating "keep it simple, silly"). A > STL-friendly alternative would to have separate member functions for the > whole-parse and the list-of-parse-pieces, then have a special function > (member or non-member) that generates a regex-culture combined list. > I agree, if we we're only concerned about satisfying people familiar with C++ culture. But we are also trying to satisfy people familiar with regex culture. Every regex package out there I know of that supports back-references begins numbering captures at 1. I don't know why. But I do know that to break with that tradition now would cause massive confusion. Besides, I'm trying to minimize the differences between xpressive's interface and TR1 regex. Is it a wart? OK, I agree. But frankly, I don't feel that this is an ugly enough wart for me to break with established practice. -- Eric Niebler Boost Consulting www.boost-consulting.com

6 8

Re: [boost] BOOST_ASSERT and __assume on MSVC
by brangdon＠cix.compulink.co.uk 19 Sep '05

19 Sep '05

In-Reply-To: <dg7jf6$uf6$1(a)sea.gmane.org> kalita(a)poczta.onet.pl (Marcin Kalicinski) wrote (abridged): > Have you considered modifying BOOST_ASSERT to use __assume on MSVC? It looks to me as though this risks changing the semantics of BOOST_ASSERT in a way which might break existing code. As I read the documentation, currently code like: if (!p) { BOOST_ASSERT( false ); return; } is supported and meaningful. If BOOST_DISABLE_ASSERTS is true, the macro does nothing and the return statement is executed when p is 0. If we change the macro to instead expand to __assume, then the compiler will probably omit both return and the check against zero. The documented behaviour of the code will change. Although I sympathise with the view that a failed assert should be considered undefined behaviour, I personally find the current documented behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds." If we use __assume, we need to clearly distinguish between the old and the new behaviours, at the point of assert. Specifically, I suggest we add a new macro, eg named BOOST_ASSUME(x), which expands to BOOST_ASSERT(x) by default and to __assume(x) when BOOST_DISABLE_ASSERTS is true. This latter case would be documented as causing undefined behaviour if x is false. Programmers can than change their code from BOOST_ASSERT to BOOST_ASSUME at their leisure. If they believe in defensive programming, they may leave some code as BOOST_ASSERT. > Microsoft docs for __assume are here: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng > /htm/msmod_36.asp -- Dave Harris, Nottingham, UK.

4 5

Re: [boost] Beyond the C++ Standard Library: An Introduction to B oost
by Bjorn.Karlsson＠readsoft.com 19 Sep '05

19 Sep '05

Hello Beman, > From: Beman Dawes [mailto:bdawes@acm.org] > > What kind of animal is that on the cover? Some kind of Lemur? Yes, they are lemurs. In case some of you are wondering what lemurs and Boost have in common, I must confess that I have absolutely no idea. My editor, Peter Gordon, came up with the unbelievably far-fetched connection that "Boost is giving a lift to the C++ Standard Library". I think that he, just as you and I did, simply thought that they were just about the cutest things you ever saw. (When deciding which cover picture to go with, I also consulted my six-year-old son, who made it quite clear that the other options were, ahem, less perfect than the one with the lemurs.) > It is about the cutest thing I've seen in a long time. (Don't > tell my office cat I said that.) My lips are sealed. Björn

2 1