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
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
https://mail.gnome.org/mailman/listinfo/libsigc-list
