March 2009 - Boost - lists.boost.org

[Smart Ptr][Bind] Implementaion of Weak Callback Function "weak_fn"
by Artyom 22 Mar '09

22 Mar '09

Hello, Today boost::bind allows to use shared_ptr to ensure that when the function is called the object exists: shared_ptr<bar> bar_ptr; function<void()> foo; foo=bind(&bar::slot,bar_ptr) Now even if we call bar_ptr.reset() the object is still owned by foo. But in some cases this is not good enough. This may create cyclic dependecies if A has shared_ptr to B and gives it a callback to A cyclic dependecy is created, so sometimes it would be useful to be able to provide weak bind function that is called iff the object exists -- that uses weak_ptr insteas of shared one. I has written a small draft of boost::weak_fn template<T> boost::weak_fn(void (T::*p)(...), weak_ptr<T> ptr) That creates such callback, it can be used with boost::bind similary to mem_fn: class foo { void bar(int x); }; Like: function<void(int x,int y)> f2=bind(weak_fn(&foo::bar,bar_ptr),_1+_2); function<void(int x)> f1=weak_fn(&foo::bar,bar_ptr); function<void()> f1=bind(weak_fn(&foo::bar,bar_ptr),0); The code availible from: http://art-blog.no-ip.info/files/weak_fn.tar.gz It is very initial implementation that gives functions from 0 to 3 parameters. - I just want to be sure if this is correct direction? - Comments on implementaions? Can it be done better? - Do I miss something? Thanks, Artyom

4 3

Re: [boost] [Smart Ptr][Bind] Implementaion of Weak Callback Function
by Artyom 22 Mar '09

22 Mar '09

