From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Pass a serial port as user data in a GTK callback handler? Date: Sun, 16 Feb 2014 19:02:59 +0100 Organization: cbb software GmbH Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dRN93LcgZmpMwxQ2TpSF2g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 3010 Xref: number.nntp.dca.giganews.com comp.lang.ada:184925 Date: 2014-02-16T19:02:59+01:00 List-Id: On Sun, 16 Feb 2014 13:57:42 -0300, hreba wrote: >> Specifically to GTK, you should better use smart pointers rather than raw >> access types when dealing with callbacks and pass them around. The point >> that UI and I/O will run in independent tasks. It is difficult to prevent >> dangling pointers otherwise. [I don't consider global variables, of course] > > So I will be back when I have to fight with task programming in Ada, as > soon as I begin with the real communication part. > > I did a fast search without finding a data structure "smart pointer" in > GObject, GLib or GTK (devhelp), only as part of the C++ language (which > I don't know). GObject and GValue in the case of GTK. The former is the base type of all GTK widgets. One possible design is that your custom widget contains the communication object it deals with. The handlers of the signals pass the access to the widget as the user parameter. There are means in GTK to ensure that signals from other widgets (when not children) that pass the widget's pointer around are disconnected when the widget disappears before the signal emitting widgets do. That prevents dangling pointers. A problem with this design is that the widget type in GtkAda is not limited. You cannot put a limited member into a non-limited widget object. So you might need a smart pointer again. In simpler cases you could just allocate the limited object in Initialize (called from Gtk_New) with new-allocator and keep the returned pointer it the widget object. In the handler of the widget's Destroy signal you would do Unchecked_Deallocate on the pointer. > But I am using Ada. Could you give a hint/reference/link > to that? You use a controlled object derived from Ada.Finalization.Controlled. The implementation of Finalize does Unchecked_Deallocate on the pointer if the reference count drops to 0. There are many implementations of this schema available. But it is not really difficult to do just from scratch. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de