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

bind's bind vs lambda's bind
by Jean-Louis Leroy 30 Aug '05

30 Aug '05

I see two "bind" adapters in Boost 1.32: one from bind and one from lambda. Although they seem to have the same interface, each seems to have its own implementation. In effect, "using namespace boost; using namespace boost::lambda;" doesn't work. What's the story here? Are they going to merge someday? Is one a full superset of the other, or better implemented (and I should stick to that one)? Do you have suggestions about handling this? TIA... -- Jean-Louis Leroy Sound Object Logic http://www.soundobjectlogic.com

6 13

Re: [Boost-users] Boost.Thread memory leak reported
by Sohail Somani 30 Aug '05

30 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov > Sent: Friday, August 26, 2005 1:27 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.Thread memory leak reported > > > Sohail Somani wrote: > > >> Christian Henning wrote: > >> > >>> But Peter, we do agree that there is problem and it should > >> be fixed, > >>> dont't we? > >> > >> I see no problems in the code. > > > > Any dynamically allocated memory that isn't freed is a Bad > Thing imho. > > Because? Was it forgotten? Was it intentional? If the assumption is it will always be freed, then there is no ambiguity.

7 13

Boost.Wave compilation taking forever
by François Duranleau 30 Aug '05

30 Aug '05

I recently downloaded the source for Boost 1.33.0 and tried to compile and install it, but I hit a problem when compiling Boost.Wave: the compilation time for the file $BOOST_ROOT/libs/wave/src/instantiate_cpp_literalgrs.cpp seems to take forever (after 4 days, the compiler was still running hard, no output). Is that normal? It is mentioned in the documentation that without separate compilation, compiling a program using Boost.Wave can take up to an hour (depending on your system configuration), so I guess compiling the library could take a long time as well, but days!?! For reference, here is my compilation command: cd $BOOST_ROOT bjam --prefix=$SOMEWHERE --builddir=build --with-python-root=/usr \ "-sTOOLS=gcc" "-sBUILD=release <optimization>speed \ <runtime-link>dynamic <threading>multi" \ "-sPYTHON_VERSION=2.3" install The platform is x86_64 running GNU/Linux, kernel 2.6.10-1.771_FC2 (from Fedora Core 2). Compiler version is g++ (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7). -- Francois

4 4

Boost.Archive: Infinite recursion in dinkumware.hpp
by Daniel Krügler 30 Aug '05

30 Aug '05

The streaming inserter of Boost archive's dinkumware.hpp for boost::int64_t causes indefinite recursion in case of negative arguments. I think the following line inside the else clause should be changed from os << -t; to os << static_cast<boost::uint64_t>(-t); Greetings from Bremen, Daniel

2 4

Re: [Boost-users] incorrect random library equality implementation?
by Steven Solie 30 Aug '05

30 Aug '05

Scott McMurray wrote: > > The std::equal() call is comparing an array of doubles using > > operator == which I thought was impossible for floating point types > > due to their inexact nature et al. > > A (radix 2) floating-point number will never be exactly equal to one > seventh, for example, because it's not representable. The other issue > is that roundoff error will make things such as 1./3*3 not result in > exactly 1. > > That doesn't mean that you can't compare between them for equality. > If one float is a copy of another, then they should be bitwise equal. > Also, floating-point operations are deterministic, so the same > sequence of operations -- in exactly the same environment -- should > also yeild bitwise equal results. What the random streaming operators are doing is saving and restoring the state of the lagged_fibonacci607 object with text. This involves converting the doubles into strings and back again. I'm not certain if ISO C++ specifies whether we are allowed to assume the conversion from double to string and back always yields the identical floating point number or not. Here is a small test program that demonstrates what the random test suite is essentially doing: #include <iostream> #include <sstream> int main() { double pi = 3.14159; double pi2 = pi; if ( pi != pi2 ) { std::cout << "test failed, pi != pi2\n"; return -1; } std::ostringstream file; file << pi; std::string ostr(file.str()); std::istringstream input(file.str()); input >> pi; std::string istr(input.str()); if ( pi != pi2 ) { std::cout << "test failed, restored pi != pi2\n"; } else { std::cout << "passed\n"; } } This test always fails here. --Steven

1 0

[Random] Improved initialisation for mersenne_twister
by Richard Jennings 30 Aug '05

30 Aug '05

With Boost 1.33 the release notes say that there is improved initialisation for mersenne_twister. Does this mean that the pseudo-random sequence from the same seed will be different with Boost 1.33 to Boost 1.32? The reason I ask is that I use the random sequence to add noise to a signal and check how my algorithm handles it. As it's pseudo-random noise I can expect the same result each time and test for that expected result. It appears that with Boost 1.33 the results are very subtly different. That's fine, but I want to be clear that it's due to a change in the pseudo-random sequence (if it is) rather than some other regression. Richard

1 0

simple compile
by Martin Cavanagh 30 Aug '05

30 Aug '05

Hi everyone. I want to show my extreme newbieness. I can't compile the BASIC thread examples. I get lots of link errors http://www-eleves-isia.cma.fr/documentation/BoostDoc/boost_1_29_0/libs/thre… I'm running Windows XP SP2 with mingw (which compiles everything else in my project fine g++ -IC:/Boost/include/boost-1_32 -LC:/Boost/lib -lboost_thread-mgw-mt thread_test.cpp It definitely finds the library (when i miss type it it throws a different error) C:/DOKUME~1/Marty/LOKALE~1/Temp/cc8Yaaaa.o(.text+0x1ce): In function `main': c:/webcam/thread_test.cpp:27: undefined reference to `_imp___ZN5boost6threadC1ERKNS_9function0IvSaINS_13function_baseEEEE' C:/DOKUME~1/Marty/LOKALE~1/Temp/cc8Yaaaa.o(.text+0x235):c:/webcam/thread_test.cpp:28: undefined reference to `_imp___ZN5boost6thread4joinEv' C:/DOKUME~1/Marty/LOKALE~1/Temp/cc8Yaaaa.o(.text+0x26b):c:/webcam/thread_test.cpp:28: undefined reference to `_imp___ZN5boost6threadD1Ev' C:/DOKUME~1/Marty/LOKALE~1/Temp/cc8Yaaaa.o(.text+0x2a0):c:/webcam/thread_test.cpp:28: undefined reference to `_imp___ZN5boost6threadD1Ev' C:/DOKUME~1/Marty/LOKALE~1/Temp/cc8Yaaaa.o(.text$_ZN12thread_alarmclEv[thread_alarm::operator()()]+0x15): In function `ZN9__gnu_cxx13new_allocatorI12thread_alarmE7destroyEPS1_': c:/msys/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allocator.h: undefined reference to `_imp___ZN5boost9xtime_getEPNS_5xtimeEi' C:/DOKUME~1/Marty/LOKALE~1/Temp/cc8Yaaaa.o(.text$_ZN12thread_alarmclEv[thread_alarm::operator()()]+0x36):c:/msys/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allocator.h: undefined reference to `_imp___ZN5boost6thread5sleepERKNS_5xtimeE' collect2: ld returned 1 exit status But when I run it as 2 commands: g++ -IC:/Boost/include/boost-1_32 thread_test.cpp -o thread_test.o -c g++ -LC:/Boost/lib -o manual_test thread_test.o -lboost_thread-mgw-mt It compiles perfectly, no warnings or anything $ manual_test.exe setting alarm for 5 seconds... alarm sounded... is there some rule, for producing executables from librarys, that the linking stage must be seperate???? Thanks Martin Send instant messages to your online friends http://au.messenger.yahoo.com

3 2

Re: [Boost-users] Thread cancellation
by Sliwa, Przemyslaw (London) 30 Aug '05

30 Aug '05

Zthread looks promising but there is no documentation at all. In addition there is no mailing list. Pshemek -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Charles BROSSOLLET Sent: 30 August 2005 12:52 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Thread cancellation The ZThreads library supports thread cancellation, but I haven't tried it. Does anyone who have an experience with both libraries could share what he thinks of each one? Regards -- Charles ----- Original Message ----- From: Janusz Piwowarski To: boost-users(a)lists.boost.org Sent: Tuesday, August 30, 2005 11:52 AM Subject: Re: [Boost-users] Thread cancellation Sliwa, Przemyslaw (London) wrote: > Can anyone tell me if it is possible to cancel a thread using > boost.thread library? Form Boost.Thread FAQ: Q: Why isn't thread cancellation or termination provided? A: There's a valid need for thread termination, so at some point Boost.Threads probably will include it, but only after we can find a truly safe (and portable) mechanism for this concept. Regards, -- Janusz _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

1 0

Boost.Signals: Suspicious workaround tests
by Daniel Krügler 30 Aug '05

30 Aug '05

Yesterday I stumbled about the following tests in boost 1.33: In signals/detail/named_slot_map.hpp: class named_slot_map_iterator { .. #if BOOST_WORKAROUND(_MSC_VER, <= 0x1701) ... }; In signals/signal_template.hpp class BOOST_SIGNALS_SIGNAL { ... #if BOOST_WORKAROUND(BOOST_MSVC, <= 0x1700) ... }; Are these tests really correct?? I am wondering because _MSC_VER has the following values (decimal!!) VC6: 1200 VC7: 1300 VC7.1: 1310 which does not fit to those hexadecimal values, which would correspond to version number 5888 and 5889 (!). I know that boost coworkers often have good contacts to compiler providers, but that good ... ;-)) Greetings from Bremen, Daniel Krügler

2 1

[assign] Some basic questions (lengthy code example)
by Ames Andreas 30 Aug '05

30 Aug '05

Hi all, I could use some advice regarding this lengthy code example: ---------- <code> ------------ #include <vector> #include <map> #include <boost/function.hpp> #include <boost/assign.hpp> struct E1 {}; struct E2 {}; enum State { eS1 = 1, eS2 }; typedef boost::function< bool (const E1 &, int) > function0_t; typedef boost::function< bool (const E2 &, int) > function1_t; struct Functions { // Functions(std::vector< function0_t > af0 , std::vector< function1_t > af1) // : f0(af0) , f1(af1) // { // } std::vector< function0_t > f0; std::vector< function1_t > f1; }; struct Handler1 { bool operator()(const E1&, int) {return true;} }; struct Handler1a { bool operator()(const E1&, int) {return true;} }; struct Handler2 { bool operator()(const E2&, int) {return true;} }; typedef std::map< State, Functions > InitDesc; using namespace boost::assign; int main() { // [1] this works just fine Functions f1 = { list_of(Handler1()), list_of(Handler2())}; // [2] this doesn't work cause Handler1 and Handler1a have different types Functions f2 = { list_of(Handler1())(Handler1a()), list_of(Handler2())}; // [3] don't know how to do this InitDesc desc = map_list_of(eS1, {list_of(Handler1()), list_of(Handler2())}) (eS2, {list_of(Handler1a()), list_of(Handler2())}); } ---------- </code> ------------ The places marked with [1], [2] and [3] are of special interest for me. I like [1] very much thanks to what bost::assign offers me. Unfortunately I can get [2] only to work, if I explicitly create instances of function0_t from Handler1 and Handler1a. Are there more elegant ways to make this work? [3] is obviously broken, but I don't know how to come up with a similarly compact way to initialise an InitDesc instance. I can uncomment Funtions' constructor above and call it explicitely with what I've written into curly braces but that unfortunately breaks [1] (because Functions is no longer aggregate then). Is there a better way to do it prefarably without breaking [1]? TIA, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | andreas . ames AT comergo . com

1 0