> foo = bind( &bar::slot, bind( > &weak_ptr<bar>::lock, weak_ptr<bar>( > bar_ptr ) ) ); > Such solution may work if you would write void bar::slot() { if(!this) return; // or if(!this) throw something(); } But I this is just a hack. More then that, throwing is not good idea because generally I do not want this situation be treated as a error. > However, one of those binds must be persisting the smart > pointer > somewhere, because calling foo always has an effect for me, > where I > would expect it to segfault after the shared_ptr is reset, > since > lock() would return a null shared_ptr. You might be able to > see the > problem though, and get where you want to be. Such "second" bind should return a "void" function that does nothing, that what I solve in weak_fn. Actually the code of weak_fn is quite simple (when using variadic templates, otherwise it is just many copies of same code for 0, 1 and N parameters). Suggestions? Comments? Artyom > > HTH, > Christopher > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[gsoc]
by Matt 22 Mar '09

22 Mar '09

Hello, All I am Matthew Chandler, and I am looking to help out for the Google summer of code. I've looked through the ideas page and am interested in working on the Devector container. -Matt

2 1

[C++0x] The cpp0x branch has been merged into trunk
by Beman Dawes 21 Mar '09

21 Mar '09

The cpp0x branch has been merged into trunk, enabling a bunch of BOOST_NO_* macros for C++0x feature tests. This should have no impact on existing code, so be sure to let me know if it causes any problems. --Beman

7 19

[asio] possible multi-threaded bug with async_write_some()
by Brian and Victoria 21 Mar '09

21 Mar '09

I'm running asio (boost 1.38) multi-threaded, and noticed that on a context switch between threads, my handler for async_write_some() will sometimes get invoked with no data transferred. My handler would call async_write_some() again if there was remaining data, but this caused (most of) the data to get sent twice since there appears to still be a call to the handler pending in the work queue. I'm not sure if this behavior is a bug or not, but the solution was to check for 0 data transferred and exit the handler if so. -Brian

1 1

threadpool lockfree_channel
by Tim Blechmann 21 Mar '09

21 Mar '09

hi oliver, i just saw, that you checked in a lockfree fifo implementation to the boost sandbox. it looks like an implementation of the michael/scott queue, isn't it? if so, i suppose, you are missing a thread-safe memory reclamation mechanism ... some time ago, i wrote a boost-style implementation of this data structure, not sure, if you came across it [1] ... maybe it would make sense to join our efforts in implementing a lockfree queue and get it into boost? best, tim [1] http://tim.klingt.org/git?p=boost_lockfree.git;a=summary -- tim(a)klingt.org http://tim.klingt.org Music is the can opener of the soul. It makes you terribly quiet inside, makes you aware that there's a roof to your being. Henry Miller

9 21

[static] A useful static variable generator.
by Dongfei Yin 21 Mar '09

21 Mar '09

Hi, Some time, the sequence of static variable initialization always make something bad. the piece of code below will useful about this problem. class static_ { public: template <int N, class T> static T& var() { static T instance; return instance; } private: ~static_() {} }; so, if a static variable of std::string is wanted, I will use: static_::var<0, std::string>() = ":)"; the first template parameter is used for when many static variable of same type is needed. most important thing is all the variable will be initialized before use. Just for fun. Dongfei.

3 2

[geometry] robustness approaches
by Fernando Cacciola 21 Mar '09

21 Mar '09

Hi boost geometers ;) When Barend first presented his geometric library proposal I argued that the so-called "epsilon-based" approach used by the library is just fundamentally wrong, and most importantly, totally unnecessary since much better methodologies exist. It deeply worries me to find that the GGL proposal haven't been updated in this regard, because the instrumentation of the proper techniques have a significant impact on the overall design. Robustness can't be treated as an implementation detail to be deal with later on (and I'm sorry if I haven't made this point clear when I warn about it before). If I where to review the library today I would have to strongly vote for rejection because of this. Here is a simple example of the fundamental problems I see all over the proposed library: There is a point_in_circle algorithm, which (as I can see from its implementation), essentially returns whether the distance from the point to the center is smaller than the circle radius. No doubt *that* is the one and only correct *mathematical* formulation for the predicate, but is one that just doesn't stand in practice at all. Computing *that very particular predicate ROBUSTELY* has been the subject of active research during the past decade, to such an extent, that pretty much every paper or article on the subject of robustness in geometric computing uses the in-circle test as a common example. The library proposed by Lucannus, OTOH, at least acknowledges the problem appropriately and approaches a solution in the right direction (there is still some important design-influencing considerations but are not showstopers) Here is a starting point http://www.mpi-inf.mpg.de/departments/d1/ClassroomExamples/ Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

8 36

casting a shared_ptr from void with custom deleter
by Kenny Riddile 20 Mar '09

20 Mar '09

I'm trying to do something like this: boost::shared_ptr<const Foo> fooPtr( boost::static_pointer_cast<const Foo>(typeErasedFoo), CustomDeleter<const Foo>() ); where typeErasedFoo is of type: boost::shared_ptr<const void> The first statement compiles if I remove the custom deleter, but if I leave it in, I get errors saying: cannot convert parameter 2 from 'CustomDeleter<T>' to 'boost::detail::sp_enable_if_convertible_impl<true>::type' Is there any way to do what I'm trying to do? I no longer need typeErasedFoo after the cast if that helps.

3 3

extending asio with unix signal handlers
by Dmitry Goncharov 20 Mar '09

20 Mar '09

Hi, What do you think of extending asio with unix signal handling? The extension lets the library user to have a handler invoked when a unix signal arrives. void on_signal(boost::system::error_code const& error) { if (!error) cout << "sigint received" << endl; } int main(int argc, char const* argv[]) { boost::asio::io_service ios; boost::asio::posix::signal_handler<SIGINT> sigint(ios); while (true) { ios.reset(); sigint.async_wait(boost::bind(on_signal, _1)); ios.poll(); } } This lets the user have a unix signal handler of an arbitrary signature. This also removes the "async-signal safe calls" restriction. Please, find the implementation along with two examples enclosed. BR, Dmitry

4 4