* Allocators for anonymous access return types @ 2010-10-31 12:18 Florian Weimer 2010-10-31 12:46 ` J-P. Rosen 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2010-10-31 12:18 UTC (permalink / raw) It seems that an allocator for an anonymous accesss return type of a library-level function essentially leaks memory (unless you use garbage collection, of course). Is this really the case? I would expect such objects to be deallocated by the master for the expression where the return type occurs. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Allocators for anonymous access return types 2010-10-31 12:18 Allocators for anonymous access return types Florian Weimer @ 2010-10-31 12:46 ` J-P. Rosen 2010-10-31 13:23 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: J-P. Rosen @ 2010-10-31 12:46 UTC (permalink / raw) Le 31/10/2010 13:18, Florian Weimer a �crit : > It seems that an allocator for an anonymous accesss return type of a > library-level function essentially leaks memory (unless you use > garbage collection, of course). Is this really the case? I would > expect such objects to be deallocated by the master for the expression > where the return type occurs. Yes, but I *guess* the master is library-level, therefore it's deallocated only when the problem terminates. I said "I guess", because few people (even in the ARG!) really understand accessibility levels. Moreover, there is no way to unchecked-deallocate anonymous access types. Conclusion: don't use them, especially with allocators. Use named types as much as possible. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Adalog a d�m�nag� / Adalog has moved: 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Allocators for anonymous access return types 2010-10-31 12:46 ` J-P. Rosen @ 2010-10-31 13:23 ` Florian Weimer 2010-10-31 14:10 ` J-P. Rosen 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2010-10-31 13:23 UTC (permalink / raw) * J-P. Rosen: > Le 31/10/2010 13:18, Florian Weimer a �crit : >> It seems that an allocator for an anonymous accesss return type of a >> library-level function essentially leaks memory (unless you use >> garbage collection, of course). Is this really the case? I would >> expect such objects to be deallocated by the master for the expression >> where the return type occurs. > Yes, but I *guess* the master is library-level, therefore it's > deallocated only when the problem terminates. Actually, it seems to be unspecified. It is curious because for unconstrained objects not created by allocators, the life-time was clarified (I think, see my other post). > Conclusion: don't use them, especially with allocators. Use named > types as much as possible. I'm trying to write type-safe variadic function which does not heavily use the free store. With anonymous access types, it could look like this: package Variadic is type Variadic is tagged limited private; Start : constant access Variadic'Class; function "&" (Left : access Variadic'Class; Right : String) return access Variadic'Class; procedure Print (Arguments : access Variadic'Class); private type Variadic is tagged limited record Data : access String; Next : access Variadic'Class; end record; Start : constant access Variadic'Class := null; end Variadic; with Ada.Text_IO; package body Variadic is function "&" (Left : access Variadic'Class; Right : String) return access Variadic'Class is begin return new Variadic'(Data => new String'(Right), Next => Left); end "&"; procedure Print (Arguments : access Variadic'Class) is Current : access Variadic'Class := Arguments; begin while Current /= null loop Ada.Text_IO.Put_Line (Current.Data.all); Current := Current.Next; end loop; end Print; end Variadic; In this example, the allocators could use the secondary stack, I think, but they don't (with GNAT). I'm not sure if it is possible to elide the string copy, though, so this is probably not what I'm after. (My other example avoids copying, and seems to be safe according to the ARM rules, as long as you don't declare something involving the Unchecked_* types. A solution based on anonymous access types might make this violation impossible, hence my interest in them.) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Allocators for anonymous access return types 2010-10-31 13:23 ` Florian Weimer @ 2010-10-31 14:10 ` J-P. Rosen 2010-10-31 14:28 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: J-P. Rosen @ 2010-10-31 14:10 UTC (permalink / raw) Le 31/10/2010 14:23, Florian Weimer a �crit : >> Conclusion: don't use them, especially with allocators. Use named >> types as much as possible. > > I'm trying to write type-safe variadic function which does not heavily > use the free store. > > With anonymous access types, it could look like this: > > package Variadic is > > type Variadic is tagged limited private; My first reaction would be to define here: type Variadic access is access Variadic; But you mention: > (My other example avoids copying, and seems to be safe according to > the ARM rules, as long as you don't declare something involving the > Unchecked_* types. A solution based on anonymous access types might > make this violation impossible, hence my interest in them.) I don't know what you mean by Unchecked_* types. I guess you mean no use of Unchecked_Conversion? Better use a restriction then. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Adalog a d�m�nag� / Adalog has moved: 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Allocators for anonymous access return types 2010-10-31 14:10 ` J-P. Rosen @ 2010-10-31 14:28 ` Florian Weimer 0 siblings, 0 replies; 5+ messages in thread From: Florian Weimer @ 2010-10-31 14:28 UTC (permalink / raw) * J-P. Rosen: >> type Variadic is tagged limited private; > My first reaction would be to define here: > type Variadic access is access Variadic; "type Variadic_Access is access Variadic;"? It's difficult to get exception-safe code that way. Deallocating the parameters in Print is not sufficient because you leak memory when constructing one of the arguments raises an exception. > But you mention: >> (My other example avoids copying, and seems to be safe according to >> the ARM rules, as long as you don't declare something involving the >> Unchecked_* types. A solution based on anonymous access types might >> make this violation impossible, hence my interest in them.) > I don't know what you mean by Unchecked_* types. I guess you mean no use > of Unchecked_Conversion? Better use a restriction then. Oops, I was referring to the Ref type in <87fwvn51mz.fsf@mid.deneb.enyo.de> (it's called Unchecked_Parameter_Reference in the actual code, and for good reason). ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-10-31 14:28 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-10-31 12:18 Allocators for anonymous access return types Florian Weimer 2010-10-31 12:46 ` J-P. Rosen 2010-10-31 13:23 ` Florian Weimer 2010-10-31 14:10 ` J-P. Rosen 2010-10-31 14:28 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox