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

Interrupting Threads with boost::thread::interrupt()
by Matthias Vallentin 18 Jun '08

18 Jun '08

Hi folks, I am having issues with boost::thread::interrupt(). As far as I understood, calling this function will throw an exception in the corresponding thread. How can deal with blocking functions, such as a calls to accept() or when a thread is waiting on a condition variable to change? Basically the thread blocks somewhere in a while (true) loop. Injecting interruption points manually with boost::this_thread::interruption_point() does not seem to help here either. boost::thread::interrupt() (or interrupt_all in a thread_group), simply does not return. Regards, Matthias -- Matthias Vallentin vallentin(a)icsi.berkeley.edu pgp/gpg: 0x37F34C16

4 4

[ASIO] when does basic_datagram::async_read() call the handler?
by Jose Martinez 18 Jun '08

18 Jun '08

Hello, For the function basic_datagram::async_read() the asio documentation states: "The handler to be called when the receive operation completes." Does that occur when a UDP datagram is received in full or the buffer has filled? I'm just concerned that it might insert into the buffer more than one UDP datagram before calling the handler or a non-complete UDP datagram. I wanted to use the async_read_until but it states that its for streams, which makes sense if the basic_datagram::async_read function returns on a per complete datagram basis. I'm also assuming large UDP datagrams (that take up multiple packets) will be collected by the transport layer before being presented to the application layer (though this is not so much an Asio question as it is a Linux network stack question). thanks a lot! jose "survival first, then happiness as we can manage it"

1 0

please help
by Meththa 17 Jun '08

17 Jun '08

Hi, I've been using the BGL library with Visual C++ to implement the Kamada_Kawai algorithm and have had no errors. I moved this code to g++ and I've had many errors and particularly one that I do not know how to solve. I have a seperate header file that plots the graph as shown below. #include ...<boost/graph/graph_traits.hpp> template<typenameGraph, typenamePositionMap>void... I receive the following error to the location where I typdef the graph_traits. plot.hpp expected initializer before '<' token KK_Algorithm line 26 does anyone know what I need to do to correct this problem. As I mentioned earlier - this worked perfectly with Visual C++. All suggestions are welcome. Thank you.typedefgraph_traits<Graph>::vertex_iterator vi, vi_end;plot(Graph& g, PositionMapposition, std::stringgraph_name) {

3 2

[Graph] Polymorphic properties
by Renaud Detry 17 Jun '08

17 Jun '08

Hi, I have a question related to Boost.Graph bundle properties when there are two distinct vertex/edge types. I would like to implement a network structure using Boost.Graph. In this structure, edges and vertices can be of two types. A vertex can be either of type VA or of type VB, and and edge can be of type EA or EB. The data element to which a vertex/edge is associated differs depending on the vertex/edge type. I will be using the adjacency_list and bundle properties adjacency_list<OutEdgeList, VertexList, Directed, VertexProperties, EdgeProperties, GraphProperties, EdgeList> I'm trying to figure what to use for VertexProperties and EdgesProperties, focusing on maintainability and flexibility. Also, I would like the whole structure to be serializable. This seems like a rather generic problem, yet I wasn't able to find an easy and elegant solution. Here are some ideas for VertexProperties (the same scheme can directly be used for EdgeProperties). 1a.- VertexProperties is set to boost::shared_ptr<VirtualVertexProp>, where VirtualVertexProp is a polymorphic class from which classes specific to types VA or VB can inherit. This approach has some issues though: for example, graph copies have to explicitly handle property clonage. 1b.- Instead of boost::shared_ptr, boost::ptr_array<VirtualVertexProp,1> could be used. The property instances are cloned when the ptr_array is copied. 2.- VertexProperties is a simple class that contains a type enum (VA or VB), and an index that identifies a data element in an external container. There would be two external containers, one containing VA data, the other for VB data. The advantage of (1b) is automatic memory management -- when a vertex is deleted, its properties also die. With (2), properties have to be manually deleted when an vertex is removed. On the other hand, (2) is a bit more simple to serialize, since there's no dynamic allocation (i.e. not on the user side) and no polymorphism (no BOOST_CLASS_EXPORT_GUID...). My questions are: - In (1b), will boost::ptr_array<VirtualVertexProp,1> provide the expected behavior, i.e. that of a clone_ptr? - Am I missing something? Is there a more natural way to solve this problem? Thanks a lot, Renaud.

