* Pass a serial port as user data in a GTK callback handler? @ 2014-02-15 23:32 hreba 2014-02-16 0:35 ` Jeffrey Carter ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: hreba @ 2014-02-15 23:32 UTC (permalink / raw) Hi, I am new to Ada and still overwhelmed by the complexity of the language. My actual programming exercise has a GTK GUI, and I want a callback handler to communicate through a serial port, so I need to pass the port in my user data, which must be of type User_Type (<>) is private; which means it must be nonlimited. But GNAT.Serial_Communications.Serial_Port is limited: type Serial_Port is new Ada.Streams.Root_Stream_Type with private; type Root_Stream_Type is abstract tagged limited private; I tried to pass a reference to the port, and it must be an "access all" (because it is not allocated by my, but a preexisting variable (hardware resource), as I understand it): port: access all GNAT.Serial_Communications.Serial_Port; But then I get an error message "all" is not permitted for anonymous access types. Is there a solution? -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-15 23:32 Pass a serial port as user data in a GTK callback handler? hreba @ 2014-02-16 0:35 ` Jeffrey Carter 2014-02-16 16:18 ` hreba 2014-02-16 7:45 ` Niklas Holsti ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: Jeffrey Carter @ 2014-02-16 0:35 UTC (permalink / raw) On 02/15/2014 04:32 PM, hreba wrote: > > "all" is not permitted for anonymous access types. > > Is there a solution? You should never use anonymous access types if you can avoid them. -- Jeff Carter "In the frozen land of Nador they were forced to eat Robin's minstrels, and there was much rejoicing." Monty Python & the Holy Grail 70 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-16 0:35 ` Jeffrey Carter @ 2014-02-16 16:18 ` hreba 0 siblings, 0 replies; 16+ messages in thread From: hreba @ 2014-02-16 16:18 UTC (permalink / raw) On 02/15/2014 10:35 PM, Jeffrey Carter wrote: > On 02/15/2014 04:32 PM, hreba wrote: >> >> "all" is not permitted for anonymous access types. >> >> Is there a solution? > > You should never use anonymous access types if you can avoid them. > Thanks for the hint. Looked up "anonymous" only now. See my reply to Niklas. -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-15 23:32 Pass a serial port as user data in a GTK callback handler? hreba 2014-02-16 0:35 ` Jeffrey Carter @ 2014-02-16 7:45 ` Niklas Holsti 2014-02-16 16:14 ` hreba 2014-02-16 9:20 ` Dmitry A. Kazakov 2014-02-17 16:13 ` adambeneschan 3 siblings, 1 reply; 16+ messages in thread From: Niklas Holsti @ 2014-02-16 7:45 UTC (permalink / raw) On 14-02-16 01:32 , hreba wrote: > Hi, > > I am new to Ada and still overwhelmed by the complexity of the language. > > My actual programming exercise has a GTK GUI, and I want a callback > handler to communicate through a serial port, so I need to pass the port > in my user data, which must be of > > type User_Type (<>) is private; > > which means it must be nonlimited. > > But GNAT.Serial_Communications.Serial_Port is limited: > > type Serial_Port is new Ada.Streams.Root_Stream_Type with private; > type Root_Stream_Type is abstract tagged limited private; > > I tried to pass a reference to the port, and it must be an "access all" > (because it is not allocated by my, but a preexisting variable (hardware > resource), as I understand it): On my machine (Win 7), the type Serial_Port is declared in GNAT.Serial_Communications by deriving from Ada.Streams.Root_Stream_Type, adding a component which refers AIUI to a Windows "handle". This is definitely a SW object; the HW resource is hidden beind Windows. On some bare-machine GNAT port, Serial_Port might be closer to the HW, but it is no doubt still a stream class, so it will not itself be mapped to some HW register. It might contain the address of (i.e. a reference to) a HW register. Therefore, you should be able to create your own Serial_Port objects on the stack, on the heap, or statically. > port: access all GNAT.Serial_Communications.Serial_Port; > > But then I get an error message > > "all" is not permitted for anonymous access types. > > Is there a solution? Give the type a name so that it isn't "anonymous": type Port_Ref is access all GNAT.Serial_Communications.Serial_Port; port : Port_Ref; Also remember to mark the actual Serial_Port object as "aliased" so that you can take its 'Access. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-16 7:45 ` Niklas Holsti @ 2014-02-16 16:14 ` hreba 0 siblings, 0 replies; 16+ messages in thread From: hreba @ 2014-02-16 16:14 UTC (permalink / raw) On 02/16/2014 04:45 AM, Niklas Holsti wrote: > Give the type a name so that it isn't "anonymous": > > type Port_Ref is access all GNAT.Serial_Communications.Serial_Port; > > port : Port_Ref; > > Also remember to mark the actual Serial_Port object as "aliased" so that > you can take its 'Access. It is the first time I stumbled about anonymous types. Looked it up in my Ada book (it is in one of the last chapters). Thanks for the clarification. -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-15 23:32 Pass a serial port as user data in a GTK callback handler? hreba 2014-02-16 0:35 ` Jeffrey Carter 2014-02-16 7:45 ` Niklas Holsti @ 2014-02-16 9:20 ` Dmitry A. Kazakov 2014-02-16 16:57 ` hreba 2014-02-17 16:13 ` adambeneschan 3 siblings, 1 reply; 16+ messages in thread From: Dmitry A. Kazakov @ 2014-02-16 9:20 UTC (permalink / raw) On Sat, 15 Feb 2014 21:32:58 -0200, hreba wrote: > My actual programming exercise has a GTK GUI, and I want a callback > handler to communicate through a serial port, so I need to pass the port > in my user data, which must be of Additionally to other responses. There cannot be any reason to pass a stream object to GTK signal handler. It is most certainly wrong to do any I/O from a signal handler, as it would block the UI. In some cases the UI may indeed be aware of I/O objects, like a COM port configuration dialog or cancel button. In these cases there is a larger object that contains the I/O object usually as a private member. 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] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-16 9:20 ` Dmitry A. Kazakov @ 2014-02-16 16:57 ` hreba 2014-02-16 18:02 ` Dmitry A. Kazakov 0 siblings, 1 reply; 16+ messages in thread From: hreba @ 2014-02-16 16:57 UTC (permalink / raw) On 02/16/2014 06:20 AM, Dmitry A. Kazakov wrote: > On Sat, 15 Feb 2014 21:32:58 -0200, hreba wrote: > >> My actual programming exercise has a GTK GUI, and I want a callback >> handler to communicate through a serial port, so I need to pass the port >> in my user data, which must be of > > Additionally to other responses. > > There cannot be any reason to pass a stream object to GTK signal handler. > It is most certainly wrong to do any I/O from a signal handler, as it would > block the UI. So far I am only trying to open/close the port when the window opens/closes, or check the availability of /dev/ttyUSB0 upon a button press. > In some cases the UI may indeed be aware of I/O objects, like a COM port > configuration dialog or cancel button. In these cases there is a larger > object that contains the I/O object usually as a private member. I think this is what I am trying right now. > 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). But I am using Ada. Could you give a hint/reference/link to that? -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-16 16:57 ` hreba @ 2014-02-16 18:02 ` Dmitry A. Kazakov 0 siblings, 0 replies; 16+ messages in thread From: Dmitry A. Kazakov @ 2014-02-16 18:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-15 23:32 Pass a serial port as user data in a GTK callback handler? hreba ` (2 preceding siblings ...) 2014-02-16 9:20 ` Dmitry A. Kazakov @ 2014-02-17 16:13 ` adambeneschan 2014-02-17 16:20 ` adambeneschan 3 siblings, 1 reply; 16+ messages in thread From: adambeneschan @ 2014-02-17 16:13 UTC (permalink / raw) On Saturday, February 15, 2014 3:32:58 PM UTC-8, hreba wrote: > Hi, > > I am new to Ada and still overwhelmed by the complexity of the language. > > My actual programming exercise has a GTK GUI, and I want a callback > handler to communicate through a serial port, so I need to pass the port > in my user data, which must be of > > type User_Type (<>) is private; > > which means it must be nonlimited. > > But GNAT.Serial_Communications.Serial_Port is limited: > > type Serial_Port is new Ada.Streams.Root_Stream_Type with private; > type Root_Stream_Type is abstract tagged limited private; > > I tried to pass a reference to the port, and it must be an "access all" > (because it is not allocated by my, but a preexisting variable (hardware > resource), as I understand it): > > port: access all GNAT.Serial_Communications.Serial_Port; > > But then I get an error message > > "all" is not permitted for anonymous access types. > > Is there a solution? I agree with everyone else that anonymous access types aren't needed in this case, and you're better off using a named access type or something else. Having said that, I just wanted to point out something about Ada: all anonymous access types are automatically "access all", i.e. they can refer to aliased variables. So you could have solved the problem by just removing the "all" keyword. -- Adam ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-17 16:13 ` adambeneschan @ 2014-02-17 16:20 ` adambeneschan 2014-02-17 21:31 ` Robert A Duff 0 siblings, 1 reply; 16+ messages in thread From: adambeneschan @ 2014-02-17 16:20 UTC (permalink / raw) On Monday, February 17, 2014 8:13:09 AM UTC-8, I wrote: > On Saturday, February 15, 2014 3:32:58 PM UTC-8, hreba wrote: > I agree with everyone else that anonymous access types aren't needed in this case, and you're better off using a named access type or something else. Having said that, I just wanted to point out something about Ada: all anonymous access types are automatically "access all", i.e. they can refer to aliased variables. So you could have solved the problem by just removing the "all" keyword. To expound on this a bit, since you mentioned you were overwhelmed by the complexity of the language: This particular inconsistency is there because of backward compatibility. Ada 83 did not have access types that could point to variables, nor did it have anonymous access types. Those were added in Ada 95. The Ada 95 designers decided that since Ada 83 access types didn't have to be implemented as addresses, it was necessary to have some way to distinguish between an access type that could point to a variable and an access type that was required to point to something allocated with "new"; in order not to break existing Ada 83 programs, the "access all" type was added, which I'm sure they hated having to do (adding the extra keyword), but sometimes there just isn't a good solution. -- Adam ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-17 16:20 ` adambeneschan @ 2014-02-17 21:31 ` Robert A Duff 2014-02-19 0:53 ` Randy Brukardt 0 siblings, 1 reply; 16+ messages in thread From: Robert A Duff @ 2014-02-17 21:31 UTC (permalink / raw) adambeneschan@gmail.com writes: > To expound on this a bit, since you mentioned you were overwhelmed by > the complexity of the language: This particular inconsistency is there > because of backward compatibility. Ada 83 did not have access types > that could point to variables, nor did it have anonymous access types. > Those were added in Ada 95. The Ada 95 designers decided that since > Ada 83 access types didn't have to be implemented as addresses, it was > necessary to have some way to distinguish between an access type that > could point to a variable and an access type that was required to > point to something allocated with "new"; in order not to break > existing Ada 83 programs, the "access all" type was added, which I'm > sure they hated having to do... We didn't have to do it, and Tucker didn't want to do it, but I convinced him it was a good idea. I later realized I was wrong, too late. Mea Culpa. >... (adding the extra keyword) "all" was already a keyword in Ada 83, so I guess you mean "adding it to the syntax for access types". >..., but sometimes > there just isn't a good solution. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-17 21:31 ` Robert A Duff @ 2014-02-19 0:53 ` Randy Brukardt 2014-02-19 22:22 ` Robert A Duff 0 siblings, 1 reply; 16+ messages in thread From: Randy Brukardt @ 2014-02-19 0:53 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcc38jhl93l.fsf@shell01.TheWorld.com... > adambeneschan@gmail.com writes: > >> To expound on this a bit, since you mentioned you were overwhelmed by >> the complexity of the language: This particular inconsistency is there >> because of backward compatibility. Ada 83 did not have access types >> that could point to variables, nor did it have anonymous access types. >> Those were added in Ada 95. The Ada 95 designers decided that since >> Ada 83 access types didn't have to be implemented as addresses, it was >> necessary to have some way to distinguish between an access type that >> could point to a variable and an access type that was required to >> point to something allocated with "new"; in order not to break >> existing Ada 83 programs, the "access all" type was added, which I'm >> sure they hated having to do... > > We didn't have to do it, and Tucker didn't want to do it, but I > convinced him it was a good idea. I later realized I was wrong, > too late. Mea Culpa. Fascinating. I wouldn't consider that wrong; the problem is the inconsistency with anonymous access types (which would be easily solved by not introducing them in the first place. ;-). What Ada calls general access and pool-specific access types ought to be separated somehow. Requiring the representation of all access types to be the same would force pool-specific types to have a worse representation than otherwise necessary -- on the U2200, general access types had to include byte-pointers (for C compatibility), but pool-specific types could assume word alignment. That was a substantial performance difference. Janus/Ada also uses stronger checking on pool-specific types (for an access type using the standard pool, if the value isn't inside the pool, we raise an exception rather than trash memory). Can't do that for general access types. I suppose we could have used an aspect for the difference (if we had had aspects in 1993), but having legality depend on aspects is always a bit dodgy. Randy. Randy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-19 0:53 ` Randy Brukardt @ 2014-02-19 22:22 ` Robert A Duff 2014-02-20 0:34 ` Randy Brukardt 0 siblings, 1 reply; 16+ messages in thread From: Robert A Duff @ 2014-02-19 22:22 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Fascinating. I wouldn't consider that wrong; the problem is the > inconsistency with anonymous access types (which would be easily solved by > not introducing them in the first place. ;-). What Ada calls general access > and pool-specific access types ought to be separated somehow. I agree that there is some value in distinguishing general from pool-specific access types. But it comes at a cost in language complexity -- we commonly see programmers getting confused by it. So I ended up concluding that the language would be better off (simpler) if all access types were general, and you can't say "access all". I also agree that the inconsistency with anonymous access types exacerbates the problem. Anonymous access types should be a simple short-hand for what you get if you declare a named access type in the usual place. Unfortunately, they have all sorts of magical properties (coextensions, dynamic accessibility, etc). The term "pool-specific" is a misnomer, by the way. That's also my fault -- I was momentarily confused into thinking that a "storage pool" and a "collection" are the same thing. Perhaps they should be, but they're not in Ada. > Requiring the representation of all access types to be the same would force > pool-specific types to have a worse representation than otherwise > necessary -- on the U2200, general access types had to include byte-pointers > (for C compatibility), but pool-specific types could assume word alignment. > That was a substantial performance difference. I don't understand that. Access types don't need to be C-compatible unless you say Convention(C). And anyway, I would expect an int* on such a machine to be represented by a word-aligned address. And you can convert from pool-specific to general, so whatever your representation is, it must allow for that. > Janus/Ada also uses stronger checking on pool-specific types (for an access > type using the standard pool, if the value isn't inside the pool, we raise > an exception rather than trash memory). Can't do that for general access > types. At some efficiency cost, you can check for dangling pointers, which is even better than what you say above. Well, "better" in catching bugs, but probably a lot worse in terms of efficiency. > I suppose we could have used an aspect for the difference (if we had had > aspects in 1993), but having legality depend on aspects is always a bit > dodgy. Yes, if the distinction is to be made, I have no problem using the "access all" syntax for that. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-19 22:22 ` Robert A Duff @ 2014-02-20 0:34 ` Randy Brukardt 2014-02-20 11:07 ` Simon Wright 2014-02-20 16:11 ` Robert A Duff 0 siblings, 2 replies; 16+ messages in thread From: Randy Brukardt @ 2014-02-20 0:34 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcc8ut64uao.fsf@shell01.TheWorld.com... > "Randy Brukardt" <randy@rrsoftware.com> writes: > >> Fascinating. I wouldn't consider that wrong; the problem is the >> inconsistency with anonymous access types (which would be easily solved >> by >> not introducing them in the first place. ;-). What Ada calls general >> access >> and pool-specific access types ought to be separated somehow. > > I agree that there is some value in distinguishing general from > pool-specific access types. But it comes at a cost in language > complexity -- we commonly see programmers getting confused by it. > So I ended up concluding that the language would be better off > (simpler) if all access types were general, and you can't say > "access all". I see. > I also agree that the inconsistency with anonymous access types > exacerbates the problem. Anonymous access types should be a > simple short-hand for what you get if you declare a named > access type in the usual place. Unfortunately, they have all > sorts of magical properties (coextensions, dynamic accessibility, etc). Not just the magical properties, but also the simple fact that you can't even make them *look* the same. I wanted to allow/encourage "all" in their syntax in order that they at least *look* like general access types, making the existing syntax obsolescent. But I didn't get much support for that. So now we have the weird situation that you have to have "all" to use 'Access with a named access type, but you must NOT use "all" with an anonymous access type. Bah! > The term "pool-specific" is a misnomer, by the way. That's also my > fault -- I was momentarily confused into thinking that a "storage pool" > and a "collection" are the same thing. Perhaps they should be, but > they're not in Ada. Yeah, you got rid of the term collection in Ada 95, and we just now put it back in Ada 2012. So I think you were confused for a fairly long moment - a bit under 17 years. :-) If we had left it around, things would be better. Note that pool-specific access types are a bit safer in general, because you can (with effort, admittedly not usually done) make deallocation safe. Whereas with general access, even if you have a valid (non-dangling) access object, you can't figure out whether it is safe (and necessary) to deallocate it or if you should just drop it on the floor. And if you get that wrong, you have storage leaks or erroneous execution. At least in Ada 2012 you can create a convinient smart pointer abstraction that takes care of all of that. Probably we ought to have considered adding such a thing to the standard library. >> Requiring the representation of all access types to be the same would >> force >> pool-specific types to have a worse representation than otherwise >> necessary -- on the U2200, general access types had to include >> byte-pointers >> (for C compatibility), but pool-specific types could assume word >> alignment. >> That was a substantial performance difference. > > I don't understand that. Access types don't need to be C-compatible > unless you say Convention(C). That's true in theory, but as a practical matter trying to force alignment on I/O was too expensive to contemplate. Unfortunately, practice can screw up a lot of otherwise good ideas. > And anyway, I would expect an int* > on such a machine to be represented by a word-aligned address. You'd be wrong about that. They tried that, and no existing C code (especially Unix) would work. That's one of those functional requirements that don't show up in a language standard. They ended up making all C pointers byte-pointers. And of course we had to interface to that existing compiler, especially since our target was their POSIX emulation (as opposed to their raw OS). > And you can convert from pool-specific to general, so whatever your > representation is, it must allow for that. Yes, but that's easy: just add a byte pointer to byte 0. Converting in the other direction is not possible in general, because dropping a non-zero byte-pointer would lead to reading and writing the wrong memory. >> Janus/Ada also uses stronger checking on pool-specific types (for an >> access >> type using the standard pool, if the value isn't inside the pool, we >> raise >> an exception rather than trash memory). Can't do that for general access >> types. > > At some efficiency cost, you can check for dangling pointers, which > is even better than what you say above. Well, "better" in catching > bugs, but probably a lot worse in terms of efficiency. Right. We couldn't of course do that in our Z-80 compiler (this check was inserted essentially at day 1 for Janus/Ada, because we were having a lot of trouble with uninitialized pointers). It's probably less useful now than it once was (the heap being a fairly large part of the address space), but I've never wanted to lose functionality going forward. >> I suppose we could have used an aspect for the difference (if we had had >> aspects in 1993), but having legality depend on aspects is always a bit >> dodgy. > > Yes, if the distinction is to be made, I have no problem using the > "access all" syntax for that. But it sure would help if named and anonymous access used the same syntax. :-) Randy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-20 0:34 ` Randy Brukardt @ 2014-02-20 11:07 ` Simon Wright 2014-02-20 16:11 ` Robert A Duff 1 sibling, 0 replies; 16+ messages in thread From: Simon Wright @ 2014-02-20 11:07 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Note that pool-specific access types are a bit safer in general, > because you can (with effort, admittedly not usually done) make > deallocation safe. Whereas with general access, even if you have a > valid (non-dangling) access object, you can't figure out whether it is > safe (and necessary) to deallocate it or if you should just drop it on > the floor. And if you get that wrong, you have storage leaks or > erroneous execution. > > At least in Ada 2012 you can create a convinient smart pointer > abstraction that takes care of all of that. Probably we ought to have > considered adding such a thing to the standard library. Most of the component libraries that started life with Ada 95 include smart pointers. I must admit that my effort wasn't convenient or very safe (access values were visible, and the user was expected not to deallocate them). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Pass a serial port as user data in a GTK callback handler? 2014-02-20 0:34 ` Randy Brukardt 2014-02-20 11:07 ` Simon Wright @ 2014-02-20 16:11 ` Robert A Duff 1 sibling, 0 replies; 16+ messages in thread From: Robert A Duff @ 2014-02-20 16:11 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Yeah, you got rid of the term collection in Ada 95, and we just now put it > back in Ada 2012. So I think you were confused for a fairly long moment - a > bit under 17 years. :-) ;-) No, not that long. I don't remember when I was confused, and when I wised up, but I just didn't bother to reinstate "collection" when I wised up. > You'd be wrong about that. They tried that, and no existing C code > (especially Unix) would work. Interesting. Such C code is broken (or at least deliberately written to be nonportable). It doesn't surprise me. > But it sure would help if named and anonymous access used the same syntax. > :-) Agreed. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-02-20 16:11 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-15 23:32 Pass a serial port as user data in a GTK callback handler? hreba 2014-02-16 0:35 ` Jeffrey Carter 2014-02-16 16:18 ` hreba 2014-02-16 7:45 ` Niklas Holsti 2014-02-16 16:14 ` hreba 2014-02-16 9:20 ` Dmitry A. Kazakov 2014-02-16 16:57 ` hreba 2014-02-16 18:02 ` Dmitry A. Kazakov 2014-02-17 16:13 ` adambeneschan 2014-02-17 16:20 ` adambeneschan 2014-02-17 21:31 ` Robert A Duff 2014-02-19 0:53 ` Randy Brukardt 2014-02-19 22:22 ` Robert A Duff 2014-02-20 0:34 ` Randy Brukardt 2014-02-20 11:07 ` Simon Wright 2014-02-20 16:11 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox