- Boost-users - lists.boost.org

Re: [Boost-users] [Asio]Question about error_code when socket::close
by Comet 17 May '10

17 May '10

> That is because you are most likely using the inefficient creation > style, probably like this: > shared_ptr<myClass> myPtr(new myClass(arg1,arg2)); > Which will also new a struct inside the shared_ptr that holds that > pointer and bookkeeping information. If you have read the shared_ptr > documentation, the efficient creation style is this: > shared_ptr<myClass> myPtr = make_shared<myClass>(arg1,arg2); > Which will new both your class and the bookkeeping information in the > same place in memory, increasing both the speed of creation (only one > new), and speed of accessing (better cache coherency). > When creating your objects at the same time (literally) as the > shared_ptr, that should fix most of those speed issues. That's not the point, make_shared can be used only when the object is created,but what I said is as follows: class Session : public boost::enable_shared_from_this<Session> { public: static void HandleRead(boost::weak_ptr<Session> session, const boost::system::error_code& error, size_t bytes_transferred) { if (session.expired()) return; ... } void Read() { // this line is very slow, // because boost::bind(&Session::HandleRead,shared_from_this(), ...) // causes extra new/delete operations socket_.async_read_some(boost::asio::buffer(...), boost::bind(&Session::HandleRead, shared_from_this(), _1, _2)); ... } void Close() { socket_.close(); } private: boost::asio::ip::tcp::socket socket_; }; std::set<boost::shared_ptr<Session> > session_set; boost::shared_ptr<Session> session = boost::make_shared<Session>(); session_set.insert(session); session->Read(); .... session->Close(); session_set->erase(session); // session is destroyed here, if I replace static void HandleRead(weak_prt ...) with void HandleRead(...) and boost::bind(&Session::HandleRead, shared_from_this()...), with boost::bind(&Session::HandleRead, this, ...); the question I asked emerges: void HandleRead(const boost::system::error_code& error, size_t bytes_transferred) { if (error) //should I erase shared_from_this() from session_set? this object may have been destroyed... } .... session->Close(); session_set->erase(session); // session is destroyed here. if I don't do this here, where should I do ? HandleRead may not be registered ever...

2 1

Re: [Boost-users] [fusion]simple fusion seq_size fails to compile
by Pete Bartlett 17 May '10

17 May '10

>The attached works; however, it just seems a lot of effort for such a simple task. >Anybody have a simpler way? Well, as you said the simpler way is to use the size function provided :-). Also your size implementation is somewhat unsatisfying in the sense that it uses empty which internally uses the library's size (meta)function. In fact I think size has to be implemented as a "core" function (i.e. not built up from other publically available functions) because it is implementation is necessarily quite different for different types of fusion sequence (e.g. array and an MPL sequence). Not an expert, Pete

2 1

[Function][Bind] Strange problem with g++ 4.5
by Maxime van Noppen 17 May '10

17 May '10

Hi, I've got a very strange problem with Boost.Function used in conjunction with Boost.Bind with g++ 4.5.0. Here is the minimal test case: ----------------gtest.cc--------------------------------- #include <boost/bind.hpp> #include <boost/function.hpp> #include <iostream> int fun(const int* id) { std::cout << "id: " << id << std::endl; std::cout << *id << std::endl; return 0; } int main() { typedef boost::function<int ()> func_t; int id = 42; std::cout << "id: " << &id << std::endl; func_t f = boost::bind(&fun, &id); //std::cout << f << std::endl; func_t g = f; g(); return 0; } ------------------------------------------------- When compiled with -O2 the program crashes: ------------------------------------------------- $ g++ -O2 gtest.cc && ./a.out id: 0x7fff3f7f85ec id: 0 Segmentation fault ------------------------------------------------- The problem seems to be inlining, when compiled with -O0 or -O2 -fno-inline everything works fine: ------------------------------------------------- $ g++ -O2 -fno-inline gtest.cc && ./a.out id: 0x7fff32b81a9c id: 0x7fff32b81a9c 42 $ g++ -O0 gtest.cc && ./a.out id: 0x7fff960b270c id: 0x7fff960b270c 42 ------------------------------------------------- What is very strange is that if I uncomment the std::cout of f everything works fine: ------------------------------------------------- $ g++ -O2 gtest.cc && ./a.out id: 0x7fff738619ac 1 id: 0x7fff738619ac 42 ------------------------------------------------- If the Boost.Function is not copied to g (ie, use f) everything works. Everything works fine with g++ (GCC) 4.4.3 20100316 (prerelease). I'm using Linux x86_64 with boost 1.42 and 1.43. Any idea of what may be going wrong here? -- Maxime

2 4

Re: [Boost-users] [Asio]Question about error_code when socket::close
by Comet 17 May '10

17 May '10

