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

[ASIO] permanently blocked io_service.run()
by Jose Martinez 24 May '08

24 May '08

Hello, I have setup a multithreaded application with multiple io_service objects because I want to pick out the thread that executes a particular event handler. So each thread object will have a copy of their own io_service object. The main server object (who handles accepts) picks which thread executes an event handler. I hope that makes sense. Anyways the main run function of the thread object will have to call io_service.run() so that it can execute the event handlers that the server object sets up for it. My question is how do I keep the thread's io_service.run() from returning right away, since there will be no work for the io_service.run() to do until the server lines up a new connection for the thread to handle? I came up with ways to do this using deadline_timer_service.async_wait(), where the thread calls async_wait() and the event handler for the async_wait() just calls another async_wait(). This should keep work for the io_service.run() to do and permanently blocked but I find this approach quite hackish. But for all I know this could be why deadline_timer_service was created for. Any thoughts on a more elegant way of doing this? thanks jose "survival first, then happiness as we can manage it"

2 1

[interprocess] is mapped_region construction threadsafe?
by Bryan Green 23 May '08

23 May '08

Hi, For a given shared memory object, is construction and use of a mapped_region threadsafe? For example, is the following going to be threadsafe: namespace ipc = boost::interprocess; ipc::file_mapping fmap("file.bin", ipc::read_write); void threadfunc(unsigned idx) { ipc::mapped_region r(fmap, ipc::read_write, idx*1024, 1024); ... } for (unsigned i=0; i<10; ++i) start_thread(boost::bind(threadfunc,i)); --- or, in OpenMP-speak: --- ipc::file_mapping fmap("file.bin", ipc::read_write); int idx; #pragma omp parallel for private(idx) for (idx=0; idx<10; ++idx) { ipc::mapped_region r(fmap, ipc::read_write, idx*1024, 1024); ... } Thanks, -bryan

2 2

design question with using call_traits and functors
by Hansi 23 May '08

23 May '08

Hello, I want to make a functor which uses automatically an reference type if the provided value isn't a pointer. Now I have thougth to use the call_traits library. template<typename Value> struct Setter { typedef void result_type; void operator()(const std::wstring& newVal, Value* pVal) { *pVal = boost::lexical_cast<typename Value>(newVal); } void operator()(const std::wstring& newVal, typename boost::call_traits<Value>::reference refVal) { refVal = boost::lexical_cast<typename Value>(newVal); } }; To call the function I have the following statement: SetValue setter = boost::bind(Setter<short>(),_1,x); Now the only thing that I don't like very much is that the user has to provide the template argument for setter. Is there some possibility to solve it that the template argument is automatically deduced? Important is that I have to possible calls one when the value is provided as value -> I need to have a reference parameter and the other is when a pointer is provided. It would be great if someone can give me a hint. Best regards Hansjörg

2 3

[BGL] and dijkstra_shortest_paths...
by Stefan Walkner 23 May '08

23 May '08

Hello, sorry, I guess this is a noob question but after struggling along with property definitions etc. I cannot find the problem with my code: I simply can not figure out, why my dijkstra_shortest_paths invocation is not correct... I searched around the net but nothing helped me... Thanks in advance for any suggestions! --------------------------------------------------- #include "boost/config.hpp" #include <iostream> #include <fstream> #include "boost/graph/graph_traits.hpp" #include "boost/graph/adjacency_list.hpp" #include "boost/graph/dijkstra_shortest_paths.hpp" using namespace std; using namespace boost; typedef enum { ePositive, eNegative } EdgeDirection_t; struct EdgeProperties { uint8_t level; uint16_t length; uint8_t angle; EdgeDirection_t direction; }; struct VertexProperties { uint32_t index; uint32_t id; uint8_t level; }; // define type for graph types typedef adjacency_list <vecS , listS, directedS, VertexProperties, EdgeProperties> Graph; int main(int argc, char** argv) { Graph graph; property_map<Graph, uint32_t VertexProperties::*>::type vIndex = get(&VertexProperties::index, graph); property_map<Graph, uint32_t VertexProperties::*>::type vId = get(&VertexProperties::id, graph); property_map<Graph, uint8_t VertexProperties::*>::type vLevel = get(&VertexProperties::level, graph); typedef graph_traits<Graph>::vertex_descriptor Vertex; Vertex v1, v2; v1 = add_vertex(graph); vIndex[v1] = 0; vId[v1] = 1; vLevel[v1] = 1; v2 = add_vertex(graph); vIndex[v2] = 1; vId[v2] = 2; vLevel[v2] = 1; EdgeProperties e1; e1.level = 10; e1.length = 2000; e1.angle = 90; e1.direction = ePositive; add_edge(v1, v2, e1, graph); typedef graph_traits<Graph>::vertex_descriptor VertexDescriptor; std::vector<VertexDescriptor> p(num_vertices(graph)); std::vector<int> d(num_vertices(graph)); // BOTH lines to not work ;( // and I have no clue why... //dijkstra_shortest_paths(graph, v1, predecessor_map(&p[0]).distance_map(&d[0])); dijkstra_shortest_paths(graph, v1, vertex_index_map(vIndex). predecessor_map(&p[0]). weight_map(get(&EdgeProperties::length, graph)). distance_map(&d[0]) ); exit(EXIT_SUCCESS); }

