August 2005 - Boost - lists.preview.boost.org

Boost on FreeBSD [patch]
by Simon Barner 06 Aug '05

06 Aug '05

Dear Boost developers, I am currently testing a CVS snapshot of the upcoming boost 1.33.0 release (from 07/31), and I found the attached patch is needed. This is because the T_DIVIDE macro is already declared in the FreeBSD header file /usr/include/machine/trap.h, which is pulled via various other header files. Kind regards, Simon (maintainer of the FreeBSD boost port) P.S.: I'll try RC1 as soon as possible. P.P.S.: Please Cc: me in your replys, I'm not on the list. Thanks.

5 5

about icpc error
by Bo Liu 06 Aug '05

06 Aug '05

Hello Martin, Can you tell me how you got the following more-than-one-instance error resolved? /boost/head-regression/boost/boost/iostreams/copy.hpp(182): error: more than one instance of overloaded function "resolve" matches the argument list: function template "boost::iostreams::detail::resolve<Mode,Ch,Iter>(const boost::iterator_range<Iter> &)" function template "boost::iostreams::detail::resolve<Mode,Ch,T>(const T &, boost::disable_if<boost::iostreams::is_std_io<T>, void>::type *)" argument types are: (const boost::iterator_range<const char *>) return copy_impl(resolve<input, char_type>(src), wrap(snk), buffer_size); command: icpc -c -w1 -g -O0 -I"../bin/boost/libs/iostreams/test" -I"/boost/head-regression/boost" -o "../bin/boost/libs/iostreams/test/newline_filter_test.test/intel-8.1-linux/debug/newline_filter_test.o" "/boost/head-regression/boost/libs/iostreams/test/newline_filter_test.cpp" I got the googled link, http://64.233.187.104/search?q=cache:uEsi-MT1fegJ:www.jobmanager.com/engine…, when I ran into the similar problem. It seems that you have resolved problem since that page was removed. Thanks, -Bo __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Who's Using Boost?
by David Abrahams 06 Aug '05

06 Aug '05

