* Unchecked_Deallocation vs. delete @ 2007-05-09 16:27 Maciej Sobczak 2007-05-09 17:02 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Maciej Sobczak @ 2007-05-09 16:27 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 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 ` (3 more replies) 2007-05-09 17:51 ` Martin Krischik 2007-05-09 20:54 ` Robert A Duff 2 siblings, 4 replies; 12+ messages in thread From: Dmitry A. Kazakov @ 2007-05-09 17:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 2007-05-09 17:02 ` Dmitry A. Kazakov @ 2007-05-09 20:56 ` Robert A Duff 2007-05-09 20:59 ` Keith Thompson ` (2 subsequent siblings) 3 siblings, 0 replies; 12+ messages in thread From: Robert A Duff @ 2007-05-09 20:56 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 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-10 21:10 ` Markus E Leypold 3 siblings, 0 replies; 12+ messages in thread From: Keith Thompson @ 2007-05-09 20:59 UTC (permalink / raw) "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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 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-10 21:10 ` Markus E Leypold 3 siblings, 1 reply; 12+ messages in thread From: Maciej Sobczak @ 2007-05-10 20:09 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 2007-05-10 20:09 ` Maciej Sobczak @ 2007-05-11 7:35 ` Dmitry A. Kazakov 2007-05-11 8:15 ` Maciej Sobczak 0 siblings, 1 reply; 12+ messages in thread From: Dmitry A. Kazakov @ 2007-05-11 7:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 2007-05-11 7:35 ` Dmitry A. Kazakov @ 2007-05-11 8:15 ` Maciej Sobczak 2007-05-11 16:39 ` Dmitry A. Kazakov 2007-05-16 19:25 ` Randy Brukardt 0 siblings, 2 replies; 12+ messages in thread From: Maciej Sobczak @ 2007-05-11 8:15 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 2007-05-11 8:15 ` Maciej Sobczak @ 2007-05-11 16:39 ` Dmitry A. Kazakov 2007-05-16 19:25 ` Randy Brukardt 1 sibling, 0 replies; 12+ messages in thread From: Dmitry A. Kazakov @ 2007-05-11 16:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 2007-05-11 8:15 ` Maciej Sobczak 2007-05-11 16:39 ` Dmitry A. Kazakov @ 2007-05-16 19:25 ` Randy Brukardt 1 sibling, 0 replies; 12+ messages in thread From: Randy Brukardt @ 2007-05-16 19:25 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 2007-05-09 17:02 ` Dmitry A. Kazakov ` (2 preceding siblings ...) 2007-05-10 20:09 ` Maciej Sobczak @ 2007-05-10 21:10 ` Markus E Leypold 3 siblings, 0 replies; 12+ messages in thread From: Markus E Leypold @ 2007-05-10 21:10 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 2007-05-09 16:27 Unchecked_Deallocation vs. delete Maciej Sobczak 2007-05-09 17:02 ` Dmitry A. Kazakov @ 2007-05-09 17:51 ` Martin Krischik 2007-05-09 20:54 ` Robert A Duff 2 siblings, 0 replies; 12+ messages in thread From: Martin Krischik @ 2007-05-09 17:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unchecked_Deallocation vs. delete 2007-05-09 16:27 Unchecked_Deallocation vs. delete Maciej Sobczak 2007-05-09 17:02 ` Dmitry A. Kazakov 2007-05-09 17:51 ` Martin Krischik @ 2007-05-09 20:54 ` Robert A Duff 2 siblings, 0 replies; 12+ messages in thread From: Robert A Duff @ 2007-05-09 20:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-05-16 19:25 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox