Re: [sigc] libsigc++ 3.0: How shall signal_impl::clear() be fixed?

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

My two previous posts were unnecessary. I've found why signal_impl_holder is not used in signal_impl::clear(). It makes several test cases fail. clear() is called from the destructor. shared_from_this() can't be used in the destructor.

I have pushed a patch with
  signal_impl_exec_holder exec(this);

Kjell

Den 2016-12-08 kl. 12:45, skrev Kjell Ahlstedt:

This post replaces my previous post to libsigc-list.

Den 2016-12-08 kl. 11:09, skrev Kjell Ahlstedt:

signal_impl::clear() in libsigc++ 3.0 contains

  // Don't let signal_impl::notify() erase the slots. It would invalidate the
  // iterator in the following loop.
  const bool saved_deferred = deferred_;
  signal_impl_exec_holder(this);

The last line is obviously wrong. It just creates a temporary signal_impl_exec_holder object which is immediately destroyed. My question is: Shall it be changed to

  signal_impl_exec_holder exec(this);
or
  signal_impl_holder exec(shared_from_this());
?

All occurences of signal_exec in libsigc++ 2.0 have been replaced in 3.0 by signal_impl_exec, except the one in clear().

signal_impl_exec shall be signal_impl_holder.

Is it a mistake to use signal_impl_exec_holder in clear()? It's strange that signal_impl_holder, which increases both exec_count_ and shared_ptr's use_count, is not used  in signal_impl::clear() when it's used in signal_impl::erase().

Kjell