I have two concerns about these pages: 1. They violate the library naming/branding conventions (http://www.boost.org/more/discussion_policy.htm#lib_names) 2. How shall we get http://www.boost.org/libs/python/projects.html integrated into it? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

CSS expert advice needed
by David Abrahams 06 Aug '05

06 Aug '05

It has frustrated me that footnotes are rendered in such extremely small type in the Parameter library documentation (http://www.boost-consulting.com/libs/parameter) but I can't tell what needs to change in the CSS to fix it. Can anyone help? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 16

Name polution with boost::type_traits
by Ivan Godard 06 Aug '05

06 Aug '05

May I suggest that the type_traits identifiers all be placed in a boost::type_traits namespace, with one indirect #include file to grandfather existing usage? The added file, say hide_type_traits.hpp, would include all the detail .hpp files the way that type_traits.hpp does now. The individual detail files would wrap each API declaration in "namespace type_traits{...}". The present type_traits.hpp would simply: #include "hide_type_traits.hpp" namespace boost { using namespace type_traits; } The effect is that current usage will still work if you include type_traits.hpp as at present, but those of us who want the type_traits names (bit not the rest of boost) in the file namespace can do a "using boost::type_traits;" to achieve that. What prompts this note is a desire to prepare for TR1 while continuing to support old compilers. We attempted to say (in a file included when using an older compiler): namespace std { #include "boost/type_traits.hpp" } so that the boost type_traits identifiers would appear in the std namespace under an old compiler just as they would in a compiler that implements TR1. However, this blows up because the boost type_traits library transitively includes other boost stuff it uses, and that stuff does *not* like to be in std :-) Of course, we could leave all the identifiers in the boost space and pick them out one by one with using statements; that's in fact what we are doing. But that means we have to track your library with our using's, a maintenance nuisance. Lastly, may I suggest that future libraries with lots of identifiers should routinely use a per-module namespace, like the mpl library does now? That would obviate this nuisance should the library later be standardized. Ivan

2 1

Boost regression notification (2005-08-05)
by Douglas Gregor 05 Aug '05

05 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-05T15:10:44Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 34 failures in 3 libraries: iostreams (1) serialization (32) thread (1) |iostreams| mapped_file_test: intel-win32-9_0 |serialization| test_list_binary_archive: cw-9_4 cw-9_5-darwin test_list_binary_archive_dll: cw-9_4 cw-9_5-darwin test_list_ptrs_binary_archive: cw-9_4 cw-9_5-darwin test_list_ptrs_binary_archive_dll: cw-9_4 cw-9_5-darwin test_list_ptrs_text_archive: cw-9_4 cw-9_5-darwin test_list_ptrs_text_archive_dll: cw-9_4 test_list_ptrs_text_warchive: cw-9_4 cw-9_5-darwin test_list_ptrs_text_warchive_dll: cw-9_4 test_list_ptrs_xml_archive: cw-9_4 cw-9_5-darwin test_list_ptrs_xml_archive_dll: cw-9_4 test_list_ptrs_xml_warchive: cw-9_4 cw-9_5-darwin test_list_ptrs_xml_warchive_dll: cw-9_4 test_list_text_archive: cw-9_4 cw-9_5-darwin test_list_text_archive_dll: cw-9_4 test_list_text_warchive: cw-9_4 cw-9_5-darwin test_list_text_warchive_dll: cw-9_4 test_list_xml_archive: cw-9_4 cw-9_5-darwin test_list_xml_archive_dll: cw-9_4 test_list_xml_warchive: cw-9_4 cw-9_5-darwin test_list_xml_warchive_dll: cw-9_4 |thread| test_thread: vc-6_5

3 2

[1.33.0] [Serialization] Important: cw-9_4 failures
by Douglas Gregor 05 Aug '05

05 Aug '05

Lots of Serialization tests are failing: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/ developer/issues.html We need to resolve these before we can release RC2. Doug

3 2

[Type Traits, BoostBook] Lots of BoostBook parsing errors
by David Abrahams 05 Aug '05

05 Aug '05

xslt-xsltproc ../bin.v2/doc/gcc-3.4.4/debug/boost.docbook file:///boost/tools/boostbook/dtd//boostbook.dtd:412: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" %DocBook; ^ Entity: line 1: %DocBook; ^ src/boost.xml:345: parser error : Entity 'eacute' not defined <firstname>Hervé</firstname> ^ src/boost.xml:346: parser error : Entity 'ouml' not defined <surname>Brönnimann</surname> ^ src/boost.xml:701: parser error : Entity 'auml' not defined <surname>Järvi</surname> ^ ... ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:123: parser error : Entity 'nbsp' not defined struct</phrase> <link linkend="boost_typetraits.is_void">is_void</link><phr ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:123: parser error : Entity 'nbsp' not defined ><phrase role="special"> :</phrase><phrase role="keyword"> public</phrase>  ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:126: parser error : Entity 'nbsp' not defined struct</phrase> <link linkend="boost_typetraits.is_void">is_void</link><phr ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:126: parser error : Entity 'nbsp' not defined ><phrase role="special"> :</phrase><phrase role="keyword"> public</phrase>  ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:142: parser error : Entity 'nbsp' not defined struct</phrase> <link linkend="boost_typetraits.is_pointer">is_pointer</lin ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:142: parser error : Entity 'nbsp' not defined ><phrase role="special"> :</phrase><phrase role="keyword"> public</phrase>  ^ .... -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[parameter] some typos in tutorial...
by Pavel Chikulaev 05 Aug '05

05 Aug '05

Hi David, There is a strange symbols in /libs/parameter/doc/html/index.html in section 2.6.2 after second function code with modifier <span class="doublesize">. Absolutely the same in 2.7.2 and 2.7.3... In section 2.8.3 "Mnemonics" note can overlap code in that section when page less than 800 pixels wide. It's better to use tables IMO there. -- Pavel Chikulaev

7 14

[Range] No Reply?
by David Abrahams 05 Aug '05

05 Aug '05

Thorsten Ottosen <nesotto(a)cs.aau.dk> writes: > Citat David Abrahams <dave(a)boost-consulting.com>: > > Hi Dave, > >> >> Thorsten, >> >> there are important issues here that go to the suitability of this >> library for generic programming. I notice there was no answer on the >> list. It's crucial that you deal with these questions eventually, and >> IMO it should happen before the 1.33.0 release. >> > > I'll see what I can do. My laptop was stolen two weeks ago, so > its hard for me to do any real work. Ouch! I'm sorry to hear that! > When is 1.33.0 going to be? I think we're hoping to do a prerelease candidate this weekend or Monday. > Anyway, here's the issues: I'm not sure that you quite "got" most of the concerns I raised. > 1. change XXX to boost::XXX. ok, I don't see any problem with this. I > could fix it monday. -------------- If you already understood everything I'm writing in this section delimited by dashes, please just tell me so and I'll relax. I'm not asking for you to simply change XXX to boost::XXX everywhere. To quote from my original posting: > | 1. What does it take to get support for standard containers as ranges? > | According to what I can see in the documentation, the standard > | containers don't satisfy the range concepts. IOW, > | > | begin(v) > | > | isn't valid when v is a standard vector. > | > | From what I can tell from browsing the implementation, the > | requirement should be: > | > | boost::begin(v) The problem is that the Range concept requirements, as you specified them, are not satisfied by standard containers. Therefore the standard containers are not Ranges. Since it is a goal of the library that the standard containers be Ranges, you need to fix the way you've specified the concept requirements. And as I said later in the post: > One should be able to look at a concept definition and understand > which types will model that concept. That concept > definition may of course lead you to look at the implementation of > other functions, but it has to let you get ahold of one end of the > string, so you can follow it to its logical conclusion. That's why > the concept definition should say that boost::begin(s) is a > requirement... and of course it should link(**) to the documentation for > boost::begin so the reader can find out what it takes to make that > function work, and deduce that it works for standard containers. -------------- I also said: > | and the default behavior of boost::begin needs to be documented. > > it's documented in another document. I provided linke to in in the > CVS version some time ago after you requrested it. And then I asked that you post a link (both to the page with the boost::begin documentation and to the page in the main docs that links to it), but I have yet to see a reply. > 2. swappable range: > > The page says: "Since ranges are characterized by a specific underlying iterator > type, we get a type of range for each type of iterator." > > that's the definition. Sorry, but that's not a definition of anything. > Is it so hard to grasp? It is easy to infer what you mean, if you're very familiar with the new iterator concepts. It's also very easy to misinterpret if you're not, because swappable iterator is a counterintuitive name. More importantly, as I suggested, there is no need to name these concepts (because you can just say "Requires: iterator<R>::type is a model of RandomAccessTraversalIterator," or whatever), especially not before they have been shown to be useful in specifying algorithms. There's no need to build a parallel and redundant concept hierachy. In fact, it's probably harmful to do so. > 3. Implementation of concepts. > > A type conforms to a concept, so ok, you can't implement it. Maybe a renaming > to "Implementations of types that concorm to Range concepts". ? I don't know what the right title is first try to answer the question I asked: You need to rename this page. What is it really describing? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 4. links from concepts to implementation. I'm not sure what you're referring to. > I remember I put some links when you asked for it. It should be > in the cvs code. In the code? I remember asking you to post some links. Or maybe you mean you fulfilled the request in (**) to put links in the documentation? Can you tell me where, on the boost-consulting CVS mirror, I can find that? > Do you want more links? I can't know until I can see what you've already done. > 5. containers and iterators. It should be explained in the introduction > that pairs and containers "just works". That is insufficient. The concept requirements have to be correct. And by the way, if you mean "This library therefore provides the means to adapt standard-like containers, null terminated strings, std::pairs of iterators, and raw arrays (and more), such that the same generic code can work with them all." then no, it doesn't make it clear that they "just work." It claims that the library gives me the *means* to make them "just work." So I'm left asking, "how do I do that?" Also, IIUC, this and other mentions of null terminated strings need to be removed now. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 9

[1.33.0 RC1] libs/type_traits/docs/html needs boostbook.css
by Larry Evans 05 Aug '05

05 Aug '05

The html tables created by the Jamfile.v2 and type_traits.qbk in parent directory have no delimiters between columns and rows without a boostbook.css in the html directory. A copy of the boostbook.css from: libs/python/doc/tutorial/doc/html seems to work.

2 5

Fw: shared_array EXC_BAD_ACCESS
by Peter Dimov 05 Aug '05

05 Aug '05

I'm forwarding the following post from boost-users http://lists.boost.org/boost-users/2005/08/12938.php since it describes a pretty severe configuration problem on Mac OS X that apparently leads to inconsistent definitions of BOOST_HAS_THREADS and all kinds of interesting ODR violations. Christopher Hunt wrote: > OK, this is now completely solved. :-) > > Interestingly, boost/detail/lightweight_mutex.hpp was being included > in one place and declaring lightweight_mutex from > boost/detail/lwm_nop.hpp. However the implementation from > boost/detail/lwm_pthreads.hpp was actually being used. > > To cut a long story short, declaring a prefix file that forced boost > to configure itself prior to importing Cocoa and Carbon dependencies > completely solved the problem. Here's what my Cocoa pch file looks > like: > > // > // Prefix header for all source files > // > > #ifdef __cplusplus > #include <boost/config.hpp> > // Gets brought in early so that any > Carbon presence doesn't influence > // its configuration. > #endif > > #ifdef __OBJC__ > #import <Cocoa/Cocoa.h> > #endif > > If you're doing just Carbon, then do your #include <Carbon/Carbon.h> > after boost/config.hpp is included (in place of the #ifdef __OBJC__ > block). > > The real gremlin here is this bit of code in > boost/config/platform/macos.hpp: > > # ifndef TARGET_CARBON > # include <boost/config/posix_features.hpp> > # endif > > There is a posting that discusses the rationale of the above: > http://lists.boost.org/boost-users/2004/10/8110.php and also makes the > observation that there's probably a better way to check for MSL. > > My recommendation is to check for the definition of __MSL__. Thus the > above code becomes: > > # ifndef __MSL__ > # include <boost/config/posix_features.hpp> > # endif > > IMHO the existing MSL check is a bug (checking TARGET_CARBON is too > broad) and will be a trap for all Cocoa/Carbon programmers wanting to > use boost. I would also think that the reality now is that most people > use xcode/gcc and not CodeWarrior/MSL (this is from someone who used > to use CW and MSL all the time). Thus, the motivation for addressing > the issue should now be high. > > What needs to be done to fix the problem? I'm willing to help to save > some other poor soul from spending a day or two stuffing around. > > Cheers, > -C

2 2

[Boost-bugs] [ boost-Support Requests-1252231 ] pointer refresh?? ?!?!??!?!?!
by SourceForge.net 04 Aug '05

04 Aug '05

Support Requests item #1252231, was opened at 2005-08-04 14:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1252231&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: pointer refresh?? ?!?!??!?!?! Initial Comment: i used boost-shared_ptr in a system tray app, and i think i'm loosing some data because of it. If the app stays minimized in sys tray for let's say an hour, things don't go very well. i'm not having any errors, but i ask u if that is possible ? it;s like they need some refresh or something..don't know what ... this is critical..help-help.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1252231&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[1.33.0] Release candidate #1 is available
by Doug Gregor 04 Aug '05

04 Aug '05

Boost 1.33.0 release candidate #1 is now available here: http://www.osl.iu.edu/~dgregor/boost-1.33.0/ There are two sets of files important for this release: - boost_1_33_0_rc1.*: The actual release candidate - boost_1_33_0_(docbook|fo|man).*: The documentation in other formats Please download and unpack the archives, browse the documentation, try the release with your favorite compiler, etc. Thanks! Doug Gregor 1.33.0 Release Manager

12 18

[network] Boost.Network proposal v0.3
by Pedro Lamarão 04 Aug '05

04 Aug '05

Fellow Boosters, this is an update on my proposal for (the beggining of?) a Boost.Network library, located in the Sandbox. I consider it feature complete for a 1.0 milestone; the features being: *) IOStreams classes, fully buffered *) A listener class *) A wrapper for the name resolution service *) A type to store addresses The missing pieces being: *) Complete the copy constructores and assignment operators of the generic_address class. *) Implement optimized xsputn() and xsgetn() in the stream buffer. *) Implement setbuf() in the stream buffer. *) Documentation (never enough) The above list is what I intend to polish up for a formal proposal. This is the TODO list for a next version: *) Address types specific for IPv4 and IPv6, with input operators. *) A formatter output operator for generic address types based on the name resolution service. *) Resolver options and manipulators for the above output operator. *) Code conversion in the stream buffer. *) A poller class. *) Wrapper for sendfile/TransmitFile. *) Implement showmanyc() and perhaps putbackfail() in the stream buffer. With a proper poller class I believe most people's desires for non-blocking operation would be satisfied. I'm going out of town on vacations for some days, so things are going to stall for a while. I hope to complete all tasks soon after Boost 1.33 is released and a new review cycle starts. -- Pedro Lamarão

