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

[bgl] Problem with topological_sort
by Loïc Joly 20 Jul '06

20 Jul '06

Hello, When I run the example code of topo_sort.cpp in the BGL examples folder, it works perfectly. However, if I replace in this example: typedef adjacency_list<vecS, vecS, directedS, property<vertex_color_t, default_color_type> > Graph; By: typedef adjacency_list<listS, listS, directedS, property<vertex_color_t, default_color_type, property<vertex_index_t, int > > > Graph; It compiles, but during execution, some assert occurs. This assert occurs deep within my std::vector implementation (msvc8.0), in the call stack, the latest reference to boost is > TopoSort.exe!boost::iterator_property_map<std::_Vector_iterator<enum boost::default_color_type,std::allocator<enum boost::default_color_type> >,boost::adj_list_vertex_property_map<boost::adjacency_list<boost::listS,boost::listS,boost::directedS,boost::property<enum boost::vertex_color_t,enum boost::default_color_type,boost::property<enum boost::vertex_index_t,int,boost::no_property> >,boost::no_property,boost::no_property,boost::listS>,int,int const &,enum boost::vertex_index_t>,enum boost::default_color_type,enum boost::default_color_type &>::operator[](void * v=0x00355eb8) Line 349 + 0x67 bytes C++ Or, for people who don't read msvc on a daily basis, it indicated the line 350 of property_map.cpp : /*template<...> class iterator_property_map : ... { */ inline R operator[](key_type v) const { return *(iter + get(index, v)) ; } Does anybody have any idea of what the problem might be ? Best regards, -- Loïc

2 2

[function]unwanted conversion
by Sean Huang 20 Jul '06

20 Jul '06

I was surprised that the following code compiled: #include <boost/function.hpp> int main(int argc, char argv[]) { typedef boost::function< void ( void ) > MyFunction; MyFunction test1 = char(); MyFunction test2 = 0; return 0; } Is there any reason why boost::function allows such conversions? Thanks, Sean

2 2

Re: [Boost-users] [function]unwanted conversion
by Sohail Somani 19 Jul '06

19 Jul '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Sean Huang > Sent: Wednesday, July 19, 2006 1:22 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] [function]unwanted conversion > > I was surprised that the following code compiled: > > #include <boost/function.hpp> > > int main(int argc, char argv[]) > { > typedef boost::function< void ( void ) > MyFunction; > MyFunction test1 = char(); > MyFunction test2 = 0; > return 0; > } That is a funny one... I wonder if its interpreting it as a function pointer because its 0. If you try it with a non-zero value it doesn't work.

1 0

Re: [Boost-users] Asio & strand & threads
by Zola 19 Jul '06

19 Jul '06

Boosters, Ok -- turns out I really didn't know what I was doing. And I really didn't want strand at all- I'm still fuzzy on strand. But here's the code for what I really did want. And the thread group is handling the Handlers properly. Now my question is... Why is a deadline timer the way it is? What's it good for? Why isn't a delay/timer like a wrapper, that you can give a function object to, and then push that into the io_service queue with a delay? So you could do something like, io_s.post(deadline_timer(boost::posix_time::milliseconds(100), &f)); ? - Zola #include <iostream> #include <boost/asio.hpp> #include <boost/thread/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/xtime.hpp> #include <boost/bind.hpp> #include <boost/function.hpp> #include <boost/ref.hpp> #include <boost/date_time/posix_time/posix_time.hpp> #include <vector> namespace asio = boost::asio; int const num_threads = 10; std::vector<boost::thread*> tv(num_threads); boost::mutex tv_mutex; boost::mutex io_mutex; class Test { public: Test(asio::io_service& io_s, unsigned int n) : io_s(io_s), n(n), f(boost::bind(&Test::print, this)) { io_s.post(f); } void print() { if (n >= 0) { { boost::mutex::scoped_lock lock(io_mutex); std::cout << "(thread=" << thread_num() << ") "; std::cout << "Timer: " << n << std::endl; } { boost::mutex::scoped_lock lock(m_mutex); io_s.post(f); --n; } boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); } } int thread_num() { boost::thread t; for (int i=0; i<num_threads; ++i) { boost::mutex::scoped_lock lock(tv_mutex); if (tv[i] && (*tv[i] == t)) { return i; } } return -1; } private: asio::io_service& io_s; unsigned int n; boost::function<void()> f; boost::mutex m_mutex; }; int main() { asio::io_service io_s; Test t(io_s, 1000); boost::thread_group threads; for (int i=0; i<num_threads; ++i) { boost::mutex::scoped_lock lock(tv_mutex); tv[i] = threads.create_thread(boost::bind(&asio::io_service::run, boost::ref(io_s))); } threads.join_all(); }

