Re: 'Valid, subtypes and constraint checking - Thanks

[Marin David Condic <nobody@noplace.com>]

O.K. From the perspective of the Standard, it may be undesirable to say 
too much or you stop someone from doing something useful in a given 
implementation environment. The down side of that, of course, is that 
you now have uncertain behavior - which rather defeats the purpose of 
having a standard, doesn't it?

If there were a "Marins_Unchecked_Deallocation ()" subprogram, it would 
most likely return a flag indicating success or a count of the number of 
bytes freed - or maybe both. I'd just like to know if my call to 
Unchecked_Deallocation did me any good or was I just wasting my time & 
creating a potential memory leak that I couldn't see because the code 
looked like it was doing what I thought it should be doing. My way, if 
an implementation can't or won't reclaim the storage, I know that this 
happened. The ARM way, you have no clue if its any good except if the 
vendor documented what it does (and you could find it in the document!) 
The ARM way could also lead to non-portability, but my way would at 
least give the programmer a shot at writing portable code.

MDC


Robert I. Eachus wrote:
> 
> First, let me agree that compilers should try to document what they do 
> in this area.  But it is harder than you might think.  For example, what 
> if I try to free a task that is not yet terminated?  Perhaps the current 
> task that is executing the call to Unchecked_Deallocation.  Right now a 
> compiler can refuse to do anything in such a case, and in fact, is 
> expected to do nothing.  (It can free SOME of the memory associated with 
> the task, but not all.)
> 
> Or a different example.  If your compiler does provide a garbage 
> collected heap, do you want Free to trump the garbage collector?  (This 
> would mean that the only time Free did something was when the object was 
> still accessable...ouch!
> 
> A better example is probably reference counted storage.  There you want 
>   a call to Free to decrement the count by one, and release the storage 
> if the count is equal to zero.
> 
> Or let's imagine a 64-bit address space on a virtual memory machine. 
> There could be a clever implementation of the heap which keeps a list of 
>  space that has been freed on pages that are currently non-resident. The 
> memory manager could also decide to materialize a new page of memory for 
> an allocation instead of paging in a page that has some free space, 
> etc.  Reasonable implementation of a heap?  Sure.  Should an Ada 
> compiler be allowed to use such a heap on a system that provides it?  Of 
> course.
> There are other cases, but I think you get the picture.  The reference 
> manual is careful not to say too much.  Vendor documentation can and 
> should be much more forthcoming.
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================