2 1

Re: [Boost-users] [Spirit-general] Compile errors with Phoenix closures
by Martin Apel 17 Jun '08

17 Jun '08

Joel de Guzman wrote: > Martin Apel wrote: > > >> boost/spirit/phoenix/closures.hpp closure<..>::context() is declared to >> return a reference to a closure_frame_t, which is a closure_frame<self_t>. >> The implementation consists of frame.get(), which invokes the get method >> on holder_t, which is a closure_frame_holder<closure_frame_t>. When >> looking at the get method of closure_frame_holder, it >> returns a reference to frame_ptr, which is a frame_t*, which is not the >> same as an object of type closure_frame<self_t> as declared by >> closure<...>::context() >> > > :-) I think you missed the #ifdef PHOENIX_THREADSAFE branch. > > I don't think so. See the following small test function, which does not do anything sensible, but from my understanding it should at least compile: void test(void) { closure<int> c; closure<int>::closure_frame_t& frame = c.context(); } But it doesn't compile, even with gcc. The error is either (without NDEBUG defined): /scratch/apel/boost_install/linux32/include/boost-1_35/boost/spirit/phoenix/closures.hpp: In member function 'phoenix::closure_frame<phoenix::closure<T0, T1, T2> >& phoenix::closure<T0, T1, T2>::context() [with T0 = int, T1 = phoenix::nil_t, T2 = phoenix::nil_t]': test2.cpp:9: instantiated from here /scratch/apel/boost_install/linux32/include/boost-1_35/boost/spirit/phoenix/closures.hpp:352: error: no match for 'operator!=' in '((phoenix::closure<int, phoenix::nil_t, phoenix::nil_t>*)this)->phoenix::closure<int, phoenix::nil_t, phoenix::nil_t>::frame != 0' test2.cpp:9: instantiated from here /scratch/apel/boost_install/linux32/include/boost-1_35/boost/spirit/phoenix/closures.hpp:352: error: invalid initialization of reference of type 'phoenix::closure_frame<phoenix::closure<int, phoenix::nil_t, phoenix::nil_t> >&' from expression of type 'phoenix::closure_frame<phoenix::closure<int, phoenix::nil_t, phoenix::nil_t> >*' or (with NDEBUG defined): /scratch/apel/boost_install/linux32/include/boost-1_35/boost/spirit/phoenix/closures.hpp: In member function 'phoenix::closure_frame<phoenix::closure<T0, T1, T2> >& phoenix::closure<T0, T1, T2>::context() [with T0 = int, T1 = phoenix::nil_t, T2 = phoenix::nil_t]': test2.cpp:9: instantiated from here /scratch/apel/boost_install/linux32/include/boost-1_35/boost/spirit/phoenix/closures.hpp:352: error: invalid initialization of reference of type 'phoenix::closure_frame<phoenix::closure<int, phoenix::nil_t, phoenix::nil_t> >&' from expression of type 'phoenix::closure_frame<phoenix::closure<int, phoenix::nil_t, phoenix::nil_t> >*' Can you reproduce this? >> Sorry, it wasn't meant as an accusation. >> > > Nah, just kidding. That's why there was a smiley there ;-) > > I had found this out some > >> months ago, so I tried to give an example from my memory. I didn't >> expect Spirit to behave exactly as iostream, because there was no >> specification with respect to numerical accuracy. Additionally I only >> found this out, when setting the precision to 20, 15 is not enough. I >> played around a bit, to find an example: >> > > I'd appreciate it if you can add a bug report to Boost's trac. > Let's see if we can do better. Thanks for reporting this! > > I added a bug report to Trac. It's got the number 2014. Regards, Martin

1 0

