GNOME.org
 

[gtkmm] Gtkmm-forge digest, Vol 1 #344 - 5 msgs

Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-admin lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  A daily digest is sent to gtkmm-main, to encourage people to help fixing the bugs.


Today's Topics:

   1. [Bug 104194] Changed - A window with an option menu seg-faults when closed. (bugzilla-daemon widget gnome org)
   2. [Bug 104181] Changed - Example segfaults after some time (bugzilla-daemon widget gnome org)
   3. [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer (bugzilla-daemon widget gnome org)
   4. [Bug 101878] Changed - Glib::RefPtr<> should have operator*() (bugzilla-daemon widget gnome org)
   5. [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer (bugzilla-daemon widget gnome org)

--__--__--

Message: 1
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, jsado_sc1 earthlink net
Cc: 
Date: Tue, 28 Jan 2003 18:03:17 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104194] Changed - A window with an option menu seg-faults when closed.

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104194

Changed by jsado_sc1 earthlink net 

--- shadow/104194	Mon Jan 27 06:47:29 2003
+++ shadow/104194.tmp.10177	Tue Jan 28 18:03:17 2003
@@ -196,6 +196,11 @@
 ==1376==    by 0x41D42F9C: ???
 ==1376==    by 0xE0107000: ???
 
 
 ------- Additional Comments From murrayc usa net  2003-01-27 06:47 -------
 Please _attach_ a test case. We can do nothing without that.
+
+------- Additional Comments From jsado_sc1 earthlink net  2003-01-28 18:03 -------
+Created an attachment (id=13896)
+Current seg-fault test case.
+



--__--__--

Message: 2
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, olau hardworking dk
Cc: 
Date: Tue, 28 Jan 2003 18:14:20 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104181] Changed - Example segfaults after some time

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104181

Changed by murrayc usa net 

--- shadow/104181	Mon Jan 27 17:22:05 2003
+++ shadow/104181.tmp.16890	Tue Jan 28 18:14:20 2003
@@ -1,13 +1,13 @@
 Bug#: 104181
 Product: gnomemm
 Version: 2.0
 OS: other
 OS Details: 
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: FIXED
 Severity: normal
 Priority: Normal
 Component: gconfmm
 AssignedTo: gtkmm-forge lists sourceforge net                            
 ReportedBy: olau hardworking dk               
 TargetMilestone: ---
@@ -128,6 +128,13 @@
 a new version.
 
 ------- Additional Comments From olau hardworking dk  2003-01-27 17:22 -------
 Created an attachment (id=13862)
 Patch of gconfmm/ChangeLog and gconfmm/gconf/gconfmm/callback.cc
 
+
+------- Additional Comments From murrayc usa net  2003-01-28 18:14 -------
+Fantastic. Well done. I was beginning to worry about this. By the way,
+valgrind might also have been helpful but it crashes on this example.
+
+Unless it's urgent for you, I will release a new version after a few
+days, just in case.



--__--__--

Message: 3
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, michaelj maine rr com
Cc: 
Date: Tue, 28 Jan 2003 18:24:01 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104332

Changed by murrayc usa net 

--- shadow/104332	Tue Jan 28 04:48:58 2003
+++ shadow/104332.tmp.23203	Tue Jan 28 18:24:00 2003
@@ -134,6 +134,10 @@
 
 
 ------- Additional Comments From murrayc usa net  2003-01-28 04:48 -------
 This patch, glibmm_object.patch, simplifies things a bit and shows
 just the lifecycle changes, though it also moves some methods around
 without changing them.
+
+------- Additional Comments From murrayc usa net  2003-01-28 18:23 -------
+I've looked at this again and I realise that I don't understand.
+Sorry, I'm stupid. Can you try explaining this anchor thing again?



--__--__--

Message: 4
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Tue, 28 Jan 2003 19:00:12 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 101878] Changed - Glib::RefPtr<> should have operator*()

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=101878

Changed by michaelj maine rr com 

--- shadow/101878	Tue Jan 28 08:05:39 2003
+++ shadow/101878.tmp.14698	Tue Jan 28 19:00:12 2003
@@ -30,6 +30,29 @@
 
 ------- Additional Comments From murrayc usa net  2003-01-28 08:05 -------
 I don't see any use for this until we can use RefPtr with
 Gtk::Object-derived classes. Apparently the problem with that is that
 the Gtk::Object can be destroyed even when there are outstanding
 references.
+
+------- Additional Comments From michaelj maine rr com  2003-01-28 19:00 -------
+Providing operator*() for RefPtr<> allows appropriate access to
+operators of the referenced object, e.g.:
+
+(*ptr) += some_value;
+++(*ptr);
+value = (*ptr)[index];
+
+Even though there are currently no operators for any classes derived
+from SigC::Object, this would make it much more practical to create
+some in the future. I'm sure there are practical uses for operators
+for a variety of glibmm classes.
+
+While I can understand the original motivation for not supporting the
+operator (presumably it was to avoid having programmers take and keep
+"dumb" references to the referenced object; I did the same thing the
+first time I wrote a smart pointer class) it really doesn't have that
+effect, because anyone with a little savvy can just do something like
+"pointer = ptr.operator->()" which is dirty and ugly. You're better
+off removing their motivation to do that by providing the
+dereferencing operator so that RefPtr<> behaves as much like a
+built-in pointer type as possible.



--__--__--

Message: 5
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Tue, 28 Jan 2003 23:19:13 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104332

Changed by michaelj maine rr com 

--- shadow/104332	Tue Jan 28 18:24:00 2003
+++ shadow/104332.tmp.12567	Tue Jan 28 23:19:12 2003
@@ -138,6 +138,86 @@
 just the lifecycle changes, though it also moves some methods around
 without changing them.
 
 ------- Additional Comments From murrayc usa net  2003-01-28 18:23 -------
 I've looked at this again and I realise that I don't understand.
 Sorry, I'm stupid. Can you try explaining this anchor thing again?
+
+------- Additional Comments From michaelj maine rr com  2003-01-28 23:19 -------
+I wouldn't attribute a lack of understanding to stupidity. It took me
+a little while to come up with the model. It's actually not that
+complicated, but you need to get the right perspective, I guess. If I
+could whiteboard it, that would probably help.
+
+The basic problem that needed to be solved is that there are two
+objects, closely coupled, that are both reference counted. Certain
+constraints needed to be obeyed in describing the interactions between
+them. Foremost, they need to have separate reference counts, because
+the GTK+ model of reference counting is incompatible with the
+conventional C++ model. First, some definitions:
+
+1) The C object is the "GObject". It is the owned object.
+2) The C++ object is the "wrapper". It owns an internal reference to
+the GObject.
+3) An "internal reference" is a reference to one of the two objects,
+held by the other object.
+4) An "external reference" is a reference to one of the two objects
+that is not held by the other object. In the case of the wrapper, an
+external reference is embodied by a RefPtr. In the case of the
+GObject, an external reference would be held by some GTK+ entity.
+
+Next, some constraints:
+
+1) Both objects need to exist so long as there are external references
+to either of them. This is so that the wrap() function will always
+return the same wrapper.
+2) Either object can keep the other alive by maintaining an internal
+reference.
+3) The two objects cannot hold mutual internal references, because
+they would then keep each other alive indefinitely.
+
+So the problem became, under what conditions should either of the
+objects hold an internal reference in order to satisfy the first and
+third constraints? In order to make this easier to determine, I came
+up with the designation of the "anchor" object:
+
+4) Only one object is the anchor object. It is the responsibility of
+the anchor object to keep the other alive when it might otherwise die.
+5) So long as there are external references, there will be at least
+one external reference to the anchor.
+6) Only the anchor object has an internal reference.
+
+Because the wrapper starts with an internal reference (to the GObject)
+and keeps that reference almost all the time, it makes sense for the
+wrapper to be the anchor under most conditions. The only time that the
+wrapper cannot be the anchor is when there are no more external
+references to it (because of constraint 5).
+
+So basically, when there are external references to the wrapper, it is
+the anchor and holds an internal reference to the GObject. When (and
+only when) there are no external references to the wrapper, then the
+GObject is the anchor and holds an internal reference to the wrapper.
+The manner in which the GObject "holds" the internal reference is an
+implementation detail, but it is useful to note that all of the work
+actually happens in member functions of the wrapper, because we cannot
+ change the implementation of the GObject.
+
+An important consequence of making the GObject the anchor whenever
+there are no external references to the wrapper is that the GObject
+will always be the anchor when there are no more external references
+at all. Hence, the GObject will always be destroyed first, which will
+in turn cause the destruction of the wrapper.
+
+One must of course be careful of the order in which references are
+acquired and released in the wrapper implementation.
+
+The implementations of Glib::IOChannel and Glib::Source use a slight
+modification of this basic scheme which finesses constraint 6, because
+their "gobject" is an instance of a local C++ class rather than an
+opaque C structure.
+
+Of course, things get more complicated in Gtk::Object, but I won't go
+into that at the moment, other than to note that there are a few hooks
+built into Glib::ObjectBase to facilitate the implementation of
+Gtk::Object.
+
+Does this help any?




--__--__--

_______________________________________________
Gtkmm-forge mailing list
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]