6 8

[1.33.0 RC1] Possible regression in serialization
by Eelis van der Weegen 04 Aug '05

04 Aug '05

Here's another one-liner that fails to compile (with gcc 3.3.5): #include <boost/serialization/nvp.hpp> I get the following error: In file included from .../boost_1_33_0/boost/serialization/nvp.hpp:33, from t.cpp:1: .../boost_1_33_0/boost/serialization/tracking.hpp:50: error: syntax error before `>' token Again, this worked with Boost 1.32 :) Regards, Eelis

3 2

Boost regression notification (2005-08-04)
by Douglas Gregor 04 Aug '05

04 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-04T14:58:10Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 1 failure in 1 library: thread (1) |thread| test_thread: borland-5_6_4

1 0

Minor documentation issues
by Ariel Badichi 04 Aug '05

04 Aug '05

Hi, The issues are present in release candidate #1. * The full library names in the main page are inconsistent; sometimes "library" is appended to the library name, and sometimes not. Some of these should probably have capital-cased "library" appended - like most of the other libraries. (There seem to be a few exceptions, e.g., Wave and functional/hash, which aren't (just) libraries.) * The "conversion" library entry in the "Libraries Listed Alphabetically" section in libs/libraries.htm is missing a few characters. * Some header filenames in libs/ptr_container/doc/headers.html are incorrect - they miss the .hpp extension.

4 5

Re: [boost] weak_ptr, maybe empty -- doc bug?
by Andy Thomas-Cramer 04 Aug '05

04 Aug '05

Is this a documentation bug? template<class Y> explicit shared_ptr(weak_ptr<Y> const & r); Effects: If r is empty, constructs an empty shared_ptr ... It seems to be throwing an exception, rather than returning an empty shared_ptr. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joe Gottman > Sent: Wednesday, August 03, 2005 7:16 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] weak_ptr, maybe empty > > > "Andy Thomas-Cramer" <Andy_Thomas-Cramer(a)avid.com> wrote in message > news:2F6133743473D04B8685415F8243F4765347D5@madison- > msg1.global.avidww.com... > > > > I have a weak_ptr that might be empty. If not empty, I'd like to make a > > smart pointer from it. > > > > But the code below throws in the shared_ptr constructor, and I don't see > > how to test whether a weak_ptr is empty. > > > > boost::weak_ptr<int> wp; > > boost::shared_ptr<int> sp(wp); > > if ( sp.get() ) { > > ... > > } > > > > Suggestions? > > > > It depends what you mean by empty. A weak_ptr can either > a) be associated with a valid shared_ptr > b) be associated with a shared_ptr that has since expired > or c) be default initialized and never associated with a shared_ptr > > If you don't need to differentiate between case b) and c), the most > elegant > way is > if (shared_ptr<int> sp = wp.lock()) { > //do work with valid shared_ptr > } > > If you need to distinguish between b) and c) you can continue with > } else { > weak_ptr empty; > if (!(wp < empty) && !(empty < wp)) { > //case c, default-constructed weak_ptr > } else { > //case b, expired weak_ptr > } > } > > In practice, most people don't need to distinguish between case b) and c) > > Joe Gottman > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Need help commiting a fix in the CVS Re: [1.33.0 RC1] Possible regression in multi_index
by JOAQUIN LOPEZ MU?Z 04 Aug '05