Re: [Boost-users] [Spirit-general] Compile errors with Phoenix closures
by Martin Apel 17 Jun '08

17 Jun '08

Joel de Guzman wrote: > Martin Apel wrote: > >> Hi all, >> >> I posted this issue a week ago to the Spirit mailing list only, but I >> got no reply. So I repost this onto the Boost mailing list as well: >> >> I tried to compile a Spirit grammar parsing a real number using closures >> under Microsoft Visual C++ 2005. The same grammar compiles fine on Linux >> using GCC 4.x. Boost version is 1.35.0 in both cases. As far as I >> understood, the error is caused by an assertion inside the closure class >> template: >> closure_frame_t& context() { assert(frame!=0); return >> frame.get(); } (line 352 of >> boost/spirit/phoenix/closures.hpp) >> >> Even if I define NDEBUG, Phoenix closures don't compile, because the >> return statement after the assertion returns a pointer to a >> closure_frame_t and not a reference. From my point of view, this is not >> really a compiler issue, but a bug in the header file >> boost/spirit/phoenix/closures.hpp. I do not understand, why GCC compiles >> this without any errors, because I think the code should not compile at all. >> Any help would be appreciated. >> > > Please post a minimal cpp file that exhibits the problem. > Please try to make it as minimal as possible so as to > focus on the problem. At any rate, have you read the > FAQ: > > http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/doc/faq.html… > > Regards, > Hi all, the mentioned FAQ entry is about an assertion triggered at runtime, but I don't even come that far, because the problem happens at compile time. While trying to generate a small example, I found out, what is causing the problem: I marked the grammar class using the closure with __declspec(dllexport), which causes MSVC to instantiate all members of a template, even if they are never needed. It seems that otherwise the "context" member function is never instantiated. If you remove the __declspec(dllexport), everything compiles. I still think, that the code is wrong, because it returns a pointer, where it should return a reference. I have attached a small example, which triggers the problem. By the way, the example implements a real parser, which uses the standard C++ runtime to convert the real number into a double. I had to implement this, because I found out, that the Spirit real_p parser creates numerically different results from the standard runtime, i.e. parsing the string "1.8" delivers a number like 1.8000000532 using Spirit, while the C++ runtime delivers something like 1.7999999973, which is always closer to the real value. Please note, that these numbers are not accurate, they are simply meant to demonstrate, what I mean. Regards, Martin

2 2

Intel TBB & BOOST
by dhruva 17 Jun '08

17 Jun '08

Hi, Just a random thought. Has anyone considered making INTEL TBB part of BOOST? Since I am juggling between the two, I feel they could be under one single umbrella. -dhruva PS: Any TBB users/developers, please comment. -- Contents reflect my personal views only!

3 4

[bind] using NULL as a bound argument
by Marc Horowitz 16 Jun '08

16 Jun '08

I am attempting to use Boost.Bind to create a callable where some of the bound arguments might be NULL. Here is a simple example: void f(const char *) {} int main() { (std::tr1::bind(f, _1))(NULL); return(0); } msvc complains: c:\Program Files\boost\boost_1_35_0\boost/bind.hpp(232) : error C2664: 'void (const char *)' : cannot convert parameter 1 from 'const int' to 'const char *' Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast c:\Program Files\boost\boost_1_35_0\boost/bind/bind_template.hpp(47) : see reference to function template instantiation 'void boost::_bi::list1<A1>::operator ()<void(__cdecl *)(const char *),boost::_bi::list1<const int &>>(boost::_bi::type<T>,F &,A &,int)' being compiled with [ A1=boost::arg<1>, T=void, F=void (__cdecl *)(const char *), A=boost::_bi::list1<const int &> ] foo.cc(20) : see reference to function template instantiation 'void boost::_bi::bind_t<R,F,L>::operator ()<int>(const A1 &)' being compiled with [ R=void, F=void (__cdecl *)(const char *), L=boost::_bi::list1<boost::arg<1>>, A1=int ] g++ complains similarly: /usr/local/boost_1_35_0/boost/bind.hpp: In member function `void boost::_bi::list1<A1>::operator()(boost::_bi::type<void>, F&, A&, int) [with F = void (*)(const char*), A = boost::_bi::list1<const int&>, A1 = boost::arg<1> (*)()]': /usr/local/boost_1_35_0/boost/bind/bind_template.hpp:47: instantiated from `typename boost::_bi::result_traits<R, F>::type boost::_bi::bind_t<R, F, L>::operator()(const A1&) [with A1 = int, R = void, F = void (*)(const char*), L = boost::_bi::list1<boost::arg<1> (*)()>]' foo.cc:20: instantiated from here /usr/local/boost_1_35_0/boost/bind.hpp:232: error: invalid conversion from `const int' to `const char*' Of course, f(NULL) works just fine. The problem seems to be that NULL expands to 0. As a literal constant, this is assignable to any pointer, but once all the template stuff happens, you end up with an expression with integer type, and that's different. Similarly (and more predictably), this fails, too: int z = 0; f(z); I have a workaround, which is to replace the constant NULL with an expression which is assignable to any pointer type. Fortunately, this is easy in C++: class NullPlaceholder { public: template <class T> operator T*() const { return((T*)NULL); } }; NullPlaceholder _NULL; Now, I can write (std::tr1::bind(f, _1))(_NULL); and the compiler is happy. Is there a better workaround for this problem? It seems like wanting to use NULL as a constant would be a pretty common case. Ideally, bind would be fixed so that NULL works, but I'm not sure how to do that without loosening the type checking for all int->pointer conversions. (I played around with trying to use specialization to add some scaffolding so that the A{1,2,3,...} template types for an int 0 literal would actually use a NullPlaceholder, but I didn't get very far, and while this would work for the compilers I use, it would not be formally portable.) A documentation note, at least, would have helped me figure out what was going wrong. Providing _NULL as a "placeholder" in the library would be the next best thing to having NULL work as is. I'm not sure if there are any other common expressions in C++ which will run into similar issues. Integer and string literal constants work just fine, but I may be missing some more subtle case. Marc P.S. It occurs to me that replacing the runtime's NULL with a macro which expanded to a constant of type NullPlaceholder should work perfectly (and does in my tests). Any use of NULL in an expression would dtrt, and optimize to the use of a constant. But overriding the runtime like this just feels sketchy.

4 8

[python] external constructors
by Gennadiy Rozental 16 Jun '08

16 Jun '08

Hi, is there any way to register external constructor for C++ class? Specifically If I have class class A { ... }; I want to register constructor like this: class_<A>(...) .def( "__init__", &make_A ) where make_A is defined something like: void make_A( A&, boost::python::list const& ); Doesn't seem to work like this. Gennadiy

1 0

[Boost.Test] Problem with vc9 runtime library
by Greg Ravikovich 16 Jun '08

16 Jun '08

Hello all. I have the following program: -------------------------- #define BOOST_TEST_MODULE Test #include <boost/test/unit_test.hpp> #include <boost/test/test_case_template.hpp> #include <boost/mpl/list.hpp> typedef boost::mpl::list<float,double> Types; BOOST_AUTO_TEST_CASE_TEMPLATE( my_test, T, Types ) { } -------------------------- The program compiles and links successfully. However, when compiled with Multithreaded Debug Dll runtime library (/MDd) The program reports: Running 2 test cases... *** No errors detected But when compiled with Mulithreaded Debug runtime library (/MTD) The program reports: Running 2 test cases... *** No errors detected Detected memory leaks! Dumping objects -> {94} normal block at 0x00342ED8, 7 bytes long. Data: <double > 64 6F 75 62 6C 65 00 {93} normal block at 0x00342EA0, 8 bytes long. Data: < .4 )4 > D8 2E 34 00 B0 29 34 00 {84} normal block at 0x003429E8, 6 bytes long. Data: <float > 66 6C 6F 61 74 00 {83} normal block at 0x003429B0, 8 bytes long. Data: < )4 > E8 29 34 00 00 00 00 00 Object dump complete. What could cause this? Any suggestions? Greg

4 7