* Prologue and epilogue aspects @ 2018-01-26 19:56 Dmitry A. Kazakov 2018-01-27 7:17 ` Randy Brukardt 0 siblings, 1 reply; 15+ messages in thread From: Dmitry A. Kazakov @ 2018-01-26 19:56 UTC (permalink / raw) While we are at [limited] controlled interfaces why not to make them safer? I would propose a simple aspect Composition for primitive procedures (including interfaces). The aspect has values: Prologue | Override (default) | Epilogue | Final procedure First (...) with Composition => Prologue; when overridden the parent type's body is called before the override. procedure Last (...) with Composition => Epilogue; when overridden the parent's body is called after successful completion of the override. procedure Always (...) with Composition => Final; when overridden the parent's body is always called after completion of the override. The exceptions from the override are re-raised after successful execution of the body. The aspect is inherited if overriding does not change it. [Variant: the aspect cannot be changed if the override does not have a full view of the type.] The aspect inherited from interfaces is overridden by the aspect inherited from a full type [diamond inheritance]. Conflicting aspects from multiple interfaces must be explicitly overridden. ---------------------------------------------------------------- Now Ada.Finalization will declare Controlled as follows: type <anonymous> is interface; procedure Initialize (Object : in out <anonymous>) is abstract with Composition => Prologue; procedure Adjust (Object : in out <anonymous>) is abstract with Composition => Prologue; procedure Finalize (Object : in out <anonymous>) abstract with Composition => Epilogue; -- -- Old code will continue "enjoying" manual calls to parent -- Initialize, Adjust, Finalize -- type Controlled is abstract new <anonymous> with private; overriding procedure Initialize (Object : in out Controlled) is null with Composition => Override; overriding procedure Adjust (Object : in out Controlled) is null with Composition => Override; overriding procedure Finalize (Object : in out Controlled) is null with Composition => Override; -- -- New code with have things as they should have been -- type Controlled_Interface is new <anonymous>; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-01-26 19:56 Prologue and epilogue aspects Dmitry A. Kazakov @ 2018-01-27 7:17 ` Randy Brukardt 2018-01-27 9:33 ` Dmitry A. Kazakov 0 siblings, 1 reply; 15+ messages in thread From: Randy Brukardt @ 2018-01-27 7:17 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:p4g15r$1s60$1@gioia.aioe.org... ... > type Controlled is abstract new <anonymous> with private; This unfortunately doesn't fix anything. An interface never can be hidden (only in the private part), and deriving a concrete type from an interface doesn't change that. We tried to define a special kind of interface that could be used in the private part in exchange for a promise never to add such an interface to a descendant of the private type. It didn't work out very well. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-01-27 7:17 ` Randy Brukardt @ 2018-01-27 9:33 ` Dmitry A. Kazakov 2018-01-29 23:08 ` Randy Brukardt 0 siblings, 1 reply; 15+ messages in thread From: Dmitry A. Kazakov @ 2018-01-27 9:33 UTC (permalink / raw) On 2018-01-27 08:17, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:p4g15r$1s60$1@gioia.aioe.org... > ... >> type Controlled is abstract new <anonymous> with private; > > This unfortunately doesn't fix anything. An interface never can be hidden > (only in the private part), and deriving a concrete type from an interface > doesn't change that. But the interface is anonymous, it cannot be referenced in any way anywhere. It is mentioned only to be inherited from by a named interface. <anonymous> / \ Controlled Controlled_Interface -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-01-27 9:33 ` Dmitry A. Kazakov @ 2018-01-29 23:08 ` Randy Brukardt 2018-01-30 8:31 ` Dmitry A. Kazakov 0 siblings, 1 reply; 15+ messages in thread From: Randy Brukardt @ 2018-01-29 23:08 UTC (permalink / raw) You mean sort of like "universal_controlled"? As previously noted, that might work for streams (and maybe pools),but controlled usually carries components along as well, so an interface (which cannot have components) is a bad match. Randy. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:p4hh1n$1qao$1@gioia.aioe.org... > On 2018-01-27 08:17, Randy Brukardt wrote: >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:p4g15r$1s60$1@gioia.aioe.org... >> ... >>> type Controlled is abstract new <anonymous> with private; >> >> This unfortunately doesn't fix anything. An interface never can be hidden >> (only in the private part), and deriving a concrete type from an >> interface >> doesn't change that. > > But the interface is anonymous, it cannot be referenced in any way > anywhere. It is mentioned only to be inherited from by a named interface. > > <anonymous> > / \ > Controlled Controlled_Interface > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-01-29 23:08 ` Randy Brukardt @ 2018-01-30 8:31 ` Dmitry A. Kazakov 2018-01-30 22:02 ` Randy Brukardt 0 siblings, 1 reply; 15+ messages in thread From: Dmitry A. Kazakov @ 2018-01-30 8:31 UTC (permalink / raw) On 30/01/2018 00:08, Randy Brukardt wrote: > You mean sort of like "universal_controlled"? No, that would require a common base for old Ada.Finalization.Controlled and new Controlled_Interface. no that this is undesired, but it was rejected already. So the idea is an anonymous base, with the name nobody dare to call. (:-)) > As previously noted, that > might work for streams (and maybe pools),but controlled usually carries > components along as well, so an interface (which cannot have components) is > a bad match. That is an implementation detail. There is no components officially, so it is up to the compiler designer to stuck these somewhere and take care of the cases when both Ada.Finalization.Controlled and Controlled_Interface are inherited from. BTW, I am not a fan of keeping lists of controlled objects and the rules to finalize objects implicitly. IMO it is a misfeature which adds no safety, just overhead. If Controlled_Interface would drop these rules I would be only happy. Then Controlled_Interface could be an interface without messy postmortem finalization rules, which would apply only if Ada.Finalization.Controlled inherited. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-01-30 8:31 ` Dmitry A. Kazakov @ 2018-01-30 22:02 ` Randy Brukardt 2018-01-31 15:05 ` Dmitry A. Kazakov 0 siblings, 1 reply; 15+ messages in thread From: Randy Brukardt @ 2018-01-30 22:02 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:p4pah6$1gan$1@gioia.aioe.org... > On 30/01/2018 00:08, Randy Brukardt wrote: >> You mean sort of like "universal_controlled"? > > No, that would require a common base for old Ada.Finalization.Controlled > and new Controlled_Interface. no that this is undesired, but it was > rejected already. So the idea is an anonymous base, with the name nobody > dare to call. (:-)) > >> As previously noted, that >> might work for streams (and maybe pools),but controlled usually carries >> components along as well, so an interface (which cannot have components) >> is >> a bad match. > > That is an implementation detail. There is no components officially, so it > is up to the compiler designer to stuck these somewhere and take care of > the cases when both Ada.Finalization.Controlled and Controlled_Interface > are inherited from. Right, but implementing "implicit components" this way is the same work as supporting full multiple inheritance -- the components couldn't be at a fixed location in the object and you would have to use dispatching or something similar to find them. If you're going to implement that sort of thing, it would be criminal not to support it generally for all types -- and then you don't need a Controlled_Interface at all (or any other interface, for that matter). Interfaces keep the runtime cost of multiple inheritance to solely dynamic dispatching. Pretty much everything else works the same as it always did, without other overhead. But if you are going to support general multiple inheritance -- implicit or explicit -- it has a distributed cost that makes all component accesses slower (at least, anything that could be used in multiple inheritance). > BTW, I am not a fan of keeping lists of controlled objects and the rules > to finalize objects implicitly. IMO it is a misfeature which adds no > safety, just overhead. If Controlled_Interface would drop these rules I > would be only happy. Then Controlled_Interface could be an interface > without messy postmortem finalization rules, which would apply only if > Ada.Finalization.Controlled inherited. Huh? If there is no implicit finalization, then there is no need for controlled types at all, as they serve no purpose. (If you want to explicitly finalize things, you can define any subprogram for that purpose. You could even call it "Finalize". And if you want an interface like that, write it yourself.) The only reason that there is a predefined type is to get the "magic" behavior. And that behavior is designed so that every object gets finalized. An abstraction that only finalizes when it is convinient is not interesting in an Ada context - it would be riddled with holes and composition would scary. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-01-30 22:02 ` Randy Brukardt @ 2018-01-31 15:05 ` Dmitry A. Kazakov 2018-02-01 0:17 ` Randy Brukardt 0 siblings, 1 reply; 15+ messages in thread From: Dmitry A. Kazakov @ 2018-01-31 15:05 UTC (permalink / raw) On 30/01/2018 23:02, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:p4pah6$1gan$1@gioia.aioe.org... >> On 30/01/2018 00:08, Randy Brukardt wrote: >>> You mean sort of like "universal_controlled"? >> >> No, that would require a common base for old Ada.Finalization.Controlled >> and new Controlled_Interface. no that this is undesired, but it was >> rejected already. So the idea is an anonymous base, with the name nobody >> dare to call. (:-)) >> >>> As previously noted, that >>> might work for streams (and maybe pools),but controlled usually carries >>> components along as well, so an interface (which cannot have components) >>> is >>> a bad match. >> >> That is an implementation detail. There is no components officially, so it >> is up to the compiler designer to stuck these somewhere and take care of >> the cases when both Ada.Finalization.Controlled and Controlled_Interface >> are inherited from. > > Right, but implementing "implicit components" this way is the same work as > supporting full multiple inheritance -- the components couldn't be at a > fixed location in the object and you would have to use dispatching or > something similar to find them. If you're going to implement that sort of > thing, it would be criminal not to support it generally for all types -- and > then you don't need a Controlled_Interface at all (or any other interface, > for that matter). There would be no components unless Ada.Finalization.Controlled inherited. When inherited from Controlled_Interface only, all checks if to call Initialize, Finalize, Adjust will be static. No lists of objects. >> BTW, I am not a fan of keeping lists of controlled objects and the rules >> to finalize objects implicitly. IMO it is a misfeature which adds no >> safety, just overhead. If Controlled_Interface would drop these rules I >> would be only happy. Then Controlled_Interface could be an interface >> without messy postmortem finalization rules, which would apply only if >> Ada.Finalization.Controlled inherited. > > Huh? If there is no implicit finalization, then there is no need for > controlled types at all, as they serve no purpose. (If you want to > explicitly finalize things, you can define any subprogram for that purpose. "Implicit" meant called upon implicit destruction, e.g. when access types go out of the scope. That thing is not needed. I don't see other reason for the Controlled_Interface to induce hidden components. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-01-31 15:05 ` Dmitry A. Kazakov @ 2018-02-01 0:17 ` Randy Brukardt 2018-02-01 9:03 ` Dmitry A. Kazakov 0 siblings, 1 reply; 15+ messages in thread From: Randy Brukardt @ 2018-02-01 0:17 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:p4sm09$126n$1@gioia.aioe.org... > On 30/01/2018 23:02, Randy Brukardt wrote: ... >> Huh? If there is no implicit finalization, then there is no need for >> controlled types at all, as they serve no purpose. (If you want to >> explicitly finalize things, you can define any subprogram for that >> purpose. > > "Implicit" meant called upon implicit destruction, e.g. when access types > go out of the scope. That thing is not needed. I don't see other reason > for the Controlled_Interface to induce hidden components. (1) Subpools and mutable types also need lists of some sort to properly do finalization. (2) The reason for the "out of scope" rules is so that Finalization can be used for resource allocation beyond simply memory management. For instance, to return device (handles) to the OS when they won't be used any more. We felt that there shouldn't be any leaks in that. (3) I think you would have to ban nested access types (that can go out of scope before program end) that designate type with parts of this kind of controlled type, lest the allocation of such objects lead to guarenteed storage leaks (one doesn't want to use Unchecked_Deallocation if they don't have to). (4) Chains for all controlled objects work best with exception handling, as it isn't necessary to enter every scope to try to clean up objects, and in particular, one doesn't have to deal with the horror of partially initialized objects (whose initialization was interrupted by an exception). To use your static implementation, you also have to use a static implementation of exceptions, and somehow keep track of initialization of objects (and every part of such objects) in each scope. It's possible (since AdaCore has managed it), but it's fiendishly complex and definitely beyond what I can do. Adopting rules that only AdaCore has enough smarts to implement would likely ensure that there never will be any other competing implementation. I think that's bad policy; even if no other implementation appears, closing the door seems like the wrong way to go. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-02-01 0:17 ` Randy Brukardt @ 2018-02-01 9:03 ` Dmitry A. Kazakov 2018-02-01 23:47 ` Randy Brukardt 0 siblings, 1 reply; 15+ messages in thread From: Dmitry A. Kazakov @ 2018-02-01 9:03 UTC (permalink / raw) On 01/02/2018 01:17, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:p4sm09$126n$1@gioia.aioe.org... >> On 30/01/2018 23:02, Randy Brukardt wrote: > ... >>> Huh? If there is no implicit finalization, then there is no need for >>> controlled types at all, as they serve no purpose. (If you want to >>> explicitly finalize things, you can define any subprogram for that >>> purpose. >> >> "Implicit" meant called upon implicit destruction, e.g. when access types >> go out of the scope. That thing is not needed. I don't see other reason >> for the Controlled_Interface to induce hidden components. > > (1) Subpools and mutable types also need lists of some sort to properly do > finalization. No, they need not. The rule would be that all explicitly allocated objects of Controlled_Interface must be explicitly deallocated. > (2) The reason for the "out of scope" rules is so that Finalization can be > used for resource allocation beyond simply memory management. For instance, > to return device (handles) to the OS when they won't be used any more. We > felt that there shouldn't be any leaks in that. I don't see how the feature would help. The only practical case when it takes effect is when exiting from the program. At that point it does not matter anyway. > (3) I think you would have to ban nested access types (that can go out of > scope before program end) that designate type with parts of this kind of > controlled type, lest the allocation of such objects lead to guarenteed > storage leaks (one doesn't want to use Unchecked_Deallocation if they don't > have to). Of course I would let them leak. No implicit deallocation. > (4) Chains for all controlled objects work best with exception handling, as > it isn't necessary to enter every scope to try to clean up objects, and in > particular, one doesn't have to deal with the horror of partially > initialized objects (whose initialization was interrupted by an exception). It is always a controlled object that goes out the scope. All dynamically allocated controlled objects are in some kind of controlled container or other controlled structure responsible to deallocate them. Everything ultimately hooked on some scoped controlled object. That is the only sane design, IMO. > To use your static implementation, you also have to use a static > implementation of exceptions, and somehow keep track of initialization of > objects (and every part of such objects) in each scope. Then the scope can maintain a list of objects it initialized. I see no need to corrupt the object representation with list pointers in order to merely roll back the stack. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-02-01 9:03 ` Dmitry A. Kazakov @ 2018-02-01 23:47 ` Randy Brukardt 2018-02-02 6:59 ` Niklas Holsti 2018-02-02 8:46 ` Dmitry A. Kazakov 0 siblings, 2 replies; 15+ messages in thread From: Randy Brukardt @ 2018-02-01 23:47 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:p4ul5c$582$1@gioia.aioe.org... > On 01/02/2018 01:17, Randy Brukardt wrote: >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:p4sm09$126n$1@gioia.aioe.org... >>> On 30/01/2018 23:02, Randy Brukardt wrote: >> ... >>>> Huh? If there is no implicit finalization, then there is no need for >>>> controlled types at all, as they serve no purpose. (If you want to >>>> explicitly finalize things, you can define any subprogram for that >>>> purpose. >>> >>> "Implicit" meant called upon implicit destruction, e.g. when access >>> types >>> go out of the scope. That thing is not needed. I don't see other reason >>> for the Controlled_Interface to induce hidden components. >> >> (1) Subpools and mutable types also need lists of some sort to properly >> do >> finalization. > > No, they need not. The rule would be that all explicitly allocated objects > of Controlled_Interface must be explicitly deallocated. Yes, but you need a list to explicitly deallocate a subpool (as there are many objects in the subpool). Or you could just ban the use of subpools, but that's madness. >> (2) The reason for the "out of scope" rules is so that Finalization can >> be >> used for resource allocation beyond simply memory management. For >> instance, >> to return device (handles) to the OS when they won't be used any more. We >> felt that there shouldn't be any leaks in that. > > I don't see how the feature would help. The only practical case when it > takes effect is when exiting from the program. At that point it does not > matter anyway. It does if the underlying manager is primitive (as some RTOSes are) and there is no automatic closing of handles. (That was the case on CP/M and early MS-DOS, if one left files open when a program exited, they never got closed at all. Which could lead to data loss or resource exhaustion.) >> (3) I think you would have to ban nested access types (that can go out of >> scope before program end) that designate type with parts of this kind of >> controlled type, lest the allocation of such objects lead to guarenteed >> storage leaks (one doesn't want to use Unchecked_Deallocation if they >> don't >> have to). > > Of course I would let them leak. No implicit deallocation. OK, but that's not the way Ada handles types with Storage_Size specified. I'd rather they were illegal (most of the accessibility madness comes from allowing such types, and they're nearly useless). >> (4) Chains for all controlled objects work best with exception handling, >> as >> it isn't necessary to enter every scope to try to clean up objects, and >> in >> particular, one doesn't have to deal with the horror of partially >> initialized objects (whose initialization was interrupted by an >> exception). > > It is always a controlled object that goes out the scope. All dynamically > allocated controlled objects are in some kind of controlled container or > other controlled structure responsible to deallocate them. Everything > ultimately hooked on some scoped controlled object. That is the only sane > design, IMO. > >> To use your static implementation, you also have to use a static >> implementation of exceptions, and somehow keep track of initialization of >> objects (and every part of such objects) in each scope. > > Then the scope can maintain a list of objects it initialized. I see no > need to corrupt the object representation with list pointers in order to > merely roll back the stack. That's what I called "fiendishly complex". Sure, it can be done, but you have to have a handler in every master with none trivial objects (regardless of whether there is any explicit exception handlers, of even if there can be). With the exception handing in our compiler, that would be a horrible drag on performance even if no handlers were used (state snapshots would be needed for each implicit handler, and handlers block optimizations as well, so a lot of unneeded checks wouldn't be identified). The only practical way to that is similar to the way that AdaCore does that (for both finalization and exception handling), which would be a 2-3 man year effort for any compiler vendor that isn't already using that scheme (so far as I know, that's most of the non-AdaCore vendors). And I doubt that even the AdaCore scheme quite matches to your goals. Plus the lack of safety (there now are many ways to get skip finalization on objects), I don't see anyone being very interested. It makes more sense, honestly, to support full multiple inheritance. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-02-01 23:47 ` Randy Brukardt @ 2018-02-02 6:59 ` Niklas Holsti 2018-02-02 22:20 ` Randy Brukardt 2018-02-02 8:46 ` Dmitry A. Kazakov 1 sibling, 1 reply; 15+ messages in thread From: Niklas Holsti @ 2018-02-02 6:59 UTC (permalink / raw) On 18-02-02 01:47 , Randy Brukardt wrote: [about finalization, etc., with Dmitry A. Kazakov] > The only practical way to that is similar to the way that AdaCore does that > (for both finalization and exception handling), [...] > > And I doubt that even the AdaCore scheme quite matches to your goals. Plus > the lack of safety (there now are many ways to get skip finalization on > objects), I ask for clarification: do you mean that AdaCore's finalization methods allow finalization to be skipped (which would be bad), or that skips could happen if Dmitry's suggestions were to be adopted? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-02-02 6:59 ` Niklas Holsti @ 2018-02-02 22:20 ` Randy Brukardt 0 siblings, 0 replies; 15+ messages in thread From: Randy Brukardt @ 2018-02-02 22:20 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:fdighkFpkguU1@mid.individual.net... > On 18-02-02 01:47 , Randy Brukardt wrote: > > [about finalization, etc., with Dmitry A. Kazakov] > >> The only practical way to that is similar to the way that AdaCore does >> that >> (for both finalization and exception handling), [...] >> >> And I doubt that even the AdaCore scheme quite matches to your goals. >> Plus >> the lack of safety (there now are many ways to get skip finalization on >> objects), > > I ask for clarification: do you mean that AdaCore's finalization methods > allow finalization to be skipped (which would be bad), or that skips could > happen if Dmitry's suggestions were to be adopted? Only if Dmitry's suggestions were to be adopted. AdaCore uses lists in some cases, Dmitry wanted to get rid of those cases by saying that they don't finalize. So far as I'm aware, GNAT does the right thing for Ada 2012 in every case. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-02-01 23:47 ` Randy Brukardt 2018-02-02 6:59 ` Niklas Holsti @ 2018-02-02 8:46 ` Dmitry A. Kazakov 2018-02-02 9:31 ` Niklas Holsti 1 sibling, 1 reply; 15+ messages in thread From: Dmitry A. Kazakov @ 2018-02-02 8:46 UTC (permalink / raw) On 02/02/2018 00:47, Randy Brukardt wrote: > Yes, but you need a list to explicitly deallocate a subpool (as there are > many objects in the subpool). Or you could just ban the use of subpools, but > that's madness. If anybody wanted a sub-pool he would be responsible to make them work with his objects. It is a stupid design anyway. When I must care about bulk deallocation I must be even more about bulk finalization. >> I don't see how the feature would help. The only practical case when it >> takes effect is when exiting from the program. At that point it does not >> matter anyway. > > It does if the underlying manager is primitive (as some RTOSes are) and > there is no automatic closing of handles. (That was the case on CP/M and > early MS-DOS, if one left files open when a program exited, they never got > closed at all. Which could lead to data loss or resource exhaustion.) I would never implement it that way. I don't know who would. If the OS does not collect dead resources, a responsible developer would design a resource manager for that, because most likely the OS handles would not work the way you described. There will be some obscure limitations regarding sharing them, contexts where you can create/release them, etc. The puny implicit finalization won't work anyway. >> Of course I would let them leak. No implicit deallocation. > > OK, but that's not the way Ada handles types with Storage_Size specified. No problem either. It would be a bounded error. The memory would be reclaimed as for any plain type, Finalization not called, what you see is what you get. > I'd rather they were illegal (most of the accessibility madness comes from > allowing such types, and they're nearly useless). I agree. The problem is that the access type is not a proper type with interfaces and classes. The language cannot manage referential semantics introduced by the programmer. There is no chance. So, it should leave that stuff alone. Give me a plain pointer with no strings attached. And let me use a full-blown referential type in the contexts where an access type is expected. That is all, would cut the Ada RM in half, won't it? (:-)) >> Then the scope can maintain a list of objects it initialized. I see no >> need to corrupt the object representation with list pointers in order to >> merely roll back the stack. > > That's what I called "fiendishly complex". Sure, it can be done, but you > have to have a handler in every master with none trivial objects (regardless > of whether there is any explicit exception handlers, of even if there can > be). With the exception handing in our compiler, that would be a horrible > drag on performance even if no handlers were used (state snapshots would be > needed for each implicit handler, and handlers block optimizations as well, > so a lot of unneeded checks wouldn't be identified). I don't see why it so. It is trivial to allocate a list head in front of the stack allocated object rather than inside it. > The only practical way to that is similar to the way that AdaCore does that > (for both finalization and exception handling), which would be a 2-3 man > year effort for any compiler vendor that isn't already using that scheme (so > far as I know, that's most of the non-AdaCore vendors). > > And I doubt that even the AdaCore scheme quite matches to your goals. Plus > the lack of safety (there now are many ways to get skip finalization on > objects), I don't see anyone being very interested. It makes more sense, > honestly, to support full multiple inheritance. I think almost all programmers are interested in safe initialization and finalization *with* rollback. This is the most important feature I can imagine. The present state when initialization and finalization is a minefield is simply unacceptable. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-02-02 8:46 ` Dmitry A. Kazakov @ 2018-02-02 9:31 ` Niklas Holsti 2018-02-02 10:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 15+ messages in thread From: Niklas Holsti @ 2018-02-02 9:31 UTC (permalink / raw) On 18-02-02 10:46 , Dmitry A. Kazakov wrote: > Give me a plain pointer with no strings attached. You want to forbid "access String" ?? :-) :-) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects 2018-02-02 9:31 ` Niklas Holsti @ 2018-02-02 10:21 ` Dmitry A. Kazakov 0 siblings, 0 replies; 15+ messages in thread From: Dmitry A. Kazakov @ 2018-02-02 10:21 UTC (permalink / raw) On 02/02/2018 10:31, Niklas Holsti wrote: > On 18-02-02 10:46 , Dmitry A. Kazakov wrote: > >> Give me a plain pointer with no strings attached. > > You want to forbid "access String" ?? > > :-) :-) BTW: type Text (Length : Natural) is access String (1..Length); type Instance (Tag : Ada.Tags.Tag) is access Object_Type'Class (Tag); -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-02-02 22:20 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-26 19:56 Prologue and epilogue aspects Dmitry A. Kazakov 2018-01-27 7:17 ` Randy Brukardt 2018-01-27 9:33 ` Dmitry A. Kazakov 2018-01-29 23:08 ` Randy Brukardt 2018-01-30 8:31 ` Dmitry A. Kazakov 2018-01-30 22:02 ` Randy Brukardt 2018-01-31 15:05 ` Dmitry A. Kazakov 2018-02-01 0:17 ` Randy Brukardt 2018-02-01 9:03 ` Dmitry A. Kazakov 2018-02-01 23:47 ` Randy Brukardt 2018-02-02 6:59 ` Niklas Holsti 2018-02-02 22:20 ` Randy Brukardt 2018-02-02 8:46 ` Dmitry A. Kazakov 2018-02-02 9:31 ` Niklas Holsti 2018-02-02 10:21 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox