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

[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