List Info

Thread: Slots not block()-ing ( debian bug #326221)?




Slots not block()-ing ( debian bug #326221)?
user name
2006-11-06 15:00:22
Hello everyone
 
I'm currently having the same problem that was posted a
while ago in a
Debian Bug description (archived here:
http://www.m
ail-archive.com/libsigc-listgnome.org/msg00195.html)
I tried to search the mailing list archive but could not
find anything
related to my problem.
When I try this:

class CFoo : public sigc::trackable
{
public:
  CFoo()
  {
    m_SlotDelete = sigc::mem_fun( this, OnSlotDeleteObject
);
  }
  virtual ~CFoo()
  {
    m_SigDelete.emit();
  }

  sigc::signal<void>        m_SigDelete;
  sigc::slot<void>          m_SlotDelete;

protected:
  virtual void  OnSlotDeleteObject()
  {
    m_SlotDelete.block();

    delete this;
  }
};


void TestFun()
{
  CFoo *p_master = new CFoo;
  CFoo *p_slave = new CFoo;

  p_master->m_SigDelete.connect( p_slave->m_SlotDelete
);
  // Bad but illustrates the problem
  p_slave->m_SigDelete.connect( p_slave->m_SlotDelete
);

  // Infinite recursion
  delete p_master;
}

When calling TestFun, there is an infinite recursion since
the
m_SigDelete calls OnSlotDeleteObject although the slot is
theoretically
blocked.
Now for my questions:
- Is this intended behaviour?
- I suppose since the bug is really old and hasn't been
fixed it
actually can't be fixed?
- Can I do this in some way other than to use sigc::mem_fun
everywhere
in the code when I want the callback to be executed in
response to a
signal?
Any help would be greatly appreciated!

Cheers

Ulf

_______________________________________________
libsigc-list mailing list
libsigc-listgnome.org
h
ttp://mail.gnome.org/mailman/listinfo/libsigc-list
[1]

about | contact  Other archives ( Real Estate discussion Medical topics )