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

Re: [Boost-users] threads in a DLL with callbacks
by Nicholas Cain 03 Oct '08

03 Oct '08

Hi, can I make another plea for any answers to my question (below). It may be that the answer is so obviously 'of course it does' that I didn't get a response. I did think about posting to the threads.devel list, but it didn't look like the right place... Nik ----- Original Message ----- From: "Nicholas Cain" <ncain(a)frontier.co.uk> To: <boost-users(a)lists.boost.org> Sent: Thursday, September 25, 2008 10:55 AM Subject: threads in a DLL with callbacks > Hi, > > I've created a component that's distributed as a DLL. The user loads the > DLL, calls various methods on it and gets some data back asyncronously via > callbacks. > > Within the component there are several threads (using boost threads of > course) any of which might call the callbacks. In all our sample code > demonstrating how to create callbacks and call the methods we use boost > mutexes to protect the callback functions and this works just fine. > > > Some of our clients however don't want to dip their toes into boost, and > want to use windows methods to protect the callbacks. For instance so far > they've tried various methods such as CComAutoCriticalSection and > EnterCriticalSection. > > They still have a crash which they're attributing to my DLL. I keep > pushing them to at least try the boost mutex as in our sample code, but no > luck so far. > > > My question is; should the windows critical section protect the callbacks > just as well as the boost mutexes, or does it require a boost mutex > protection? (or do you require a code example to know the answer to this?) > > > Nik > > >

3 3

Re: [Boost-users] [Graph] Issue with is_straight_line_drawing?
by Gevorg Voskanyan 03 Oct '08

03 Oct '08

David Gleich wrote: > Hi, > > I'm concerned about the output I'm getting from the > is_straight_line_drawing function in the Boost Graph library. My > understanding was that it should report true when the graph and > positions are a planar embedding (no edge crossings). > > Based on this understanding, I thought the code listed at the end of > the message should say that the drawing for a clique on 4 vertices, > with positions on a square, is not planar (see the picture below). > This arrangement has one edge crossing. The function outputs that the > graph is a plane drawing. > > Did I misunderstand what the is_straight_line_drawing function is > supposed to do? > > Thanks, > David Gleich > > #include > #include > #include > #include > #include > #include > > #include > > using namespace boost; > > //a class to hold the coordinates of the straight line embedding > struct coord_t { > std::size_t x; > std::size_t y; > }; > > int main(int argc, char** argv) { > typedef adjacency_list > < vecS, vecS, undirectedS, property> graph; > > graph g(4); // make the clique on 4 vertices > add_edge(0,1,g); add_edge(0,2,g); add_edge(0,3,g); > add_edge(1,2,g); add_edge(1,3,g); add_edge(2,3,g); > > //Set up a property map to hold the mapping from vertices to coord_t's > typedef std::vector< coord_t > straight_line_drawing_storage_t; > typedef boost::iterator_property_map > < straight_line_drawing_storage_t::iterator, > property_map::type > > > straight_line_drawing_t; > > > straight_line_drawing_storage_t straight_line_drawing_storage > (num_vertices(g)); > straight_line_drawing_t straight_line_drawing > (straight_line_drawing_storage.begin(), > get(vertex_index,g) > ); > /* > should be > 0 > / | \ > 3--|--1 > \ | / > 2 > which is not a plane drawing. > */ > straight_line_drawing[0].x = 1; straight_line_drawing[0].y = 2; > straight_line_drawing[1].x = 2; straight_line_drawing[1].y = 1; > straight_line_drawing[2].x = 1; straight_line_drawing[2].y = 0; > straight_line_drawing[3].x = 0; straight_line_drawing[3].y = 1; > > if (is_straight_line_drawing(g, straight_line_drawing)) > std::cout << "Is a plane drawing." << std::endl; > else > std::cout << "Is not a plane drawing." << std::endl; > > return 0; > } > > > /* Compiling and example > $ g++ -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v > --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 > --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc > --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) > > $g++ is_straight_line_drawing.cpp -I/home/dgleich/dev/lib/boost_1_36_0/ > $./a.out > Is a plane drawing. > > Should be > > Is not a plane drawing. > */ Hi David, is_straight_line_drawing() is actually correct here because your test graph can be drawn in a way that has no edge crossing. Consider for example this one: 3 --- 1 \ \ / / \ 0 / \ | / \|/ 2 Sorry for my perhaps clumsy ASCII drawing, but you get the idea. Hope this helps, Gevorg

1 0

[Proto] Limiting function arity in grammar
by Joel Falcou 02 Oct '08

02 Oct '08

How can I write a grammar that accept a given set of terminal and functions with up to N arguments (for example accepting function with 1 to 5 arguments but not 6 or more) ? I believe i can count the elements of vararg using mpl::size ons ome proto::arg_ or proto::value maybe but how to prevent those who violates this condition be removed from the accepted functions et ? thanks in advance -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 3

compiler warnings with visual studio 2008
by gfsdjkgf＠Safe-mail.net 02 Oct '08

02 Oct '08

Hello folks I am using boost 1.37 off the CVS with the visual studio 2008 compiler. As soon as I compile my code files with the /W4 option (maximum compiler warning level), I get tons of warnings inside the boost header. Disabling them all using #pragma's can be a pain in the ass. Is there any other, better solution to get rid of the warnings? Thank you

1 0

[bind] How to dereference _1 in a boost::bind expression
by Peter Barker 02 Oct '08

02 Oct '08

Hello, Here's an example of my problem: #include <algorithm> #include <vector> #include <boost/bind.hpp> class TheClass { }; void accept(TheClass& tc) { } int main() { std::vector<TheClass*> cont; // Compile error - how to dereference _1 ??? std::for_each(cont.begin(),cont.end(),boost::bind(&accept,_1)); } How can I dereference _1 so I can use the accept function? Regards, Pete

6 11

serialization x64 abi_prefix/suffix problem
by Terdale, Shantibhushan 02 Oct '08

02 Oct '08

I am getting these errors while building one of my projects where boost serialization headers are included 1>..\..\..\ThirdParty\Boost\boost/config/abi_prefix.hpp(19) : error C2220: warning treated as error - no 'object' file generated 1>..\..\..\ThirdParty\Boost\boost/config/abi_prefix.hpp(19) : warning C4103: 'x:\thirdparty\boost\boost\config\abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 1>..\..\..\ThirdParty\Boost\boost/serialization/extended_type_info.hpp(2 7) : warning C4103: 'x:\thirdparty\boost\boost\serialization\extended_type_info.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 1>..\..\..\ThirdParty\Boost\boost/config/abi_suffix.hpp(20) : warning C4103: 'x:\thirdparty\boost\boost\config\abi_suffix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 1>..\..\..\ThirdParty\Boost\boost/serialization/extended_type_info.hpp(9 5) : warning C4103: 'x:\thirdparty\boost\boost\serialization\extended_type_info.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 1>..\..\..\ThirdParty\Boost\boost/config/abi_prefix.hpp(19) : warning C4103: 'x:\thirdparty\boost\boost\config\abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 1>..\..\..\ThirdParty\Boost\boost/serialization/extended_type_info_typei d.hpp(35) : warning C4103: 'x:\thirdparty\boost\boost\serialization\extended_type_info_typeid.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 1>..\..\..\ThirdParty\Boost\boost/config/abi_suffix.hpp(20) : warning C4103: 'x:\thirdparty\boost\boost\config\abi_suffix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 1>..\..\..\ThirdParty\Boost\boost/serialization/extended_type_info_typei d.hpp(143) : warning C4103: 'x:\thirdparty\boost\boost\serialization\extended_type_info_typeid.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) I saw discussion on this before and am wondering what is the solution? It only emits these warnings for x64 build and why not for x86 ? It only emits these warnings for one perticular project in my soluton whereas these headers are included in many projects. why? Thanks Shanti

1 0

[mp_math_v02] Typo in integral_ops.hpp?
by Mikko Vainio 02 Oct '08

02 Oct '08

Hi, A couple of problems encountered with mp_math_v02 from the Vault: - Should line 315 of mp_math/mp_int/detail/integral_ops.hpp read "lhs.multiply_by_digit(static_cast<typename MpInt::digit_type>(rhs));" instead of "lhs.mul_digit(static_cast<typename MpInt::digit_type>(rhs));" ? "mul_digit" seems not to be defined. - prime_tab_impl::values gets defined multiple times, because the assignment is in the header. You could use a singleton class and e.g. Eratosthenes' sieve to fill the array with primes. That should stay header-only. Rgds, Mikko

1 0

Simple regex does not match
by Jean-Pierre Bergamin 02 Oct '08

02 Oct '08

Hello everyone Why does the following regex not match? boost::regex expected("foo"); BOOST_CHECK(boost::regex_match("foo bar", expected)); Is there a flag I should set so that this regex matches? In perl, there would be a match in this case. if ("foo bar" =~ /foo/) { ... } Thanks for your hints. James

2 1

[mp_math] Serialization of mp_int<> ?
by Mikko Vainio 02 Oct '08

02 Oct '08

Hi, Does anyone know if serialization is implemented for the mp_int class from the mp_math library in the vault? Regards, Mikko

1 0

type_info wrapper
by Peter Barker 01 Oct '08

01 Oct '08

Hello, I'm looking for a type_info wrapper similar to the one described in Alexandrescu's Modern C++ design and wondered if Boost contained one that wasn't in the implementation detail area of another library? My Googling shows there's been a demand for this in the past and wonder if it had been done? Regards, Pete

3 3