> void Read() { > // this line is very slow, > // because boost::bind(&Session::HandleRead,shared_from_this(), ...) > // causes extra new/delete operations My test result: ---------------------------------- raw ptr version ------------------------ a.cc: class A { public: void f() {} }; int main() { A a; boost::function<void ()> f; for (size_t i = 0; i < 100000000; ++i) { f = boost::bind(&A::f, &a); } } gcc a.cc -O2 time ./a.out real 0m1.235s user 0m1.232s sys 0m0.000s ------------------------------------ shared_ptr version ---------------------- a.cc: class A { public: static void f(boost::weak_ptr<A>) {} }; int main() { boost::shared_ptr<A> a = boost::make_shared<A>(); boost::function<void ()> f; for (size_t i = 0; i < 100000000; ++i) { f = boost::bind(&A::f, a); } } gcc a.cc -O2 time ./a.out real 0m25.925s user 0m25.898s sys 0m0.000s

1 0

linking for release, has debug baggage
by Dan Bloomquist 17 May '10

17 May '10

Hi, I have a large project and for what ever reason if I add xpressive.hpp in my precompiled header, it completly kills intelligence. So I figured I'd move the stuff I want to use off to a lib. Works fine in debug but if I build the release, this lib tries to link in the Microsoft debug libs. In my project: 1>mfcs90.lib(nolib.obj) : warning LNK4098: defaultlib 'mfc90d.lib' conflicts with use of other libs; use /NODEFAULTLIB:library 1>mfcs90.lib(nolib.obj) : warning LNK4098: defaultlib 'mfcs90d.lib' conflicts with use of other libs; use /NODEFAULTLIB:library and just this one in the test solution: 1>msvcrt.lib(cinitexe.obj) : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library I have been able to recreate the problem in a small solution that should not dependent on my directories other than setting the boost path: <http://lakeweb.net/downloads/RaVpath.zip> (20k) vc 2008 (9.0) boost 1_42 And I don't know, this may have nothing to do with boost, but I have other dlls and libs without this problem. It is coming from 'boost::filesystem' as best as I can determine. And maybe someone has seen this before and knows off the top of their head. Thanks, Dan.

2 1

[thread] Reader/Writer starvation
by Jérémy Coulon 17 May '10

17 May '10

Hi, According to the documentation of Boost 1.34 (before the major rewrite of boost::thread), the read/write lock was offering different scheduling policies. Some of those policies were providing a solution to the starvation problem that usually occurs with this kind of lock. http://www.boost.org/doc/libs/1_34_1/doc/html/thread/concepts.html#thread.c… http://www.boost.org/doc/libs/1_34_1/doc/html/thread/concepts.html#thread.c… But I don't find any reference to starvation and scheduling policies in the current Boost documentation (1.37). So, I am wondering if this starvation problem is solved in the current boost::thread implementation ? What scheduling policy is actually the default one ? Can the documentation be improved ? Thanks. Jeremy

2 1

Re: [Boost-users] [Asio]Question about error_code when socket::close
by 鑫炜廖 17 May '10

17 May '10

Igor R <boost.lists <at> gmail.com> writes: > > > I want to distinguish the error_code set by calling socket::close from any other ways (like system error, network > > error, etc), otherwise, I can't determine whether I should delete the object in async handlers, because > some have already been deleted after I call socket::close. If boost::asio::error::operation_aborted > definitely means "socket::close is called", I can distinguish this situation. > > It seems to be rather error-prone approach. One day, when your > application will have grown a bit, you'll find yourself hunting weird > segfaults / access-violations. > But when should I delete the object after I call socket::close? May be there's no async handler, so just deleting object in handlers leads to memory leak. > > I've tried using boost::weak_ptr with boost::bind,but the performance decrease dramatically. > > Did you run a performance profiler with fully-optimized application > and really discovered that the bottle-neck is in shared_ptr's?! This > would be really surprising... > I've tested it separately, when binding a weak_ptr/shared_ptr with a member function, it will cause extra new/delete operations, but raw pointer will not(gcc 4.4.1, boost 1.4.3).The former way is about 20 times slower,as a frequently operation, it seems not acceptable.

2 1

Re: [Boost-users] [fusion]simple fusion seq_size fails to compile
by Pete Bartlett 16 May '10

16 May '10

>Compilation of attachment 1 with gcc-4.5, produces errors in attachment 2. When the >'#if 1' on line 24 is changed to '#if 0', it compiles OK. > >What am I doing wrong? > >TIA. In the second "inner" instantiation of seq_size (ie the one taking in an empty sequence), what return type /could/ pop_front have? So intuitively a compile error is what I would expect here - and I think a literal reading of the documentation agrees because an empty sequence does not satisfy the fusion Sequence concept.

2 2

[fusion]simple fusion seq_size fails to compile
by Larry Evans 16 May '10

16 May '10

Compilation of attachment 1 with gcc-4.5, produces errors in attachment 2. When the '#if 1' on line 24 is changed to '#if 0', it compiles OK. What am I doing wrong? TIA. -regards, Larry /home/evansl/download/gcc/4.5-20100408/install/bin/g++ -c -Wall -ftemplate-depth-300 -O0 -g3 -fno-inline -std=gnu++0x -I/home/evansl/prog_dev/boost-svn/ro/trunk -DTEMPLATE_DEPTH=300 fusion_list_nil_function_specialization.cpp -MMD -o /home/evansl/prog_dev/boost-svn/ro/trunk/sandbox-local/build/gcc4_5n/sandbox/variadic_templates/libs/composite_storage/sandbox/fusion_list_nil_function_specialization.o In file included from /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/container/list/cons_iterator.hpp:14:0, from /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/container/list/cons.hpp:16, from /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/container/list.hpp:10, from fusion_list_nil_function_specialization.cpp:4: /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/container/list/detail/next_impl.hpp: In instantiation of 'boost::fusion::extension::next_impl<boost::fusion::cons_iterator_tag>::apply<boost::fusion::cons_iterator<boost::fusion::void_> >': /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/iterator/next.hpp:52:9: instantiated from 'boost::fusion::result_of::next<boost::fusion::cons_iterator<boost::fusion::void_> >' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/iterator/detail/distance.hpp:36:9: instantiated from 'boost::fusion::distance_detail::next_distance<boost::fusion::cons_iterator<boost::fusion::void_>, boost::fusion::cons_iterator<const boost::fusion::nil> >' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/mpl/eval_if.hpp:38:31: instantiated from 'boost::mpl::eval_if<boost::fusion::result_of::equal_to<boost::fusion::cons_iterator<boost::fusion::void_>, boost::fusion::cons_iterator<const boost::fusion::nil> >, boost::mpl::identity<mpl_::int_<0> >, boost::fusion::distance_detail::next_distance<boost::fusion::cons_iterator<boost::fusion::void_>, boost::fusion::cons_iterator<const boost::fusion::nil> > >' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/iterator/detail/distance.hpp:46:5: instantiated from 'boost::fusion::distance_detail::linear_distance<boost::fusion::cons_iterator<boost::fusion::void_>, boost::fusion::cons_iterator<const boost::fusion::nil> >' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/iterator/distance.hpp:37:13: instantiated from 'boost::fusion::extension::distance_impl<boost::fusion::cons_iterator_tag>::apply<boost::fusion::cons_iterator<boost::fusion::void_>, boost::fusion::cons_iterator<const boost::fusion::nil> >' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/iterator/distance.hpp:66:9: instantiated from 'boost::fusion::result_of::distance<boost::fusion::cons_iterator<boost::fusion::void_>, boost::fusion::cons_iterator<const boost::fusion::nil> >' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/view/iterator_range/iterator_range.hpp:33:74: instantiated from 'boost::fusion::iterator_range<boost::fusion::cons_iterator<boost::fusion::void_>, boost::fusion::cons_iterator<const boost::fusion::nil> >' fusion_list_nil_function_specialization.cpp:25:52: instantiated from 'unsigned int seq_size(const FusionSeq&) [with FusionSeq = boost::fusion::iterator_range<boost::fusion::cons_iterator<const boost::fusion::nil>, boost::fusion::cons_iterator<const boost::fusion::nil> >]' fusion_list_nil_function_specialization.cpp:25:52: instantiated from 'unsigned int seq_size(const FusionSeq&) [with FusionSeq = boost::fusion::list<int>]' fusion_list_nil_function_specialization.cpp:35:45: instantiated from here /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/container/list/detail/next_impl.hpp:37:54: error: invalid use of incomplete type 'struct boost::fusion::extension::next_impl<boost::fusion::cons_iterator_tag>::apply<boost::fusion::cons_iterator<boost::fusion::void_> >::cons_type' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/container/list/list_fwd.hpp:15:12: error: forward declaration of 'struct boost::fusion::extension::next_impl<boost::fusion::cons_iterator_tag>::apply<boost::fusion::cons_iterator<boost::fusion::void_> >::cons_type' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/container/list/detail/next_impl.hpp:45:17: error: invalid use of incomplete type 'struct boost::fusion::extension::next_impl<boost::fusion::cons_iterator_tag>::apply<boost::fusion::cons_iterator<boost::fusion::void_> >::cons_type' /home/evansl/prog_dev/boost-svn/ro/trunk/boost/fusion/container/list/list_fwd.hpp:15:12: error: forward declaration of 'struct boost::fusion::extension::next_impl<boost::fusion::cons_iterator_tag>::apply<boost::fusion::cons_iterator<boost::fusion::void_> >::cons_type' ,,,

1 0

[statechart] transition exception
by Christophe Bourez 16 May '10

16 May '10

Hi, Is it possible to transit<> back to the source state when an exception is thrown by the handler of a transition ? Pls, note that the handler of the transition can be used by several transitions in the state diagram. The state machine, being in a transition, is between two stable states. The exception can be handled by the innermost common outer state (or anyone above). In an handler of this state, is it possible to force transit<> to the source state of the transition that throws the exception ? Or is it possible to manage it differently ? Thank you for your help, Christophe

2 1