Using libsigc++ signals - Revision history

PBS: /* Memory safety */ Fix Emitter -> Receiver

2023-02-04T12:24:36Z

Memory safety: Fix Emitter -> Receiver

← Older revision		Revision as of 12:24, 4 February 2023
Line 62:		Line 62:

	===Automatic disconnection===		===Automatic disconnection===
	Make <tt>~~Emitter~~</tt> publically derive from <tt>sigc::trackable</tt>. Then use any of <tt>sigc::mem_fn()</tt>, <tt>sigc::track_obj()</tt> or <tt>sigc::track_object()</tt> to create slots. The slot will then be disconnected when the object is destroyed.		Make <tt>Receiver</tt> publically derive from <tt>sigc::trackable</tt>. Then use any of <tt>sigc::mem_fn()</tt>, <tt>sigc::track_obj()</tt> or <tt>sigc::track_object()</tt> to create slots. The slot will then be disconnected when the object is destroyed.

	Here are some further comments and caveats with this approach:		Here are some further comments and caveats with this approach:

	*If you forget to make make <tt>~~Emitter~~</tt> inherit from <tt>sigc::trackable</tt>, then <tt>sigc::mem_fn()</tt> and <tt>sigc::track_obj()</tt> will silently fall back to being unsafe, which makes code that uses them fragile. By contrast, <tt>sigc::track_object()</tt> will refuse to compile. However, at the time of writing, the superior <tt>sigc::track_object()</tt> cannot be used yet due to not being supported on all build targets.		*If you forget to make make <tt>Receiver</tt> inherit from <tt>sigc::trackable</tt>, then <tt>sigc::mem_fn()</tt> and <tt>sigc::track_obj()</tt> will silently fall back to being unsafe, which makes code that uses them fragile. By contrast, <tt>sigc::track_object()</tt> will refuse to compile. However, at the time of writing, the superior <tt>sigc::track_object()</tt> cannot be used yet due to not being supported on all build targets.

	*Even with the above approach, signals will be disconnected during the destructor of the <tt>sigc::trackable</tt> base subobject, which happens ''after'' the destructor of the <tt>~~Emitter~~</tt> subobject. So it is entirely possible for a sufficiently complicated class hierarchy, written by many different authors and performing complex signal manipulations in its destructor, to invoke slots on destructed objects even when the best practices for <tt>sigc::trackable</tt> and <tt>sigc::track_obj()</tt> are followed. This is not an issue for simple classes, or for the approach of the next section.		*Even with the above approach, signals will be disconnected during the destructor of the <tt>sigc::trackable</tt> base subobject, which happens ''after'' the destructor of the <tt>Receiver</tt> subobject. So it is entirely possible for a sufficiently complicated class hierarchy, written by many different authors and performing complex signal manipulations in its destructor, to invoke slots on destructed objects even when the best practices for <tt>sigc::trackable</tt> and <tt>sigc::track_obj()</tt> are followed. This is not an issue for simple classes, or for the approach of the next section.

	===Manual disconnection ===		===Manual disconnection ===

PBS: Bring earlier sections up to date, add memory safety section

2023-02-04T05:56:58Z

Bring earlier sections up to date, add memory safety section

Show changes

Tweenk: /* Conventions and tips */

2014-03-09T23:57:04Z

Conventions and tips

← Older revision		Revision as of 23:57, 9 March 2014
Line 162:		Line 162:

	==Conventions and tips==		==Conventions and tips==
	* Your signals should only have parameters that can change with each invocation. For example, a position change signal could have the old and new positions as the parameters. In particular, signals ~~'''~~should ~~never~~ have the emitting object as a parameter.~~'''~~ The proper way to connect to a signal from a different object is to use <tt>sigc::bind</tt> like this:		* Your signals should only have parameters that can change with each invocation. For example, a position change signal could have the old and new positions as the parameters. In particular, signals should not have the emitting object as a parameter. The proper way to connect to a signal from a different object is to use <tt>sigc::bind</tt> like this:
	class SomeObject {		class SomeObject {
	public:		public:

Tweenk: /* Return values of signals */

2013-09-24T20:54:11Z

Return values of signals

← Older revision		Revision as of 20:54, 24 September 2013
Line 132:		Line 132:
	double length_from_last_slot = signal_get_length.emit();		double length_from_last_slot = signal_get_length.emit();

	This ~~isn't very powerful~~, because you lose data from other slots. libsigc++ provides a powerful mechanism for handling return values from multiple slots, called accumulators.		This is not ideal, because you lose data from other slots. libsigc++ provides a powerful mechanism for handling return values from multiple slots, called accumulators.

	===Accumulators===		===Accumulators===

Tweenk: /* Connecting to signals */

2013-09-24T20:51:51Z

Connecting to signals

← Older revision		Revision as of 20:51, 24 September 2013
Line 43:		Line 43:
	}		}
	private:		private:
	void _handleNumberChange(int ~~state~~) {		void _handleNumberChange(int increment) {
	std::cout << "The number increased by " << ~~state~~ << std::endl;		std::cout << "The number increased by " << increment << std::endl;
	}		}
	};		};

Tweenk: /* Defining signals */

2013-09-24T20:51:22Z

Defining signals

← Older revision		Revision as of 20:51, 24 September 2013
Line 18:		Line 18:
	int getNumber() { return _number; }		int getNumber() { return _number; }
	std::string const &getName { return _name; }		std::string const &getName { return _name; }
	'''sigc::signal<void> signal_number_changed;'''		'''sigc::signal<void, int> signal_number_changed;'''
	private:		private:
	int _number;		int _number;

Tweenk: /* Conventions and tips */

2009-12-31T09:28:47Z

Conventions and tips

← Older revision		Revision as of 09:28, 31 December 2009
Line 162:		Line 162:

	==Conventions and tips==		==Conventions and tips==
	# Your signals should only have parameters that can change with each invocation. For example, a position change signal could have the old and new positions as the parameters. In particular, signals '''should never have the emitting object as a parameter.''' The proper way to connect to a signal from a different object is to use <tt>sigc::bind</tt> like this:		* Your signals should only have parameters that can change with each invocation. For example, a position change signal could have the old and new positions as the parameters. In particular, signals '''should never have the emitting object as a parameter.''' The proper way to connect to a signal from a different object is to use <tt>sigc::bind</tt> like this:
	class SomeObject {		class SomeObject {
	public:		public:
Line 179:		Line 179:
	In the example, a reference is bound (because the SomeObject parameter will never need to be NULL), but you can also use a pointer.		In the example, a reference is bound (because the SomeObject parameter will never need to be NULL), but you can also use a pointer.

	# Use the C++ wrappers for GTK+ as a reference for good signal parameter choices.		* Use the C++ wrappers for GTK+ as a reference for good signal parameter choices.
			* The memory and performance overhead of adding signals to an object is quite small - most things are handled at compile time thanks to the use of templates.
	# The memory and performance overhead of adding signals to an object is quite small - most things are handled at compile time thanks to the use of templates.		* When using [[Boost shared pointers]], you cannot bind them as the "emitting object" parameter to slots. That's because the shared pointer will be copied into the object's slot list, keeping it in memory indefinitely. You need to use a weak pointer, which won't prevent the object's desctruction, but can be used to obtain a regular shared pointer. See [[Shared pointers]] for a more detailed guide.

	# When using [[Boost shared pointers]], you cannot bind them as the "emitting object" parameter to slots. That's because the shared pointer will be copied into the object's slot list, keeping it in memory indefinitely. You need to use a weak pointer, which won't prevent the object's desctruction, but can be used to obtain a regular shared pointer. See [[Shared pointers]] for a more detailed guide.

	==See Also==		==See Also==
	[http://libsigc.sourceforge.net/libsigc2/docs/index.html libsigc++ reference documentation]		[http://libsigc.sourceforge.net/libsigc2/docs/index.html libsigc++ reference documentation]
	[http://bugzilla.gnome.org/show_bug.cgi?id=586436 Gnome bug #586436 - epic accumulator fail]		[http://bugzilla.gnome.org/show_bug.cgi?id=586436 Gnome bug #586436 - epic accumulator fail]

Tweenk: /* Accumulators */

2009-12-31T09:27:48Z

Accumulators

← Older revision		Revision as of 09:27, 31 December 2009
Line 159:		Line 159:
	Now <tt>sum_of_lengths</tt> contains the sum of return values from all the slots.		Now <tt>sum_of_lengths</tt> contains the sum of return values from all the slots.

	WARNING: ~~I have discovered a~~ bug in libsigc++ that makes accumulators severely broken, because their result type must be implicitly convertible to and from the slot return type. See [http://bugzilla.gnome.org/show_bug.cgi?id=586436 this GNOME bug.] ~~Until this is~~ fixed~~, accumulators aren't very useful~~. --[[User:Tweenk\|Tweenk]] 01:31~~, 20 June~~ 2009 (UTC)		WARNING: There is an old bug in libsigc++ that makes accumulators severely broken, because their result type must be implicitly convertible to and from the slot return type. See [http://bugzilla.gnome.org/show_bug.cgi?id=586436 this GNOME bug.] It will be fixed in the next libsigc++ release. --[[User:Tweenk\|Tweenk]] 09:27, 31 December 2009 (UTC)

	==Conventions and tips==		==Conventions and tips==

Tweenk: /* Defining signals */

2009-12-31T09:25:18Z

Defining signals

← Older revision		Revision as of 09:25, 31 December 2009
Line 27:		Line 27:
	return o;		return o;
	}		}

			Several Inkscape classes use private signal attributes and define accessor methods for connecting slots, but this prevents you from using some advanced features. Wrapping them all in accessors isn't worth the hassle.

	<tt>signal</tt> is a class template. The first type parameter is the return type of the slot. The remaining ones are the types of parameters passed to each slot when the signal is ''emitted''.		<tt>signal</tt> is a class template. The first type parameter is the return type of the slot. The remaining ones are the types of parameters passed to each slot when the signal is ''emitted''.

Tweenk: /* Conventions and tips */

2009-08-01T21:46:54Z

Conventions and tips

← Older revision		Revision as of 21:46, 1 August 2009
Line 160:		Line 160:

	==Conventions and tips==		==Conventions and tips==
	# Your signals should only ~~expose what's necessary in~~ the ~~parameter list~~. In particular, ~~they~~ should ~~not~~ have the emitting object as a parameter. Use the C++ wrappers for GTK+ as a reference for good signal parameter choices.		# Your signals should only have parameters that can change with each invocation. For example, a position change signal could have the old and new positions as the parameters. In particular, signals '''should never have the emitting object as a parameter.''' The proper way to connect to a signal from a different object is to use <tt>sigc::bind</tt> like this:
	# When using Boost shared pointers, you cannot bind them as the "emitting object" parameter to slots. That's because the shared pointer will ~~sit in~~ the object's slot list, keeping it in memory indefinitely. You need to use a weak pointer, which won't prevent the object's desctruction, but can be used to obtain a regular shared pointer. See [[Shared pointers]] for a more detailed guide.		class SomeObject {
			public:
			sigc::signal<void> signal_update;
			...
			};
			class OtherObject {
			...
			void onUpdate(SomeObject &so);
			};
			...
			some_object.signal_update.connect(
			sigc::bind<0>(
			sigc::mem_fun(other_object, &OtherObject::onUpdate),
			some_object));
			In the example, a reference is bound (because the SomeObject parameter will never need to be NULL), but you can also use a pointer.

			# Use the C++ wrappers for GTK+ as a reference for good signal parameter choices.

			# The memory and performance overhead of adding signals to an object is quite small - most things are handled at compile time thanks to the use of templates.

			# When using [[Boost shared pointers]], you cannot bind them as the "emitting object" parameter to slots. That's because the shared pointer will be copied into the object's slot list, keeping it in memory indefinitely. You need to use a weak pointer, which won't prevent the object's desctruction, but can be used to obtain a regular shared pointer. See [[Shared pointers]] for a more detailed guide.

	==See Also==		==See Also==
	[http://libsigc.sourceforge.net/libsigc2/docs/index.html libsigc++ reference documentation]		[http://libsigc.sourceforge.net/libsigc2/docs/index.html libsigc++ reference documentation]
	[http://bugzilla.gnome.org/show_bug.cgi?id=586436 Gnome bug #586436 - epic accumulator fail]		[http://bugzilla.gnome.org/show_bug.cgi?id=586436 Gnome bug #586436 - epic accumulator fail]