2 2

[thread] thread_specific_ptr with NULL/empty cleanup_function - messy
by Bryan Green 23 May '08

23 May '08

Hi, I have been converting some of my pthread-code to boost::thread, and I commonly use thread-specific storage to store a pointer that is not intended to be deleted when the thread exits (the default action for thread_specific_ptr). In pthreads, specifying NULL as the cleanup_function accomplishes what I want, i.e. no cleanup is done. In boost::thread, specifying NULL will crash my program, because the implementation does not test for a null cleanup_function before invoking it. Since the cleanup function for thread_specific_ptr<T> takes an argument of type T*, this means that whereever I use thread_specific_ptr in this way, I have to define an empty function taking T*, to pass as the cleanup function. It seems pretty messy and wasteful to me, when all that is needed is a (cleanup_function != 0) test in the implementation. Is there a rationale for boost::thread not supporting a NULL cleanup_function pointer? Thanks, -bryan

1 0

Struggling with Solaris build
by Sean Johnston 23 May '08

23 May '08

I'm struggling to get Boost built on a Solaris box here. Initially I was stuck on compilation errors due to v8plus issues. After some googling and trial and error I worked out what to put in user-config.jam to fix that. However, I'm now struggling with the following error: ... wrong ELF class: ELFCLASS64 I'm using gcc-3.2 and the Sun linker, trying to build a 64bit version of just the program_options and regex libraries. Here's what I've got for the user-config.jam: using gcc : : : <address-model>64 <linker-type>"sun" <compileflags>"-m64" <linkflags>"-Wl,64" <instruction-set>"v9" ; I'm basically flummoxed at this point, and my google-fu is failing to find me a solution. All the object files are 64bit so I don't know why it is complaining as it should be doing the link as 64bit. Sean. -- It's a conical sort of effort

2 3

[1.36.0] Release schedule set
by Beman Dawes 23 May '08

23 May '08

The 1.36.0 release schedule has been set. For details, see http://svn.boost.org/trac/boost/wiki/ReleaseSchedule The milestones are: *Note well: Changes must always be committed to trunk and be stable on trunk regression testing before being merged to branches/release.* * *May, 2008:* branches/release opens for all stable changes, including bug fixes, major library upgrades, and, with permission, new libraries. Breaking changes should be coordinated with libraries affected. * *June 19, 2008:* branches/release closes for new libraries and major upgrades or breaking changes to existing libraries. Still open for bug fixes and minor changes to all libraries. * *July 3, 2008:* branches/release closes for routine minor changes and fixes. Still open for serious problem fixes. * *July 10, 2008:* branches/release closes for all library changes except when specific permission given by release manager(s). * *July 17, 2008 (sooner if possible):* Beta 1 target date. Further betas and/or release candidates as feedback dictates. * *July 31, 2008:* Release ship date. --Beman

1 0

Boost 1.35 weak_ptr::lock
by Clarke, Aaron 23 May '08

23 May '08

Hello, I'm trying to update my codes Boost from 1.34.1 to 1.35 and I'm getting a test case failure dealing with weak_ptr. I have an std::vector of weak_ptr's and I've verified that the weak_ptr that get put in are valid. Then later I look through the whole vector and lock the weak_ptr's to call a virtual method on them. The weak_ptr says it's (!expired) and the (shared_ptr == true). But the vtable is all messed up and the shared_ptr's px is not a pointer to something I made the weak_ptr from. Soo... is there any idea about why the weak_ptr from 1.35 would do this when the weak_ptr from 1.34.1 works fine? The headers look remarkably the same so I have no idea. Thanks, Aaron

2 2

boost unit test how to disable memory leak check
by Selçuk Giray Özdamar 23 May '08

23 May '08

// my_test.cpp BOOST_AUTO_TEST_SUITE( my_test_suite_01 ) struct F { F() { BOOST_TEST_MESSAGE( "setup fixture my_test_suite_01" ); } ~F(){ BOOST_TEST_MESSAGE( "teardown fixture my_test_suite_01" ); } }; BOOST_FIXTURE_TEST_CASE( my_test_01, F ) { Data d(); BOOST_CHECK( d.isNew() ); BOOST_CHECK_EQUAL(d.value(), 0.0f); } BOOST_AUTO_TEST_SUITE_END() // Main.cpp #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> While running unit tests (boost unit test) I'm also getting memory leak results. Is there any way to disable memory leak test. I only want to see the unit test results. Running 11 test cases... *** No errors detected Detected memory leaks! Dumping objects -> .....

2 1

boost::python::import
by Degraeve, Frederic 23 May '08

23 May '08

Hello, I tried this code with vs7-8 and boost1.34.1-1.35.0 and my python is a 2.4. The call to Cpython works well but boost::python doesn't work. I've got an exception about an access violation reading location 0x00000000. help, please? thank you. Frédéric #include "stdafx.h" #include <boost/python.hpp> #include <iostream> #include <stdexcept> #include <cassert> using namespace boost::python; int _tmain(int argc, _TCHAR* argv[]) { Py_Initialize(); PyObject* pSys = PyImport_ImportModule("sys"); // works boost::python::object sys = boost::python::import("sys"); // doesnt work return 0; } This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this message, or any attachment, that have arisen as a result of e-mail transmission. If verification is required, please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.

1 0