Unchecked_Deallocation vs. delete

Unchecked_Deallocation vs. delete

[Maciej Sobczak]

What's the benefit of Unchecked_Deallocation as a generic library
procedure vs. built-in deallocation operator like delete in C++?

The disadvantage, as far as I perceive it, is that it breaks the
symmetry that should be expected with regard to the allocation
operation. If "new" is built-in, then the deallocation should be built-
in as well. Making it a generic library procedure just makes more work
for the programmers for no clear reason.

What clear reason am I missing?

--
Maciej Sobczak
http://www.msobczak.com/

Re: Unchecked_Deallocation vs. delete

[Dmitry A. Kazakov]

On 9 May 2007 09:27:25 -0700, Maciej Sobczak wrote:

> What's the benefit of Unchecked_Deallocation as a generic library
> procedure vs. built-in deallocation operator like delete in C++?

To make it harder to use.

> The disadvantage, as far as I perceive it, is that it breaks the
> symmetry that should be expected with regard to the allocation
> operation. If "new" is built-in, then the deallocation should be built-
> in as well.

The symmetry is apparent. Pointers can be constructed using two methods:
new T and X'Access. Further even if a pointer is constructed with new, it
can be subject of GC.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Unchecked_Deallocation vs. delete

[Martin Krischik]

Maciej Sobczak wrote:

> What's the benefit of Unchecked_Deallocation as a generic library
> procedure vs. built-in deallocation operator like delete in C++?
> 
> The disadvantage, as far as I perceive it, is that it breaks the
> symmetry that should be expected with regard to the allocation
> operation. If "new" is built-in, then the deallocation should be built-
> in as well. Making it a generic library procedure just makes more work
> for the programmers for no clear reason.
> 
> What clear reason am I missing?

Yes, Ada was designed to use garbage collected. Only the idea did not work
out as the embedded market does not like garbage collection. As a result
only the Ada compiler targeting Java or .NET are actually garbage
collected.

Now this might change and GNAT might get a collector after all. But that's
just rumors but I for once would love it. There are still those little
memroy blocks passed between tasks in AdaCL which are little dogy.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Unchecked_Deallocation vs. delete

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> What's the benefit of Unchecked_Deallocation as a generic library
> procedure vs. built-in deallocation operator like delete in C++?
>
> The disadvantage, as far as I perceive it, is that it breaks the
> symmetry that should be expected with regard to the allocation
> operation. If "new" is built-in, then the deallocation should be built-
> in as well. Making it a generic library procedure just makes more work
> for the programmers for no clear reason.
>
> What clear reason am I missing?

I think you're right.  Not missing anything.

The original reason why U_D is a generic procedure is probably because
the designers of Ada 83 imagined that garbage collection would be
ubiquitous, so U_D would rarely be necesary.  I suppose they thought
that "with U_D;" would be a red flag, at the top of the package that
does such "evil" things.  Note that U_D is banished to chapter 13,
where all the other machine-dependent stuff lives.

- Bob

Re: Unchecked_Deallocation vs. delete

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> The symmetry is apparent. Pointers can be constructed using two methods:
> new T and X'Access.

Except that X'Access did not exist when this design decision was made.
In Ada  83, "new" and U_D really are symmetric.

>...Further even if a pointer is constructed with new, it
> can be subject of GC.

Right.

- Bob

Re: Unchecked_Deallocation vs. delete

[Keith Thompson]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 9 May 2007 09:27:25 -0700, Maciej Sobczak wrote:
>> What's the benefit of Unchecked_Deallocation as a generic library
>> procedure vs. built-in deallocation operator like delete in C++?
>
> To make it harder to use.
[...]

Yes.  Allocation is safe; it either succeeds or fails cleanly.
Deallocation, if you happen to deallocate the wrong thing, can fail in
arbitrarily bad ways.  Requiring you to instantiate
Unchecked_Deallocation (emphasis on "Unchecked") is intended as a
reminder that it's entirely up to *you* to get it right; if you mess
up the argument, the implementation isn't going to save you.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Unchecked_Deallocation vs. delete

[Maciej Sobczak]

On 9 Maj, 19:02, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > What's the benefit of Unchecked_Deallocation as a generic library
> > procedure vs. built-in deallocation operator like delete in C++?
>
> To make it harder to use.

Why not make a
Very_Hard_To_Use_Unchecked_Deallocation_Built_In_Operator instead?

I'm not asking about the spelling (which is ugly for purpose), but
about category.

> > The disadvantage, as far as I perceive it, is that it breaks the
> > symmetry that should be expected with regard to the allocation
> > operation. If "new" is built-in, then the deallocation should be built-
> > in as well.
>
> The symmetry is apparent. Pointers can be constructed using two methods:
> new T and X'Access.

Then put a run-time check in this Very_Hard_..._Operator.

Or, why not making separate "subtypes" of pointers? One would be a
specialization of pointers for X'Access and another for new T. You
would need to use the "subtype" for new T to deallocate, or the
compiler would spank you and the downcast to this "subtype" (if ever
needed) would be a perfect place for the run-time check.
(this is a wild idea, but seems to be more in the spirit of Ada)

> Further even if a pointer is constructed with new, it
> can be subject of GC.

So? GC does not prevent me from calling U_D or Very_..._Operator.

--
Maciej Sobczak
http://www.msobczak.com/

Re: Unchecked_Deallocation vs. delete

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 9 May 2007 09:27:25 -0700, Maciej Sobczak wrote:
>
>> What's the benefit of Unchecked_Deallocation as a generic library
>> procedure vs. built-in deallocation operator like delete in C++?
>
> To make it harder to use.

My theory is, they did it on the express purpose to antagonize
you. Someone must have had the second sight and foreseen that you
don't like generics.

Regards -- Markus

Re: Unchecked_Deallocation vs. delete

[Dmitry A. Kazakov]

On 10 May 2007 13:09:31 -0700, Maciej Sobczak wrote:

> On 9 Maj, 19:02, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> What's the benefit of Unchecked_Deallocation as a generic library
>>> procedure vs. built-in deallocation operator like delete in C++?
>>
>> To make it harder to use.
> 
> Why not make a
> Very_Hard_To_Use_Unchecked_Deallocation_Built_In_Operator instead?

Primitive operation of the access type you mean, there is no need to
introduce an operator.

> I'm not asking about the spelling (which is ugly for purpose), but
> about category.

Well, as for categories, what is the benefit of having pointers? If I
designed Ada I would make referential derived types (of the target type)
instead. Fully transparent, no ugly ".all", no predefined shallow
assignment etc.

>>> The disadvantage, as far as I perceive it, is that it breaks the
>>> symmetry that should be expected with regard to the allocation
>>> operation. If "new" is built-in, then the deallocation should be built-
>>> in as well.
>>
>> The symmetry is apparent. Pointers can be constructed using two methods:
>> new T and X'Access.
> 
> Then put a run-time check in this Very_Hard_..._Operator.

That might mean overhead on some architectures. 

> Or, why not making separate "subtypes" of pointers?

Sure, I am with you. With the storage pool considered a discriminant of the
access type, it would be easy. But look at the recent debate about
discriminated types. There is no acceptance here.

> One would be a
> specialization of pointers for X'Access and another for new T. You
> would need to use the "subtype" for new T to deallocate, or the
> compiler would spank you and the downcast to this "subtype" (if ever
> needed) would be a perfect place for the run-time check.
> (this is a wild idea, but seems to be more in the spirit of Ada)

No, IMO it is quite reasonable, but see above.

>> Further even if a pointer is constructed with new, it
>> can be subject of GC.
> 
> So? GC does not prevent me from calling U_D or Very_..._Operator.

My comment was about symmetry between new and free.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Unchecked_Deallocation vs. delete

[Maciej Sobczak]

On 11 Maj, 09:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > Why not make a
> > Very_Hard_To_Use_Unchecked_Deallocation_Built_In_Operator instead?
>
> Primitive operation of the access type you mean, there is no need to
> introduce an operator.

If there was a need to introduce 'new' as an operator...

> > I'm not asking about the spelling (which is ugly for purpose), but
> > about category.
>
> Well, as for categories, what is the benefit of having pointers? If I
> designed Ada I would make referential derived types (of the target type)
> instead.

That would be mess. Referential derived types (of the target type)
when the target type is actually a base for some other type? You mean
- pointer as a type derived from Vehicle that can refer to Cars,
Planes and Boats? That would make the pointer (OK, "referer") a
sibling of those other, concrete types. From when do we have types
asymetrically refering to their siblings in the hierarchy? Complete
mess.

> > Then put a run-time check in this Very_Hard_..._Operator.
>
> That might mean overhead on some architectures.

Then don't put the test and enjoy undefined behavior, just like with
U_D.

> > Or, why not making separate "subtypes" of pointers?
>
> Sure, I am with you. With the storage pool considered a discriminant of the
> access type, it would be easy. But look at the recent debate about
> discriminated types. There is no acceptance here.

Yes.

> >> Further even if a pointer is constructed with new, it
> >> can be subject of GC.
>
> > So? GC does not prevent me from calling U_D or Very_..._Operator.
>
> My comment was about symmetry between new and free.

OK. But even then, GC is not a package that can be just with'ed. It is
something that has some magic connections with the rest of the runtime
and as such is part of the language implementation. The same about U_D
- I still don't see why it is a library procedure. It plays an
important role in the language implementation and if its allocating
counterpart is a built-in operation, then U_D should be built-in as
well.

--
Maciej Sobczak
http://www.msobczak.com/

Re: Unchecked_Deallocation vs. delete

[Dmitry A. Kazakov]

On 11 May 2007 01:15:15 -0700, Maciej Sobczak wrote:

> On 11 Maj, 09:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> I'm not asking about the spelling (which is ugly for purpose), but
>>> about category.
>>
>> Well, as for categories, what is the benefit of having pointers? If I
>> designed Ada I would make referential derived types (of the target type)
>> instead.
> 
> That would be mess. Referential derived types (of the target type)
> when the target type is actually a base for some other type?

These are siblings.

> You mean
> - pointer as a type derived from Vehicle that can refer to Cars,
> Planes and Boats?

No. To have this it should be a pointer type to / derived from
Vehicle'Class.

(When you derive from Vehicle you obtain a member of Vehicle'Class, not the
class itself. So, no derived type knows anything about its siblings)

>>> Then put a run-time check in this Very_Hard_..._Operator.
>>
>> That might mean overhead on some architectures.
> 
> Then don't put the test and enjoy undefined behavior, just like with
> U_D.

This is what "Unchecked" stands for in Unchecked_Deallocation. Undefined
operators is in the realm of C++ (:-)).

>>>> Further even if a pointer is constructed with new, it
>>>> can be subject of GC.
>>
>>> So? GC does not prevent me from calling U_D or Very_..._Operator.
>>
>> My comment was about symmetry between new and free.
> 
> OK. But even then, GC is not a package that can be just with'ed. It is
> something that has some magic connections with the rest of the runtime
> and as such is part of the language implementation.

I think GC could be made a well-isolated package, because pointers are
typed in Ada. I don't refer to anonymous access types which are agreed
being a C-ish mess. But normal access types are named, so you can set GC at
an access type and only at it.

> The same about U_D
> - I still don't see why it is a library procedure. It plays an
> important role in the language implementation and if its allocating
> counterpart is a built-in operation, then U_D should be built-in as
> well.

If you are asking about "would be nice," then I would make both primitive
operations of the access type interface. And I certainly don't want any
more reserved dictionary words. It became a plague in Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Unchecked_Deallocation vs. delete

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
news:1178871315.928116.262190@e51g2000hsg.googlegroups.com...
> On 11 Maj, 09:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > > Why not make a
> > > Very_Hard_To_Use_Unchecked_Deallocation_Built_In_Operator instead?
> >
> > Primitive operation of the access type you mean, there is no need to
> > introduce an operator.
>
> If there was a need to introduce 'new' as an operator...

<Pedantic>
'new' is not an operatOR, it is a primitive operatION. Operators (like "+",
"abs") can be user-defined; operations (like "new", "in", ":=") cannot.
(Well, actually operators are also operations, so it's really only
operations that are not operators that cannot.)

Dmitry was just making that distinction...
</Pedantic>

Note that some operations like "new" and ":=" can have some user-defined
behavior using another mechanism (storage pools for "new", controlled types
for ":="), but that is different than being completely user-defined.
Complete redefinition would be hard for operations, because some of the
needed semantics cannot easily be modeled as a subprogram call.

                               Randy.