04 Aug '05

----- Mensaje original ----- De: Eelis van der Weegen <gmane(a)contacts.eelis.net> Fecha: Jueves, Agosto 4, 2005 9:00 am Asunto: [boost] [1.33.0 RC1] Possible regression in multi_index > I'm having trouble compiling a source file consisting of the > following single line: > > #include <boost/multi_index/ordered_index.hpp> > > Using gcc 3.3.5, I get the following error: [...] > error: no > class template named `archive_exception' in `boost::archive' > Hi Eelis, thank you very much for the report. This is indeed a bug in ordered_index.hpp, I forgot to add an include defining archive_exceptions. As it happens, I've got a local test that checks that every header in Boost.MultiIndex correctly compiles when included in isolation, but the compiler I'm using does not implement 2-phase lookup and didn't catch this one... Are fixes still allowed to go to RC2? If so, I'd appreciate if someone could check the attached boost/multi_index/ordered_index.hpp replacement. It merely adds an additional include to solve Eelis' report, and I've locally checked it doesn't break anything. I cannot commit it myself, since I don't have CVS write access these days. I'm also sorry I can't send the fix as a diff file, but I don't have any diffing tool here --the change boils down to a new line at position 65. Thank you for your help, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[1.33.0] 31 remaining broken links
by Jonathan Turkanis 04 Aug '05

04 Aug '05

Hi, There are still a few broken links. The affected areas of Boost are: - who's using boost (FEAR) - numeric/interval - numeric/ublas - serialization - spirit - test - people/darin adler - build v1 Jonathan begin 666 NewReport.txt M1DE,13H@(" @($,Z7$1O8W5M96YT<R!A;F0@4V5T=&EN9W-<='5R:V%N:7-< M2&]M95QB;V]S=%\Q7S,S7S!<9&]C7&AT;6Q<=VAO7W-?=7-I;F=?8F]O<W1? M7&]P96XN:'1M; T*#0H@("!A(&AR968]:'1T<#HO+V9E87(N<V]U<F-E9F]R M9V4N;F5T+R ]/3T^(%1H92!S97)V97(@<F5S<&]N<V4@8V]U;&0@;F]T(&)E M('!A<G-E9"X-"@T*1DE,13H@(" @($,Z7$1O8W5M96YT<R!A;F0@4V5T=&EN M9W-<='5R:V%N:7-<2&]M95QB;V]S=%\Q7S,S7S!<;&EB<UQN=6UE<FEC7&EN M=&5R=F%L7&1O8UQI;G1E<G9A;"YH=&T-"@T*(" @82!H<F5F/2-I;G1E<G9A M;%]P;VQI8VEE<R ]/3T^(&9I;&4@9F]U;F0L(&)U="!I;G1E<FYA;"!L:6YK M(&ES(&%B<V5N= T*(" @82!H<F5F/2-C:&5C:VEN9R ]/3T^(&9I;&4@9F]U M;F0L(&)U="!I;G1E<FYA;"!L:6YK(&ES(&%B<V5N= T*(" @82!H<F5F/6AT M=' Z+R]W=W<N<FAE:6XM;6%I;BYD92]P96]P;&4O:FUA=7)E<B]I;G1E<G9A M;"YT87(N9WH@/3T]/B!%<G)O<CH@<F5S;W5R8V4@;F]T(&9O=6YD#0H-"D9) M3$4Z(" @("!#.EQ$;V-U;65N=',@86YD(%-E='1I;F=S7'1U<FMA;FES7$AO M;65<8F]O<W1?,5\S,U\P7&QI8G-<;G5M97)I8UQU8FQA<UQD;V-<8FQA<RYH M=&T-"@T*(" @82!H<F5F/2-?=&]D;S P,# P,R ]/3T^(&9I;&4@9F]U;F0L M(&)U="!I;G1E<FYA;"!L:6YK(&ES(&%B<V5N= T*(" @82!H<F5F/2-G83@@ M/3T]/B!F:6QE(&9O=6YD+"!B=70@:6YT97)N86P@;&EN:R!I<R!A8G-E;G0- M"B @(&$@:')E9CTC7W1O9&\P,# P,#0@/3T]/B!F:6QE(&9O=6YD+"!B=70@ M:6YT97)N86P@;&EN:R!I<R!A8G-E;G0-"B @(&$@:')E9CTC9V$X(#T]/3X@ M9FEL92!F;W5N9"P@8G5T(&EN=&5R;F%L(&QI;FL@:7,@86)S96YT#0H@("!A M(&AR968](U]T;V1O,# P,# U(#T]/3X@9FEL92!F;W5N9"P@8G5T(&EN=&5R M;F%L(&QI;FL@:7,@86)S96YT#0H@("!A(&AR968](V=A." ]/3T^(&9I;&4@ M9F]U;F0L(&)U="!I;G1E<FYA;"!L:6YK(&ES(&%B<V5N= T*(" @82!H<F5F M/2-?=&]D;S P,# P-B ]/3T^(&9I;&4@9F]U;F0L(&)U="!I;G1E<FYA;"!L M:6YK(&ES(&%B<V5N= T*(" @82!H<F5F/2-G83@@/3T]/B!F:6QE(&9O=6YD M+"!B=70@:6YT97)N86P@;&EN:R!I<R!A8G-E;G0-"@T*1DE,13H@(" @($,Z M7$1O8W5M96YT<R!A;F0@4V5T=&EN9W-<='5R:V%N:7-<2&]M95QB;V]S=%\Q M7S,S7S!<;&EB<UQS97)I86QI>F%T:6]N7&1O8UQA<F-H:79E<RYH=&UL#0H- M"B @(&$@:')E9CUS<&5C:6%L+FAT;6PC9&5R:79E9'!O:6YT97)S(#T]/3X@ M9FEL92!F;W5N9"P@8G5T(&EN=&5R;F%L(&QI;FL@:7,@86)S96YT#0H@("!A M(&AR968]<W!E8VEA;"YH=&UL(V1E<FEV961P;VEN=&5R<R ]/3T^(&9I;&4@ M9F]U;F0L(&)U="!I;G1E<FYA;"!L:6YK(&ES(&%B<V5N= T*#0I&24Q%.B @ M(" @0SI<1&]C=6UE;G1S(&%N9"!3971T:6YG<UQT=7)K86YI<UQ(;VUE7&)O M;W-T7S%?,S-?,%QL:6)S7'-E<FEA;&EZ871I;VY<9&]C7'1R86ET<RYH=&UL M#0H-"B @(&$@:')E9CUS<&5C:6%L+FAT;6PC9&5R:79E9'!O:6YT97)S(#T] M/3X@9FEL92!F;W5N9"P@8G5T(&EN=&5R;F%L(&QI;FL@:7,@86)S96YT#0H- M"D9)3$4Z(" @("!#.EQ$;V-U;65N=',@86YD(%-E='1I;F=S7'1U<FMA;FES M7$AO;65<8F]O<W1?,5\S,U\P7&QI8G-<<W!I<FET7&1O8UQP<F5F86-E+FAT M;6P-"@T*(" @82!H<F5F/6AT=' Z+R]W=W<N9V5O8W)A=VQE<BYC;VTO;&ES M=',O,R]3;W5R8V5&;W)G92\Q,C@S-R\P+R ]/3T^($5R<F]R.B!R97-O=7)C M92!N;W0@9F]U;F0@*%)%1$E214-4140@5$\Z(&AT=' Z+R]S;W5R8V5F;W)G M92YN970O;&ES=',O,R]3;W5R8V5&;W)G92\Q,C@S-R\P+R I#0H-"D9)3$4Z M(" @("!#.EQ$;V-U;65N=',@86YD(%-E='1I;F=S7'1U<FMA;FES7$AO;65< M8F]O<W1?,5\S,U\P7&QI8G-<<W!I<FET7'!H;V5N:7A<9&]C7'!R969A8V4N M:'1M; T*#0H@("!A(&AR968]:'1T<#HO+VYE=W,N9VUA;F4N;W)G+W1H<F5A M9"YP:' _9W)O=7 ]9VUA;F4N8V]M<"YS<&ER:70N9V5N97)A;" ]/3T^(%1H M92!A='1E;7!T('1O(&-O;FYE8W0@=&\@=&AE('-E<G9E<B!F86EL960N#0H@ M("!A(&AR968]:'1T<#HO+W=W=RYG96]C<F%W;&5R+F-O;2]L:7-T<R\S+U-O M=7)C949O<F=E+S$R.#,W+S O(#T]/3X@17)R;W(Z(')E<V]U<F-E(&YO="!F M;W5N9" H4D5$25)%0U1%1"!43SH@:'1T<#HO+W-O=7)C969O<F=E+FYE="]L M:7-T<R\S+U-O=7)C949O<F=E+S$R.#,W+S O("D-"@T*1DE,13H@(" @($,Z M7$1O8W5M96YT<R!A;F0@4V5T=&EN9W-<='5R:V%N:7-<2&]M95QB;V]S=%\Q M7S,S7S!<;&EB<UQT97-T7&1O8UQP;W)T86)I;&ET>2YH=&UL#0H-"B @($$@ M:')E9CUH='1P.B\O8F]O<W0N<V]U<F-E9F]R9V4N;F5T+W)E9W)E<W-I;VXM M;&]G<R]D979E;&]P97(O=&5S="YH=&UL(#T]/3X@17)R;W(Z(')E<V]U<F-E M(&YO="!F;W5N9 T*#0I&24Q%.B @(" @0SI<1&]C=6UE;G1S(&%N9"!3971T M:6YG<UQT=7)K86YI<UQ(;VUE7&)O;W-T7S%?,S-?,%QL:6)S7'1E<W1<9&]C M7&-O;7!O;F5N='-<=&5S=%]E>&5C7VUO;FET;W)<8V]M<&EL871I;VXN:'1M M; T*#0H@("!!(&AR968]+BXO+BXO+BXO<W)C+W5N:71?=&5S=%]R97-U;'0N M8W!P(#T]/3X@1FEL92!M:7-S:6YG#0H@("!!(&AR968]+BXO+BXO+BXO<W)C M+W-U<'!L:65D7VQO9U]F;W)M871T97)S+F-P<" ]/3T^($9I;&4@;6ES<VEN M9PT*#0I&24Q%.B @(" @0SI<1&]C=6UE;G1S(&%N9"!3971T:6YG<UQT=7)K M86YI<UQ(;VUE7&)O;W-T7S%?,S-?,%QL:6)S7'1E<W1<9&]C7&-O;7!O;F5N M='-<=71F7&-O;7!I;&%T:6]N+FAT;6P-"@T*(" @02!H<F5F/2XN+RXN+RXN M+W-R8R]U;FET7W1E<W1?<F5S=6QT+F-P<" ]/3T^($9I;&4@;6ES<VEN9PT* M(" @02!H<F5F/2XN+RXN+RXN+W-R8R]S=7!P;&EE9%]L;V=?9F]R;6%T=&5R M<RYC<' @/3T]/B!&:6QE(&UI<W-I;F<-"@T*1DE,13H@(" @($,Z7$1O8W5M M96YT<R!A;F0@4V5T=&EN9W-<='5R:V%N:7-<2&]M95QB;V]S=%\Q7S,S7S!< M;&EB<UQT97-T7&1O8UQC;VUP;VYE;G1S7'5T9EQC;VUP;VYE;G1S7'1E<W1? M8V%S95QB;V]S=%]F=6YC=&EO;E]T8RYH=&UL#0H-"B @($$@:')E9CTN+B\N M+B\N+B\N+B\N+B\N+B\N+B]B;V]S="]T97-T+W5N:71?=&5S=%]S=6ET95]E M>"YH<' @/3T]/B!&:6QE(&UI<W-I;F<-"@T*1DE,13H@(" @($,Z7$1O8W5M M96YT<R!A;F0@4V5T=&EN9W-<='5R:V%N:7-<2&]M95QB;V]S=%\Q7S,S7S!< M;&EB<UQT97-T7&1O8UQC;VUP;VYE;G1S7'5T9EQC;VUP;VYE;G1S7'1E<W1? M8V%S95QP87)A;5]B;V]S=%]F=6YC=&EO;E]T8RYH=&UL#0H-"B @($$@:')E M9CTN+B\N+B\N+B\N+B\N+B\N+B\N+B]B;V]S="]T97-T+W5N:71?=&5S=%]S M=6ET95]E>"YH<' @/3T]/B!&:6QE(&UI<W-I;F<-"@T*1DE,13H@(" @($,Z M7$1O8W5M96YT<R!A;F0@4V5T=&EN9W-<='5R:V%N:7-<2&]M95QB;V]S=%\Q M7S,S7S!<;&EB<UQT97-T7&1O8UQT97-T<UQU;FET7W1E<W1?<W5I=&5?97A? M=&5S="YH=&UL#0H-"B @($$@:')E9CTN+B\N+B]T97-T+W5N:71?=&5S=%]S M=6ET95]E>%]T97-T+F-P<" ]/3T^($9I;&4@;6ES<VEN9PT*#0I&24Q%.B @ M(" @0SI<1&]C=6UE;G1S(&%N9"!3971T:6YG<UQT=7)K86YI<UQ(;VUE7&)O M;W-T7S%?,S-?,%QP96]P;&5<9&%R:6Y?861L97(N:'1M#0H-"B @(&$@:')E M9CUH='1P.B\O=W=W+G-P:65S+F-O;2]^9W)E9R]B;'5E;65A;FEE<RYH=&UL M(#T]/3X@17)R;W(Z(')E<V]U<F-E(&YO="!F;W5N9 T*(" @82!H<F5F/6AT M=' Z+R]W=W<N9V5N97)A;&UA9VEC+F-O;2 ]/3T^($5R<F]R.C0P,PT*#0I& M24Q%.B @(" @0SI<1&]C=6UE;G1S(&%N9"!3971T:6YG<UQT=7)K86YI<UQ( M;VUE7&)O;W-T7S%?,S-?,%QT;V]L<UQB=6EL9%QV,5QB=6EL9%]S>7-T96TN M:'1M#0H-"B @(&$@:')E9CTC9W)I<W0@/3T]/B!F:6QE(&9O=6YD+"!B=70@ M:6YT97)N86P@;&EN:R!I<R!A8G-E;G0-"@T*1DE,13H@(" @($,Z7$1O8W5M M96YT<R!A;F0@4V5T=&EN9W-<='5R:V%N:7-<2&]M95QB;V]S=%\Q7S,S7S!< M=&]O;'-<8G5I;&1<=C%<9V-C+6YO8WEG=VEN+71O;VQS+FAT;6P-"@T*(" @ M82!H<F5F/6AT=' Z+R]W=W<N;F%N;W1E8V@N=VES8RYE9'4O?FMH86XO<V]F M='=A<F4O9VYU+7=I;C,R+VUN;RUC>6=W:6XM:&]W=&\N='AT(#T]/3X@17)R M;W(Z(')E<V]U<F-E(&YO="!F;W5N9 T*#0I&24Q%.B @(" @0SI<1&]C=6UE M;G1S(&%N9"!3971T:6YG<UQT=7)K86YI<UQ(;VUE7&)O;W-T7S%?,S-?,%QT M;V]L<UQB=6EL9%QV,5QS=6YP<F\M=&]O;',N:'1M; T*#0H@("!A(&AR968] M:'1T<#HO+V)O;W-T+G-O=7)C969O<F=E+FYE="]R96=R97-S:6]N+6QO9W,O M8W,M4W5N3U,N:'1M;" ]/3T^($5R<F]R.B!R97-O=7)C92!N;W0@9F]U;F0- #"@T* ` end

