- Boost - lists.boost.org

RE: [boost] Critique of Boost.Threads
by Jon Kalb 10 May '05

10 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes > Sent: Wednesday, May 04, 2005 6:31 AM > To: Boost mailing list > Subject: [boost] Critique of Boost.Threads > > With Kevlin Henney's permission, the following is a repost of > a message he recently posted on the C++ committee's library > reflector. It gives his views on Boost.Threads in the context > of possible standardization. > > --Beman > > ------- I have a (newbie) question about the joiner API. > And usage as follows: > > void void_task(); > int int_task(); > ... > joiner<void> wait_for_completion = thread(void_task); > joiner<int> wait_for_value = thread(int_task); > ... > int result = wait_for_value(); > wait_for_completion(); In the code snippet above does the line "int result = wait_for_value();" block until the completion of the thread? (It must or there is no way of knowing if the value of result is valid.) Is there a way for the client to avoid the block by checking whether or not thread is completed so that the call won't block... Some sort of wait_for_value.is_done()? -- Jon Kalb jonkalb(a)microsoft.com

3 2

[Integer] Libraries needs to be taught about Compaq Tru64 UNIX
by Douglas Gregor 10 May '05

10 May '05

Someone with access to Compaq Tru64 UNIX could probably fix the two COMSOFT errors in the Integer library: http://www.meta-comm.com/engineering/boost-regression/cvs-head/ developer/integer.html in a manner of minutes. It's likely some preprocessor magic that needs to be introduced. Doug

3 2

Re: Singleton Review: GCC compiler errors
by Jason Hise 10 May '05

10 May '05

Tobias Schwinger wrote: > Jason Hise wrote: > >> Sorry about the duplicate messages, thunderbird seemed to be having a >> problem. Hoping it's fixed now. >> >> Jason Hise wrote: >> >>> Tom Brinkman wrote: >>> >>>> Was the "singleton" library tested on GCC. I'm getting many >>>> compiler errors on 3.34. >>> >>> >>> >>> It was a while back, but many changes have been made since then. >>> I'll see if I can track down a copy of gcc to try compiling with it >>> myself. >> >> >> >> Actually, now that I'm looking into it it appears that Dev C++ uses a >> port of GCC by default, and I have successfully tested the latest >> version with Dev C++, getting no warnings or errors. What error >> messages are you getting? >> > > Are you sure you had all warnings enabled (-Wall) ? > > It was rather loud on my system. However, I could successfully build > tests and example with both 3.2 and 3.4 (both MinGW32). > > I'll send the output to you in private mail. Thanks for the heads up that I needed to use the -Wall option (I'm not used to working with gcc). I am now getting the same warnings that you sent to me, and am working to correct them. In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc? -Jason

8 10

[dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
by Doug Gregor 10 May '05

10 May '05

The stream extraction operators for dynamic_bitset are failing on CodeWarrior 9.4. See: http://tinyurl.com/addko Is anyone familiar enough with the quirks of Metrowerks' iostreams to fix this issue? Doug

1 0

[mpl] problems with VC7.0 + /Za
by Jonathan Turkanis 10 May '05

10 May '05

Hi, In porting Boost.Range to VC7, I discovered that several MPL headers do not compile if language extensions are disabled. I have verified the problem with the logical metafunctions (and, or, ...), the arithmetic metafunctions (plus, divides, ...) and the bitwise arithmetic functions. Jonathan

1 0

Re: [boost] Re: Calling a python function from C++ to update a progress display widget
by Ralf W. Grosse-Kunstleve 09 May '05

09 May '05

--- David Abrahams <dave(a)boost-consulting.com> wrote: > "Thierry Lam" <lam(a)pcigeomatics.com> writes: > > Hi Thierry, > > In the future, a better place for Boost.Python questions is > http://www.boost.org/more/mailing_lists.htm#cplussig That list is broken at the moment. :( I don't know why, and I am still waiting for a response from the Python people. Cheers, Ralf __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

BOOST_LOG & dlls
by Dirk Griffioen 09 May '05

09 May '05

Hi John, (I don't know if you get this but anyway). If I define & enable a log in a .lib but use it in a .dll somewhere else in the app (via declare in a .hpp file), I don't get no output from the dll: app.exe / \ log.lib stuff.dll (Compiles/links fine and the exe has output - but the dll has not.) Somehow, I want to avoid having a 'DECLARE + setup_logging' in all my dlls. Am I missing something? Best wishes, Dirk Griffioen ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this email in error please notify our system management at postmaster(a)optiver.com and immediately and permanently delete this message and any attachments. ********************************************

3 2

Formal Review: FOREACH macro
by Gennadiy Rozental 09 May '05

09 May '05

The formal review of Eric Nibbler's FOREACH macro starts today, April 25, and will continue until Monday, May 1st. I will be serving as review manager. BOOST_FOREACH is a macro that makes it simple to iterate over STL containers, ranges, arrays and null-terminated strings. Its performance approaches that of the hand-coded equivalent loop. BOOST_FOREACH uses Boost.Range can be extended to iterating user-defined collections by extending Boost.Range. The library is available at: http://boost-sandbox.sourceforge.net/vault/index.php?directory=eric_niebler foreach.zip Please note that the documentation is also available separately from the sources. It also can be viewed online at: http://boost-sandbox.sourceforge.net/libs/foreach The library is known to work (with different compliance levels) at least on the following compilers: * Visual C++ 7.1 * Visual C++ Whidbey Beta * Visual C++ 7.0 * Visual C++ 6.0 * gcc 3.3.3 * Intel for Windows 8.0 * Intel for Windows 7.0 * Comeau 4.3.3 When submitting reviews, please state explicitly whether or not you believe that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. Gennadiy

36 141

Re: [boost] (Named) Parameter Library
by Cromwell Enage 09 May '05

09 May '05

Daniel Wallin wrote: > Yes, that's correct. Although the code has been moved > to the Boost CVS and the namespace has been changed > to 'parameter'. Oh, that's where it is, now. Cool! A second look at the new code revealed that much of the type-extraction functionality I sought has already been implemented in <boost/parameter/aux_/arg_list.hpp>, under the nested struct 'key_value_type' (lines 71-78 and 186-196). However, this struct is defined only for older compilers. Can the definitions be moved out of the conditional macro blocks? That way, a type-extraction metafunction like the following would work: template < class ArgList, class KW, class Default > struct get_key_value_type : mpl::apply2< typename ArgList::key_value_type , KW , Default > { } > Thank you. I've merged your macro change into the > trunk, but I'm holding off the type-extraction code > until we have completed the changes we are currently > working on. No problem. Just don't take too long! My multi-state mazes project makes heavy use of this library. I'm currently working on documentation and a 2-D demo, and I hope to release it to the OS community in three or four weeks. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

archive's i/o register_type() signature (Bug#308291: please prevent compiler warning about unused variable)
by Domenico Andreoli 09 May '05

09 May '05

hi, boost debian package has been reported this bug/wish. is anybody able to commit this tiny fix? many thanks. cheers domenico ----- Forwarded message from martin f krafft <madduck(a)debian.org> ----- Date: Mon, 9 May 2005 09:59:43 +0200 From: martin f krafft <madduck(a)debian.org> Subject: Bug#308291: please prevent compiler warning about unused variable Some of us like to use -Werror. Some of boost does not. Please consider the following, non-intrusive and tested patches: diff -u /tmp/interface_oarchive.hpp /usr/include/boost/archive/detail/interface_oarchive.hpp --- /tmp/interface_oarchive.hpp 2005-05-09 09:54:24.897652747 +0200 +++ /usr/include/boost/archive/detail/interface_oarchive.hpp 2005-05-09 09:54:56.611522300 +0200 @@ -57,7 +57,7 @@ } template<class T> - const basic_pointer_oserializer * register_type(T * t = NULL){ + const basic_pointer_oserializer * register_type(T * = NULL){ const basic_pointer_oserializer & bpos = instantiate_pointer_oserializer( static_cast<Archive *>(NULL), diff -u /tmp/interface_iarchive.hpp /usr/include/boost/archive/detail/interface_iarchive.hpp --- /tmp/interface_iarchive.hpp 2005-05-09 09:58:24.366913089 +0200 +++ /usr/include/boost/archive/detail/interface_iarchive.hpp 2005-05-09 09:58:31.519755952 +0200 @@ -53,7 +53,7 @@ } template<class T> - const basic_pointer_iserializer * register_type(T * t = NULL){ + const basic_pointer_iserializer * register_type(T * = NULL){ const basic_pointer_iserializer & bpis = archive::detail::instantiate_pointer_iserializer( static_cast<Archive *>(NULL), ----- End forwarded message ----- -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

1 0