1 0

Asio & strand & threads
by Zola 19 Jul '06

19 Jul '06

Hi Boosters, I'm trying to figure out how Asio's strand works. My concept of strand is a bit blurry. Asio's Timer.5 tutorial says: "An boost::asio::strand<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00260…>guarantees that, for those handlers that are dispatched through it, an executing handler will be allowed to complete before the next one is started. This is guaranteed irrespective of the number of threads that are calling boost::asio::io_service::run()<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00139…>. Of course, the handlers may still execute concurrently with other handlers that were *not* dispatched through an boost::asio::strand<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00260…>, or were dispatched through a different boost::asio::strand<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00260…>object." Asio's documentation for boost::asio::io_service::run says: "Run the io_service's event processing loop. The run()<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00139…>function blocks until all work has finished and there are no more handlers to be dispatched, or until the io_service<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00139…>has been interrupted. Multiple threads may call the run()<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00139…>function to set up a pool of threads from which the io_service<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00139…>may execute handlers." The key here is "Multiple threads may call the run()<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00139…>function to set up a pool of threads from which the io_service<http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00139…>may execute handlers." -- This implies to me that it's automatic, and the thread pool will take whatever work it can. I've created a little example which has ten threads calling io_service::run, and printing out which thread is calling a handler given to the deadline timer. The issue here is that when I run this Test, the same thread is calling print() every time, no matter what I do. My understanding of this Test is as so: io_service holds a queue of asynchronous events. You fill up the io service with events, and then you call run on it. If multiple threads call run, they'll do whatever work they can. I'm calling run from 10 threads: Each thread will see what events are there, and handle them if possible. The asynchronous waits are calling a strand wrapper. The strand wrapper is like a mutex, and ensures that no two threads will call print() at the same time. What is going on, and why is the same thread calling print() every time? Is my understanding here completely wrong? - Zola // The Test: #include <iostream> #include <boost/asio.hpp> #include <boost/thread/thread.hpp> #include <boost/bind.hpp> #include <boost/function.hpp> #include <boost/date_time/posix_time/posix_time.hpp> #include <vector> namespace asio = boost::asio; int const num_threads = 10; std::vector<boost::thread*> tv(num_threads); class Test { public: Test(asio::io_service& io, int n, int ms) : n(n), ms(ms), s(io), dt(io, boost::posix_time::milliseconds(ms)), f(boost::bind(&Test::print, this)) { dt.async_wait(s.wrap(f)); } void print() { if (n >= 0) { boost::thread t; for (int i=0; i<num_threads; ++i) { if (tv[i] && (*tv[i] == t)) { std::cout << "(thread=" << i << ") "; break; } } std::cout << "Timer: " << n << std::endl; --n; dt.expires_at(dt.expires_at() + boost::posix_time::milliseconds(ms)); dt.async_wait(s.wrap(f)); } } private: int n; unsigned int ms; asio::strand s; asio::deadline_timer dt; boost::function<void (asio::error&)> f; }; int main() { asio::io_service io; Test t(io, 1000, 5); // 1000 iterations, every 5 ms. boost::thread_group threads; for (int i=0; i<num_threads; ++i) { tv[i] = threads.create_thread(boost::bind(&asio::io_service::run, &io)); } threads.join_all(); }

1 0

adding -fPIC flag for AMD64
by Scott Amort 19 Jul '06

19 Jul '06

