Paul Davis wrote:
> below is a tiny program that demonstrates either an anti-pattern or a
> bug or both in the use/design of libsigc++. the program will generally
> run normally, but using valgrind reveals something deeply wrong, as
> noted in the annotations in the code.
>
Paul,
Fixed:
#include <boost/shared_ptr.hpp>
#include <boost/weak_ptr.hpp>
#include <sigc++/sigc++.h>
class B;
class A : public sigc::trackable
{
public:
A () {}
void signal_handler (boost::weak_ptr<B>) {};
};
class B : public sigc::trackable
{
public:
B () {}
sigc::signal<void> MySignal;
};
int
main (int argc, char* argv[])
{
{
boost::shared_ptr<A> a (new A);
{
boost::shared_ptr<B> b (new B);
boost::weak_ptr<B> c( b ) ;
b->MySignal.connect (sigc::bind (sigc::mem_fun (*(a.get()),
&A::signal_handler), c));
}
}
return 0;
}
As b goes out of scope, new B gets deleted as normal.
Now, as the slot gets destroyed its just a weak_ptr, no double delete.
I'm not exactly sure how you managed to get the double delete with a
shared_ptr. And I'm kind of wired and caught up in my own software stuff
at the moment right now, but I once read about using weak_ptr's to
remove cyclic dependencies.
I'm not sure where the problem is. If its sigc or boost. I'm guessing
its just a weird corner case between the usage.
Paul Davis
(no, I'm not answering my own question)
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/libsigc-list
