RFC on range design for D2

Leandro Lucarella llucax at gmail.com
Tue Sep 9 07:03:03 PDT 2008


Andrei Alexandrescu, el  8 de septiembre a las 19:24 me escribiste:
> 1.5) Allow object ownership but also make the behavior of incorrect code 
> well-defined so it can be reasoned about, reproduced, and debugged.
> 
> That's why I think an Array going out of scope should invoke destructors for its 
> data, and then obliterate contents with ElementType.init. That way, an 
> Array!(File) will properly close all files AND put them in a "closed" state. At 
> the same time, the memory associated with the array will NOT be deallocated, so 
> a range surviving the array will never crash unrelated code, but instead will 
> see closed files all over.

Why is so bad that the program crashes if you do something wrong? For how
long you will have the memory "alive", it will use "regular" GC semantics
(i.e., when nobody points at it anymore)? In that case, leting the
programmer leave dangling pointers to data that should be "dead" without
crashing, wouldn't make easier to introduce memory leaks?

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Did you know the originally a Danish guy invented the burglar-alarm
unfortunately, it got stolen


More information about the Digitalmars-d-announce mailing list