- Boost-users - lists.boost.org

boost and g++-4.0
by Marc Cromme 28 Nov '04

28 Nov '04

I was wondering if Boost does work with g++ 4.0 (on Linux/Unix systems). I have seen that the config files boost/config/compiler/gcc.hpp check up to version 3.4. (boost version 1.31.0-9 on a debian testing system) Does anybody have experiences with g++ 4.0 ?? Is there a gcc.hpp including tests for g++ 4.0 ?? Something else I should know and do not ?? Marc Cromme -- Marc Cromme, cand. polyt, Ph.D Senior Developer, Project Manager Index Data Aps Købmagergade 43, 2 1150 Copenhagen K. Denmark tel: +45 3341 1000 fax: +45 3341 0101 http://www.indexdata.com INDEX DATA Means Business for Open Source and Open Standards

1 0

Can't compile very simple snippet that uses boost::tuple
by Frank Astier 28 Nov '04

28 Nov '04

I am pretty sure it's because of my lack of skills with templates... Still, I don't understand why I can stream a vector if it's on its own, but not if it's stored in a boost::tuple. And it works with a std::pair! Any hint? #include <boost/tuple/tuple.hpp> #include <boost/tuple/tuple_io.hpp> #include <iostream> #include <vector> #include <algorithm> using namespace std; using namespace boost; template <typename T> ostream& operator<<(ostream& out, const vector<T>& v) { copy(v.begin(), v.end(), ostream_iterator<T>(out, " ")); return out; } template <typename T, typename U> ostream& operator<<(ostream& out, const pair<T, U>& p) { return out << p.first << " " << p.second; } int main(int, char**) { vector<float> v; cout << v; // Works fine pair<vector<float>, pair<int, int> > p; cout << p; // Works fine tuple<vector<float> > t; cout << t; // <== WON'T COMPILE } Thanks, Frank

2 1

Another use for apply.
by Paul Elliott 28 Nov '04

28 Nov '04

The bind documentation mentions the apply object as a way to get around the fact that bind does not evaluate its first arguement. There is another use. You can reverse the roles of function and parameters. You can use apply and bind to turn a parameter into a functor, and call it using a function as a parameter! Example. #include <boost/bind.hpp> #include <boost/function.hpp> #include <boost/bind/apply.hpp> #include <fstream> #include <iostream> #include <iomanip> // some sample test functions. (data) int g(int x) {return x+1;}; int h(int x) {return x*x; }; int main(int argc, char * argv) { // want to work with functions of the form int f(int); typedef int P(int); // bind the integer 5 to apply turning // apply into the number 5 into a function! call it five boost::function<int (P)> five = boost::bind(boost::apply<int>(),_1,5); //int y = five(g); // Now call 5 with the "data" g and h. std::cout << "+1=" << five(g) << std::endl << "square = " << five(h) << std::endl; return 0; }; Results: +1=6 square = 25 -- Paul Elliott 1(512)837-1096 pelliott(a)io.com PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

1 0

[Q] Unresolved references when linking against the test libs
by Michael Peterson 27 Nov '04

27 Nov '04

I apologize in advance if this turns out to be a linker problem not related to boost. So here goes: For compatibility/legacy reasons, we can not use the Boost.Build jamfiles to build our application. Accordingly, I've written a set of traditional makefiles to build the project's executables and have run into difficulties. Specifically, when I try to link my test program against the boost test libraries, I get an error message (reformatted for easy reading) saying that the reference to test_main can not be resolved. Here's the spew (formatted to make it easier to read): g++ -g3 -L../long/debug -L/usr/lib -L/usr/local/lib -L/usr/local/lib/stlport -L/usr/local/lib/boost -o "debug/unit_test" debug/longtest.o -lLong -lboost_unit_test_framework-gcc-mt-p -lboost_test_exec_monitor-gcc-mt-p -lpthread -lc /usr/local/lib/boost/libboost_test_exec_monitor-gcc-mt-p.so: undefined reference to `test_main(int, char**)' collect2: ld returned 1 exit status make: *** [debug/unit_test] Error 1 According to nm, the undefined reference, test_main, is defined in the exec_monitor library. I've tried reordering the libraries but no joy. Any advice and/or hints would be very much appreciated. I am using STLPort-4.6.2 and boost_1_32_0 and Linux (I386) Cheers, Michael

