From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Freeing Pointers to classwide types
Date: 1998/10/11
Date: 1998-10-11T00:00:00+00:00 [thread overview]
Message-ID: <m37ly732dz.fsf@mheaney.ni.net> (raw)
In-Reply-To: 362081E9.5CF38122@icon.fi
Niklas Holsti <nholsti@icon.fi> writes:
> On the other hand, it seems that GNAT (in WebAda) lets one specify
> a positive Storage_Size for an access type to a descendant of the
> type T, so it would seem possible for clients to use "new" for
> descendant types. Doesn't this break your approach?
There's nothing that prevents someone from declaring their own access
type.
What I was trying to do was say to the user the memory allocation and
deallocation are hidden behind primitive operations provided by the
abstraction. Somehow you have to tell the client that he isn't supposed
to call new and Unchecked_Deallocation himself.
It has been my experience that compilers obey you when you set the
storage size to 0. If a client forgets, and he does call allocator new,
then he'll get storage error. This isn't as nice as detecting the error
at compile time, but it gets the job done. (Although a good compiler
will tell you at compile-time that the allocation will raise
Storage_Error.)
I follow the philosophy that allocator new (and Unchecked_Deallocation)
are operations used only to _implement_ higher-level operations provided
by an abstraction.
It's not unlike an array or a list. Those data structures are
primitive, in the sense that they should only be used to implement
higher-level data structures. A client should never directly use a list
as a data structure.
next prev parent reply other threads:[~1998-10-11 0:00 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-09-24 0:00 Freeing Pointers to classwide types joecool
1998-09-25 0:00 ` Tom Moran
1998-09-25 0:00 ` Bob Fletcher
1998-09-25 0:00 ` Samuel Tardieu
1998-09-25 0:00 ` dennison
1998-10-09 0:00 ` Matthew Heaney
1998-10-12 0:00 ` Mats Weber
1998-10-12 0:00 ` Pat Rogers
1998-09-25 0:00 ` dewarr
1998-09-25 0:00 ` Tom Moran
1998-09-25 0:00 ` dewarr
1998-09-26 0:00 ` Tom Moran
1998-09-26 0:00 ` dewarr
1998-09-26 0:00 ` Tom Moran
1998-09-27 0:00 ` dewarr
1998-09-27 0:00 ` Tom Moran
1998-09-28 0:00 ` dewarr
1998-09-28 0:00 ` Tom Moran
1998-09-28 0:00 ` dewarr
1998-09-28 0:00 ` Tom Moran
1998-09-28 0:00 ` Tom Moran
1998-09-28 0:00 ` Brian Rogoff
1998-09-28 0:00 ` Pat Rogers
1998-09-28 0:00 ` Tom Moran
1998-09-28 0:00 ` Pat Rogers
1998-09-29 0:00 ` dewarr
1998-09-29 0:00 ` Tom Moran
1998-09-30 0:00 ` Tom Moran
1998-10-01 0:00 ` dewar
1998-10-01 0:00 ` Tom Moran
1998-10-01 0:00 ` Samuel Tardieu
1998-10-01 0:00 ` Tom Moran
1998-10-01 0:00 ` dennison
1998-10-01 0:00 ` Tucker Taft
1998-10-01 0:00 ` Tom Moran
1998-10-02 0:00 ` dewarr
1998-10-02 0:00 ` Larry Kilgallen
1998-10-02 0:00 ` dewarr
1998-10-02 0:00 ` dennison
1998-10-02 0:00 ` dewarr
1998-10-02 0:00 ` dewarr
1998-10-09 0:00 ` Matthew Heaney
1998-10-09 0:00 ` dennison
1998-10-09 0:00 ` Matthew Heaney
1998-10-01 0:00 ` dewarr
1998-10-01 0:00 ` Tom Moran
1998-10-01 0:00 ` dewarr
1998-09-28 0:00 ` dewarr
1998-09-28 0:00 ` Richard D Riehle
1998-09-28 0:00 ` Pat Rogers
1998-09-29 0:00 ` dewarr
1998-10-09 0:00 ` Matthew Heaney
1998-10-09 0:00 ` Matthew Heaney
1998-09-25 0:00 ` alan walkington
1998-09-26 0:00 ` Simon Wright
1998-10-09 0:00 ` Matthew Heaney
1998-10-09 0:00 ` Niklas Holsti
1998-10-10 0:00 ` Matthew Heaney
1998-10-11 0:00 ` Niklas Holsti
1998-10-11 0:00 ` Matthew Heaney [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-09-25 0:00 bpr5549
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox