comp.lang.ada
 help / color / mirror / Atom feed
From: Maciej Sobczak <see.my.homepage@gmail.com>
Subject: Re: Unchecked_Deallocation vs. delete
Date: 11 May 2007 01:15:15 -0700
Date: 2007-05-11T01:15:15-07:00	[thread overview]
Message-ID: <1178871315.928116.262190@e51g2000hsg.googlegroups.com> (raw)
In-Reply-To: <brqynpyan2fg$.1rckp7j79on2$.dlg@40tude.net>

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/




  reply	other threads:[~2007-05-11  8:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-09 16:27 Unchecked_Deallocation vs. delete Maciej Sobczak
2007-05-09 17:02 ` Dmitry A. Kazakov
2007-05-09 20:56   ` Robert A Duff
2007-05-09 20:59   ` Keith Thompson
2007-05-10 20:09   ` Maciej Sobczak
2007-05-11  7:35     ` Dmitry A. Kazakov
2007-05-11  8:15       ` Maciej Sobczak [this message]
2007-05-11 16:39         ` Dmitry A. Kazakov
2007-05-16 19:25         ` Randy Brukardt
2007-05-10 21:10   ` Markus E Leypold
2007-05-09 17:51 ` Martin Krischik
2007-05-09 20:54 ` Robert A Duff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox