- Boost-users - lists.boost.org

Re: [Boost-users] Boost::multiIndex container problems
by JOAQUIN LOPEZ MU?Z 30 Aug '05

30 Aug '05

2 1

[statechart] Can events carry data?
by BRIDGES Dick 30 Aug '05

30 Aug '05

Is there any provision for "event-local" storage? I'd like to create events that carry data (e.g., timestamp, source, etc.) to be used by reactions and transitions to update state-local storage. I didn't see anything like this in the documentation. Bad idea? Major drawbacks? If it wouldn't be a problem, how might I go about doing it? Regards, Dick Bridges

2 1

function object wrapper problem
by Okko Willeboordse 30 Aug '05

30 Aug '05

I have a class that has a constructor that takes a Boost function object wrapper; class some_class { public: some_class(const boost::function1<wchar_t*, short*>& some_member) .... I call the constructor with a member function using Boost bind. some_class some_object(boost::bind(&some_other_class::some_member, &some_other_object, _1)); Now I want to use some_class for some_member functions that return an other type pointer. So I do class some_class { public: template <class T> some_class(const boost::function1<T*, short*>& get_member) .... But now the compiler (VS 2003) starts complaining; error C2664: 'some_class::some_class(const some_class &)' : cannot convert parameter 1 from 'boost::_bi::bind_t<R,F,L>' to 'const some_class &' with [ R=wchar_t *, F=boost::_mfi::mf1<wchar_t *,some_other_class,short *>, L=boost::_bi::list2<boost::_bi::list_av_2<some_other_class *__w64 ,boost::arg<1>>::B1,boost::_bi::list_av_2<some_other_class *__w64 ,boost::arg<1>>::B2> ] Reason: cannot convert from 'boost::_bi::bind_t<R,F,L>' to 'const some_class' with [ R=wchar_t *, F=boost::_mfi::mf1<wchar_t *,some_other_class,short *>, L=boost::_bi::list2<boost::_bi::list_av_2<some_other_class *__w64 ,boost::arg<1>>::B1,boost::_bi::list_av_2<some_other_class *__w64 ,boost::arg<1>>::B2> ] No constructor could take the source type, or constructor overload resolution was ambiguous Any ideas? Many thanks, Okko Willeboordse

3 4

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