3 4

[Q] BBV2 -- How to control naming of libraries...
by Michael Peterson 27 Nov '04

27 Nov '04

This is another getting started question: I noticed that when I staged the build of the boost libraries, unlike BBV1, the lib names were of the form boost_xxx.so. I would like to be able to control the naming (and staging) such that ib names are prefixed with 'lib' and have a version number for a suffix. For example, instead of boost_xxx.so I would like the libs to be named libboost_xxx.so-1.32.0 Must I modify the <lib> target in each Jamfile.v2 to accomplish these ends? Thanks, again Michael P.S. Still haven't solved the unresolved reference to test_main. I now suspect that the libraries did not get built correctly (I used bbv1) because I can take source code directly from the examples and it fails with the same error. Hence, I'm trying to build using BBV2.

1 0

Thread Join/StackTrace
by Fallon, David 26 Nov '04

26 Nov '04

I am having problems debugging an application under Linux using gdb and the boost threads library. The problem I am basically having is the stack trace is only going back to the join statement rather than to point in the program that caused the crash. My application is reasonable complicated so to reproduce it I have created a buggy version of the helloword4 tutorial. The slightly modified the helloworld4 tutorial program to loop 7 times and then crash. The stack trace given in gdb points back to the join statement rather than the source code line that generated the error. Has anyone else come across this problem? // Copyright (C) 2001-2003 // William E. Kempf // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. William E. Kempf makes no representations // about the suitability of this software for any purpose. // It is provided "as is" without express or implied warranty. #include <boost/thread/thread.hpp> #include <boost/bind.hpp> #include <iostream> #include <string.h> void helloworld(const char* who) { for(int i = 0 ; i < 10; i++ ) { std::cout << who << "says, \"Hello World.\" " << i << std::endl; sleep(2); if(i > 7 ) { std::cout << " will crash " << std::endl; char * p = NULL; strcpy(p,"abcde "); // CAUSES Segmentation FAULT here but gdb } } } int main() { boost::thread thrd(boost::bind(&helloworld, "Bob")); thrd.join(); // Stack trace STOPS HERE }

2 1

Boost Thread - Read Write Mutex Problem
by David Brownell 26 Nov '04

26 Nov '04

When running the simple program listed below, the scoped_read_lock appears to never acquire a read lock on the mutex and, as a result, the program never finishes. In looking through the documentation, I don't think there is anything additional I need to do and was a bit surprised that this didn't work. Here is the code: boost::read_write_mutex m(static_cast<boost::read_write_scheduling_policy::read_write_scheduling_pol icy_enum>(alternating_many_reads)); std::cout << "Before\n"; { boost::read_write_mutex::scoped_write_lock l(m); } std::cout << "Middle\n"; { boost::read_write_mutex::scoped_read_lock l(m); } std::cout << "After\n"; And some more details: - test_read_write_mutex.cpp completed without problems - writer_priority and reader_priority completed without problems. Only alternating_many_reads and alternating_single_read seem to have problems. - Windows XP SP2 - Microsoft Visual Studio 2003 - I am compiling with the Multithreaded DLL version of the CRT, so boost_thread-vc71-mt-gd-1_32.lib is being used Thanks for your help! David Brownell

1 0

Serialization: shared_ptr documentation
by Malte Clasen 26 Nov '04

26 Nov '04