5 4

Review Request: xpressive
by Eric Niebler 04 Aug '05

04 Aug '05

As of version 0.9.5, posted yesterday, xpressive is close enough to v1.0 for me to feel comfortable putting it up for review. Could it please be added to the queue? BTW, GMane apparantly dropped the following msg, which I sent yesterday: << Background >> xpressive is a TR1 regex work-alike that also accepts regexes as expression templates and lets regexes nest and call each other recursively. << Significant changes since 0.9.3 >> - c_regex_traits to wrap the global C locale - null_regex_traits for searching non-char data - doc and test improvements - bugs in static regexes and Unicode support squashed << Download >> xpressive.zip at: http://boost-sandbox.sf.net/vault/index.php?directory=eric_niebler << Docs >> http://boost-sandbox.sf.net/libs/xpressive Note: You can consider this the xpressive 1.0 release candidate. All that remains is to add more tests and documentation, and perhaps a tweak to the traits interface. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

[1.33.0 RC1] Possible regression in multi_index
by Eelis van der Weegen 04 Aug '05

04 Aug '05

I'm having trouble compiling a source file consisting of the following single line: #include <boost/multi_index/ordered_index.hpp> Using gcc 3.3.5, I get the following error: In file included from t.cpp:1: .../boost_1_33_0/boost/multi_index/ordered_index.hpp: In member function `void boost::multi_index::detail::ordered_index<KeyFromValue, Compare, SuperMeta, TagList, Category>::rearranger(boost::multi_index::detail::ordered_index_node<typename SuperMeta::type::node_type>*, boost::multi_index::detail::ordered_index_node<typename SuperMeta::type::node_type>*)': .../boost_1_33_0/boost/multi_index/ordered_index.hpp:1092: error: no class template named `archive_exception' in `boost::archive' Needless to say this used to work with Boost 1.32 :) Regards, Eelis

1 0

[parameters] some typos in reference...
by Pavel Chikulaev 04 Aug '05

04 Aug '05

Hi Daniel, There are some strange symbols with modifier "<span class=doublesize>" after in section 4.2 after second member function definition, again in the same section in "operator()" subsection after first operator() definition, then in section 6.1 after second function body. Is it a bug of rst, or what? Also <hr> with class="docutils footer" IMO looks bad here - it's just take about 80% of space, and IMO it's would look much better if it would take 100%... Even simple <hr/> IMO would be better here... -- Pavel Chikulaev

3 6

Fw: [network] Boost.Network proposal v0.3
by Scott Woods 04 Aug '05

04 Aug '05

Pardon. An error in that last message. ----- Original Message ----- From: "Scott Woods" <scottw(a)qbik.com> To: <boost(a)lists.boost.org> > The above paragrah is about the long term significance of non-blocking vs > blocking. I believe you are also facing the issue of library > (de-)composition; > if you ultimately want to provide both a blocking and non-blocking API it > is less difficult to imagine a non-blocking API over a blocking API than the > other way around. Should be; "if you ultimately want to provide both a blocking and non-blocking API it is less difficult to imagine a blocking API over a non-blocking API than the other way around."

1 0