Hi All, I am trying to statically link a shared library I am developing with the Boost Regex library. I get the following error: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libboost_regex.a(instances.o): relocation R_X86_64_32 against `boost::object_cache<boost::re_detail::cpp_regex_traits_base<char>, boost::re_detail::cpp_regex_traits_implementation<char> >::do_get(boost::re_detail::cpp_regex_traits_base<char> const&, unsigned long)::s_data' can not be used when making a shared object; recompile with -fPIC I have run across this once before, and although I am not really clear why, it appears that on my AMD64 platform, if I try to link a static library into a shared library, that static library needs to be compiled with -fPIC (this requirement does not exist for normal x86 platforms). My question is: is there an already available option that I can add when compiling the Boost libraries to enable this setting? I am not at all familiar with the BJam build system. Thanks for any assistance! Best, Scott

3 3

binary streams?
by bringiton bringiton 19 Jul '06

19 Jul '06

I'm wondering whether boost has binary streams (or whether the standard library does and i missed it). I had a quick look at boost serialisation. looks like it maybe too involved for my needs. my only needs would be something as follows: outstream s; s << (int)3; s << (float)4.0; s << std::string("hello"); void* data = s.buffer(); int size = s.size(); instream s(data, size); int a << s; float b << s; std::string b << s; I plan on sending the data over TCP. Portability would also be handy (ie endian issues). I may use asio when it is avail in the next boost release. does that support binary streams?

2 1

Re: [Boost-users] [thread] Keeping leak detectors still... - Results
by Daniel Krügler 19 Jul '06

19 Jul '06

Hello, I apologize for the late response to the original thread "Re: [thread] Keeping leak detectors still..." but we had some hard time to bring the boost tests to run and I hope we did that correctly... Furtheron I would like to thank my colleague Rüdiger Dreier for his patience for doing all this testing work. Please note, that the bjam boost tests where performed twice, each one with compiler MSVC 8.00.50727.42 on Windows XP SP2 and the official release of boost 1.33.1. The only difference was that the original file libs/thread/src/tss_hooks.cpp was replaced by the version posted by Peter Dimov on 2006-07-15T18:31 (where the leading and trailing html tags have been removed). All 14 thread-related tests passed the tests for both situations. If anyone is interested in the complete test output (which includes the results of all other libs), please don't resist to ask for them (I didn't want to pollute the news group space without explicit invitation to do that...) Additionally to the boost test, we run a homegrewn, simple threading-mutex-locking test, which also passed successfully for the old and new tss_hooks.cpp version. We could also observe that the standard leak reporter did *not* choke anymore ;-) Greetings from Bremen, Daniel Krügler

1 0

[python], [regex] Segmentation fault when deallocating match_results in a python extension module
by bernhard.maeder＠zkb.ch 19 Jul '06

19 Jul '06

Hello everybody I have a problem in a boost.python module that makes use of the boost.regex library. I'm not sure how much the problem is related to those two libraries or whether I'm just doing something wrong in the build setup. I have the following two python modules: *** test2.cpp *** #include <string> #include<boost/python.hpp> #include<boost/regex.hpp> using namespace boost; using namespace boost::python; void test_func(std::string const & in) { boost::regex expr("^(.*)\\[.*\\]$"); boost::match_results<std::string::const_iterator> match; boost::regex_match(in.begin(), in.end(), match, expr); } BOOST_PYTHON_MODULE(test2) { def("testFunc", &test_func); } *** Build command *** g++-3.4 -Wall -pthread -fPIC -I. -I/usr/include/python2.3 -c -otest2.os test2.cpp g++-3.4 -pthread -shared -o test2.so test2.os -lpython2.3 -lboost_python-gcc-mt-1_33 -lboost_regex-gcc-mt-1_33 *** test.py *** from test2 import * testFunc('justastring') *** output *** >>> from test2 import * >>> testFunc('justastring') Segmentation fault The program aborts when exiting test_func(), during deallocation of match_results. The error occurs somewhere in _M_deallocate of stl_vector.h. Can anybody help me with this problem? What could possibly go wrong here? One thing I noted: python is compiled using GCC3.3 on our system, while we are using GCC3.4, is this a problem? (But, trying the same on a system with GCC 4 for both, python and our app, also fails, so it seems like the problem is to be sought elsewhere). Thanks a lot! Bernhard

2 1

date_time compilation errors on gcc/STLport (time_formatters.hpp)
by Sagnes, Frederic 19 Jul '06

19 Jul '06

<<log.txt>> Hello, I had some troubles compiling my software with the date_time boost library. I attached the build log, I'm using STLport 5.1.0 RC1 (but 5.0.2 has the same troubles), GCC 4.0.1, Boost 1.33.1 and Linux Mandriva 2006.0. It is related to the use of STLport streams by date_time in time_formatters.hpp. It says "ambiguous overload for 'operator<<'". I don't know if it's related to the way I compiled Boost and/or STLport, but this error is generated by the compiler, not the linker. This problem doesn't show up on Visual Studio 2003. Best regards _______________________________________________ Frédéric Sagnes, A&D AS RD DH K3 Siemens AG Karlsruhe

1 0