- Boost-users - lists.boost.org

PB with Regex Syntax in boost::regex 1.38 cause crash with memory exhausted .
by coord.admin 13 May '09

13 May '09

Hi , i'm using boost::regex 1.38 and C++ to code a textfile parsor . My code work correctly with most regular expression but i've got one problem with this expression: ^([^\s]+)\s+\d+\s+(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s+\w+\/(\d+)\s+\d+\s+(\w+)\s+(\w+)\:\/\/?([^\:\/\?\s]+):?(\d*)(\S*).+Referer:(.+)\\r.*$ and a file with these lines : 1237084031.249 985 10.0.0.1 TCP_MISS/200 37567 GET http://monsite.information.com/index.mas?epl=00960031UlsNZ0sAVVETVRBeHgsJRz… - ROUNDROBIN_PARENT/10.10.10.10 text/html [Connection: Close\r\nCache-Control: no-cache,no-store\r\nPragma: No-Cache\r\nAccept: */*\r\nHost: monsite.information.com\r\nUser-Agent: XXXX/X.X (Update: XXXX X.X; UNIX)\r\nProxy-Connection: Keep-Alive\r\n] [HTTP/1.1 200 OK\r\nDate: Sun, 15 Mar 2009 02:27:10 GMT\r\nServer: Oversee Webserver v1.3.18\r\nSet-Cookie: ident=click:0%257csearch:0%257cexitpop:0%257ctoken:vqzyyyprxutxyvqs%257clload:0%257clvisit:1237084030; path=/; expires=Mon, 16-Mar-2009 02:27:10 GMT\r\nSet-Cookie: monsite.com=click:0%257csearch:0%257cexitpop:0%257clload:0%257clvisit:1237084030; path=/; expires=Mon, 16-Mar-2009 02:27:10 GMT\r\nSet-Cookie: Spusr=ac15000c6b3f49bc677e9c0b; path=/; expires=Tue, 15-Mar-11 02:27:10 GMT\r\nCache-control: private, no-cache, must-revalidate\r\nExpires: Mon, 26 Jul 1997 05:00:00 GMT\r\nPragma: no-cache\r\nP3P: policyref="http://monsite.information.com/w3c/p3p.xml", CP="NOI DSP COR ADMa OUR NOR STA"\r\nConnection: close\r\nContent-Type: text/html\r\n\r] I've got this error message : terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what(): Memory exhausted Abandon The problem is probably here : (\d*)(\S*).+Referer:(.+) because when i delete this part it work correctly. I try this expression and this file with a perl script and it work correctly , but with boost not . Can you help me ?

2 1

[conversion] lexical_cast<> compilation with --pedantic-errors
by Evgeny Tarasov 13 May '09

13 May '09

If to compile program with the key --pedantic-errors there exist some error messages. Otherwise everything is ok. #include <boost/lexical_cast.hpp> //line 38 In file included from /usr/local/include/boost-1_39/boost/detail/lcast_precision.hpp:16, from /usr/local/include/boost-1_39/boost/lexical_cast.hpp:31, from accepterimpl.cpp:38: /usr/local/include/boost-1_39/boost/integer_traits.hpp:164:66: use of C99 long long integer constant /usr/local/include/boost-1_39/boost/integer_traits.hpp:164:77: use of C99 long long integer constant /usr/local/include/boost-1_39/boost/integer_traits.hpp:170:70: use of C99 long long integer constant /usr/local/include/boost-1_39/boost/integer_traits.hpp:170:70: use of C99 long long integer constant make[2]: *** [accepterimpl.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Are there any means to overcome it ?

1 0

[BGL]Why the output of algorithms are vertex sequence(PredecessorMap)? How about parallel edges??
by Li Ning 13 May '09

13 May '09

For example, a graph has 2 nodes: A & B. There are 2 edges form A to B which are edge1 & edge2. edge1 has weight 1, edge2 has weight 2. Then the shortest path form A to B is: vertex A---edge1---vertex B. But the default output of all algorithm is vertex sequence. Why? How to get the edge sequence?? I have noticed vistor.hpp has a class edge_predecessor_recorder, but I don't know how to use it. Anybody give me a hint? -- View this message in context: http://www.nabble.com/-BGL-Why-the-output-of-algorithms-are-vertex-sequence… Sent from the Boost - Users mailing list archive at Nabble.com.

4 12

[Asio] Cancel an async timer from another timer's handler
by Laurent Fert 13 May '09

13 May '09

Hi, I faced some strange behavior while using timers (boost_1_38_0/boost_1_39_0). Here is an easy way to reproduce such behavior (note: I use async timeouts and a single thread): =experiment 1= Timer1 expires after 2 seconds and reschedules itself to fire again 2 seconds later. Timer2 expires after 2 seconds and cancels Timer1. Result: Timer2's handler gets called but the cancel call on Timer1 returns 0. Timer1's handler gets called (although it should have been cancelled) and therefore, Timer1 repeats itself indefinitely. =experiment 2= Timer1 expires after 1995 milliseconds and primes itself to fire again 1995 milliseconds later. Timer2 expires after 2 seconds and cancels Timer1. Result: Timer1's handler gets called and reschedules itself. Timer2's handler gets called and Timer1 gets canceled properly. =experiment 3= Timer1 expires after 2005 milliseconds and primes itself to fire again 2005 milliseconds later. Timer2 expires after 2 seconds and cancels Timer1. Result: Timer2's handler gets called and Timer1 gets canceled properly. =experiment 4= Repeat experiment 1 but change the expiration time of Timer1 instead of canceling it from Timer2's handler. Result: Timer2's handler gets called and Timer1 gets rescheduled properly. Note that Timer1's handler doesn't get called at all before the new expiry time although it should be called with an operation_aborted error code. =summary= When Timer1 and Timer2 expire at a very close time, Timer2 cannot cancel Timer1 although it can reschedule it. Is it an expected behavior? Is it due to the design of Asio? Regards, Laurent

1 0

[boost-users][signals2] thread-safe disconnection for intrusively ref-counted objects
by Igor R 13 May '09

13 May '09

Hello, Is there any trick or customization that would allow the subj? I mean the following situation: // pseudo-code! class intrusively_refcounted : //... { private: void listenToAsyncSubsystem() { // signals will come from another thread asyncSubsystem_.someEvent.connect(slot_type(&intrusively_refcounted::handler, this).track(???)); // can't use here shared_ptr/weak_ptr for tracking } }; I could store a connection object, so that it would be destroyed/disconnected in ~intrusively_refcounted(), but I guess it's not thread-safe, just like the approach with "trackable". So what would be the correct approach? Thanks!

2 2

How to reduce the size of a output DLL file?
by ipangth 13 May '09

13 May '09

I used to build a DLL file with VS2005 & boost-1_33, the project used boost::thread, asio, serialization, filesystem, datetime,system, link static, /MT, and the output DLL file size is about 1.7M. Now I port the project to VS2008 SP1 with boost-1_36, but the output file size increase to 2.9M! The VS2008 DLL project just default setting. I do not know whether this problem is boost-1_36 OR vs2008. Can some one give me some tips for how to reduce the DLL out put file size? -- Best regards, aster

2 1

[Boost.Test]
by Ruediger Berlich 13 May '09

13 May '09

Hi there, I am using Boost.Test to run Unit tests for my code (Boost 1.39). For each class, I have a number of tests (implemented through BOOST_AUTO_TEST_CASE or BOOST_AUTO_TEST_CASE_TEMPLATE, respectively), organized in test suites (arranged in BOOST_AUTO_TEST_SUITE blocks). Each BOOST_AUTO_TEST_SUITE with the associated AUTO_TESTs is a separate compilation unit, thus localted in its own file. I would now like to make sure that tests are run in a specific order. After all these are unit tests, and I want the most basic components to be tested first. Is there a way to do this with the AUTO-environment, or do I have to resort to manual registration of test suites and/or test cases ? I have tried changing the linking order, but to no avail. As always thanks for a great library collection and any help provided! Best Regards, Ruediger

4 6

[operators] Implicit instantiation.
by Robert Jones 13 May '09

13 May '09

I need to write a map class which distinguishes read from writing using the subscripting notation, so I wrapped the std::map, forwarded all the typdefs and methods, except for operator[], like this template < class Key, class T, template < typename Core > class Access > struct my_map { typedef std :: map< Key, T > core_type; typedef Access< core_type > proxy_type; typedef typename core_type :: key_type key_type; // ...lots of other stuff... proxy_type operator[]( const key_type & key ); }; where a typical 'Access' policy might be something like this. template < class T > struct proxy { typedef T map_type; typedef typename map_type :: key_type key_type; typedef typename map_type :: mapped_type mapped_type; proxy( map_type & core, const key_type & key ); proxy operator = ( const mapped_type & value ); operator mapped_type & ( ) const; }; Ok, all that broadly works, except expressions like my_map< string, string, proxy > m; if ( m[ "fred" ] == "bloggs" ).... won't compile even with a bool operator==(proxy, proxy), because the compiler can't figure out the implicit type conversions. What's needed is friend bool operator == ( proxy, const mapped_type & ); inside the proxy class, which does work. However I'd also like operator!=() to work in the same way, so I thought boost::operators, hence the declaration of proxy becomes template < class T > struct proxy : boost :: equality_comparable< proxy< T >, typename T :: mapped_type > { ... }; Which solves the problem. Now, the next twist is that I'd like to be able to compare my_map elements against any type which I can lexically convert to the mapped type, so an operator like friend template < class U > bool operator==( proxy, const U & ); but how do I express that to boost::equality_comparable, since the U type is generated by implicit instantiation, which applies to functions but not to classes? Thanks for reading. - Rob

1 0

Compile error when using breadth_first_search with these adjacency_list template parameters
by Julian 13 May '09

13 May '09

Hi, I get one compiler error when using breadth_first search with the adjacency list shown below. template < typename Vertex> class bfs_reachable_set_visitor : public default_bfs_visitor { public: bfs_reachable_set_visitor(set<Vertex>* bucket): m_set(bucket) { } template < typename Graph > void discover_vertex(Vertex u, const Graph & g) { m_set->insert(u); } set<Vertex>* m_set; }; typedef adjacency_list<setS, listS, undirectedS, RectGraphVertexData> RectAreaGraph; typedef graph_traits<RectAreaGraph>::vertex_descriptor VDescriptor; struct RectGraphVertexData {}; void some_func() { RectAreaGraph g; set<VDescriptor> reachableSet; bfs_reachable_set_visitor<VDescriptor> setvis(&reachableSet); breadth_first_search(g, *(vertices(g).first), visitor(setvis)); } The error: /Developer/boost_1_39_0/boost/property_map.hpp:351: error: no match for 'operator+' in '((const boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::listS, boost::undirectedS, RectGraphVertexData, boost::no_property, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&>*)this)->boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::listS, boost::undirectedS, RectGraphVertexData, boost::no_property, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&>::iter + boost::get [with PropertyMap = boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::listS, boost::undirectedS, RectGraphVertexData, boost::no_property, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t>, Reference = const boost::detail::error_property_not_found&, K = void*](((const boost::put_get_helper<const boost::detail::error_property_not_found&, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::listS, boost::undirectedS, RectGraphVertexData, boost::no_property, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >&)((const boost::put_get_helper<const boost::detail::error_property_not_found&, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::listS, boost::undirectedS, RectGraphVertexData, boost::no_property, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >*)(&((const boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::listS, boost::undirectedS, RectGraphVertexData, boost::no_property, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&>*)this)->boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::listS, boost::undirectedS, RectGraphVertexData, boost::no_property, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&>::index))), ((void* const&)((void* const*)(& v))))' For now, since it compiles with vecS, I can change to that, but I would prefer to have setS for edge and listS for vertex.

2 2

serialization in 1.39: crash on program exit
by Filip Peters 13 May '09

13 May '09

Hi, I just compiled our program with boost 1.39, upgraded from 1.38. Now on exit I get a crash, (unhandled exception: stack overflow). If I look at the call stack, it's filled with Scene.dll!boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() Line 88 C++ Scene.dll!boost::serialization::void_cast_detail::void_caster_shortcut::`scalar deleting destructor'() + 0xf bytes C++ Scene.dll!boost::serialization::void_cast_detail::void_caster::recursive_unregister() Line 207 + 0x28 bytes C++ Scene.dll!boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() Line 88 C++ Scene.dll!boost::serialization::void_cast_detail::void_caster_shortcut::`scalar deleting destructor'() + 0xf bytes C++ Scene.dll!boost::serialization::void_cast_detail::void_caster::recursive_unregister() Line 207 + 0x28 bytes C++ Scene.dll!boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() Line 88 C++ Scene.dll!boost::serialization::void_cast_detail::void_caster_shortcut::`scalar deleting destructor'() + 0xf bytes C++ compiler: ms visual c++ 2008 boost 1.39.0 I have a whole lot of classes that are registered with BOOST_CLASS_EXPORT, and saved through a shared_ptr to a base class. If I remove the exports, start and quit the application, I don't get a crash. It was working fine in 1.37 and 1.38. (from 1.33.1 on in fact) Has anybody seen this before or any ideas? thx, Filip Peters

3 2