Hi, the serialization docs about shared_ptr state that you have to call void_cast_register to use shared_ptr: ---------- This indicates that we're not quite done. [...] In this case we need only the latter function so we can replace the base object serialization with: // register the relationship between each derived class // its polymorphic base void_cast_register< boost::detail::sp_counted_base, boost::detail::sp_counted_base_impl<P, D> >(); ---------- (http://boost.org/libs/serialization/doc/shared_ptr.html) There are two issues with this: a) The actual void_cast_register declaration has its parameters in the reverse order: ---------- template<class Derived, class Base> inline BOOST_DLLEXPORT const void * void_cast_register( const Derived * /* dnull = NULL */, const Base * /* bnull = NULL */ ) BOOST_USED; ---------- (void_cast.hpp) b) It doesn't seem to work either way, although there are different exceptions in both cases. The demo_shared_ptr.cpp doesn't even call it, instead the following is used: ---------- oa.register_type( static_cast< boost::detail::sp_counted_base_impl< B *, boost::checked_deleter<B> > * >(NULL) ---------- (demo_shared_ptr.cpp) This one actually works, the use counter is properly updated. So I guess the documentation is outdated, isn't it? Malte

2 1

cannot compile serialization library
by "Kay Erik Münch" 25 Nov '04

25 Nov '04

Hi, I'm using the borland 5.6.4 compiler on a Win2k platform. For compiling the serialization lib i followed the hint given in the "Release Notes" to use spirit 1.6x I chdir-ed into the serialization\build directory and called: bjam -sTOOLS=borland -sBCCROOT=C:\Programme\Borland\CBuilder6 -sSPIRIT_ROOT=K:\spirit161 bcc32 tells me (rougly translated): borland-C++-action ..\..\..\bin\boost\libs\serialization\build\ libboost_serialization.lib\borland\debug\xml_grammar.obj K:\boost_1_32_0\libs\serialization\build\../src/xml_grammar.cpp: Error E2209 K:\spirit161\boost/spirit/core/basics.hpp 19: \ include-File 'boost/mpl/apply_if.hpp' could not be opened *** 1 Error ... *** "C:\Programme\Borland\CBuilder6\bin\bcc32" -j5 -g255 -q -c -P -w -Ve -Vx -a8 -b- -DBOOST_TEST_NO_AUTO_LINK=1 -v -Od -vi- -tWC -tWR -tWC -WM- -w-8080 -w-8071 -w-8057 -w-8001 -I"..\..\..\bin\boost\libs\serialization\build" -I"K:\spirit161" -I"C:\Programme\Borland\CBuilder6\include" -I"K:\boost_1_32_0" -o"..\..\..\bin\boost\libs\serialization\build\libboost_serialization.lib\ borland\debug\xml_grammar.obj" "K:\boost_1_32_0\libs\serialization\build\../src/xml_grammar.cpp" He's right, there is no apply_if.hpp in the mpl library any more. How can i get the library compiled ? -- Thanks for boost ! Kay ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

3 3

Re: Memory leak reported using threads library
by alansa＠ati-uk.com 25 Nov '04

25 Nov '04

I don't mind any one off small leaks. They may not be nice but no one is going to notice them. What bothers me is when memory keeps leaking for each iteration of the loop. I don't bother with the microsoft crt leak stuff. It's rarely that much use in complex projects and even if it does detect a leak it rarely can tell you where it is. As it turns out the crt leak detect stuff doesn't seem to show any leak (at least on my system), but lets say I put in my own my own leak of say new char[10] or something then the leak messages pour out. Use windows performance counters however and it's a different story, watch the working set rocket up. And it seems to increase at different rates depending on what the thread is doing. Eventually you will run out of memory entirely. Use the crt dll in your main program however and the working set is dead flat. >What I don't understand is your mentioning of the boost::function lib. >Where do you think it is getting used in >your example? boost::function is being used in the constructor of thread i believe. Has anyone been able to confirm this leak or is it just me? Naturally boost::threads is a dll only (at least v 1.30 which i'm currently using) and it itself can either link dynamically or statically to the crt. It doesn't make any difference which though. I have to link dynamically to crt in my program to avoid the leak. Why should this make a difference? I don't particular want to upgrade to 1.32 for my project as it's rather late in the day. I don't want any other issues creeping in and I've resolved the issue by using the dll. However I thought I should report my findings and see if anyone knows anything about it. Do we know if there is no leak in 1.32 or is it still there? Thanks. Alan

8 11