www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why will the delete keyword be removed?

reply Trass3r <un known.com> writes:
Does it really add so much complexity to the compiler that it's worth  
removing?
Jul 13 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/13/2010 03:51 PM, Trass3r wrote:
 Does it really add so much complexity to the compiler that it's worth
 removing?

It adds misconception and confusion. delete must disappear from D. Andrei
Jul 13 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:
 It adds misconception and confusion. delete must disappear from D.

Is this case important? http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=113319 Bye, bearophile
Jul 13 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/13/2010 05:15 PM, bearophile wrote:
 Andrei:
 It adds misconception and confusion. delete must disappear from D.

Is this case important? http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=113319 Bye, bearophile

I don't understand what you mean by "this case". All I'm saying is simply that all structures and algorithms of GCs are optimized for automatic bulk collections and all structures and algorithms of manual allocators are optimized for manual frees. So it is definitely not reasonable to ask one to do the job of the other. druntime's current allocator does offer a reasonably effective method of manual deallocation, but that risks at creating confusion among users who might think it's reasonable to expect that any later GC for D would have such a method. The reality is that D's current GC is rather old technology and we definitely must expect that any state-of-the-art GC added to D cannot honor manual deallocation requests. Andrei
Jul 13 2010
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 07/14/2010 12:50 AM, Andrei Alexandrescu wrote:
 On 07/13/2010 03:51 PM, Trass3r wrote:
 Does it really add so much complexity to the compiler that it's worth
 removing?

It adds misconception and confusion. delete must disappear from D. Andrei

FWIW, the current implementation of clear() has at least one problem that guarantees my not using it: the default constructor may be arbitrarily complex (for example, it may allocate an expensive resource), so running it on the dead object is not acceptable. Also, as other people mentioned, resurrecting the dead object prevents the program from failing early in case a dangling pointer to that object gets dereferenced. I'd probably want clear() to run the destructor and zero the object's memory. This way the objects the dead object may reference can be GCed even in the presence of dangling pointers the dead object. Additionally, the probability of the program failing early on a dangling pointer dereference is high because the vtable pointer is null (any virtual call is bound to fail). Or something like that.
Jul 14 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/14/2010 02:38 PM, Max Samukha wrote:
 On 07/14/2010 12:50 AM, Andrei Alexandrescu wrote:
 On 07/13/2010 03:51 PM, Trass3r wrote:
 Does it really add so much complexity to the compiler that it's worth
 removing?

It adds misconception and confusion. delete must disappear from D. Andrei

FWIW, the current implementation of clear() has at least one problem that guarantees my not using it: the default constructor may be arbitrarily complex (for example, it may allocate an expensive resource), so running it on the dead object is not acceptable.

You mean class objects, right? I agree. I think it's okay to fill the object with its stateless .init members, which would assuage the issue.
 Also, as other people mentioned, resurrecting the dead object prevents
 the program from failing early in case a dangling pointer to that object
 gets dereferenced.

There is no early failure with dangling pointers.
 I'd probably want clear() to run the destructor and zero the object's
 memory.

No, because: class A { int x = -1; float y = 0; ... } You'd want that guy to be obliterated with the proper initializers for x and y.
 This way the objects the dead object may reference can be GCed
 even in the presence of dangling pointers the dead object. Additionally,
 the probability of the program failing early on a dangling pointer
 dereference is high because the vtable pointer is null (any virtual call
 is bound to fail).

 Or something like that.

I think the vtable could remain valid. Andrei
Jul 14 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/14/2010 04:08 PM, Vladimir Panteleev wrote:
 On Wed, 14 Jul 2010 22:43:00 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 You mean class objects, right? I agree. I think it's okay to fill the
 object with its stateless .init members, which would assuage the issue.

Then that object may be in an invalid state, in cases when valid states are created by the constructor.

That is correct. This is an unavoidable consequence. It doesn't have anything to do with the existence or absence of delete. The notion of "zombie objects" that have been disposed of any resources yet still exist to avoid dangling pointers has been widely discussed in various circles. D handles the matter better than all languages I know.
 Also, what about classes which don't have a default constructor?

All classes have a state where all members are default initialized.
 It is my understanding that you are trying to add something to the
 language which would destroy an object without deallocating it (and
 deprecate everything that involves on-the-spot deallocation), in order
 to allow creating simpler and more efficient garbage collectors.

I'm not adding anything. I am removing a mistake that C++ made (i.e. conflating destruction with deallocation). And the purpose is not to assuage or help GCs. The only purpose is memory safety.
 The
 only correct solution seems to be to call the destructor, and mark the
 object instance as invalid. The release version needn't do anything, the
 debug version can stomp on the object's memory to make sure that any
 code that attempts to access the object crashes quickly. (This is
 practically the same as deallocation, as far as the user can see - the
 difference lies in that the GC doesn't do anything immediately.)

For safety there's no debug and release. It's either safe or unsafe. Adding a Boolean to each object to tell whether it was destroyed or not complicates matters without bringing a palpable benefit. Andrei
Jul 14 2010
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Andrei Alexandrescu wrote:

 Also, what about classes which don't have a default constructor?

All classes have a state where all members are default initialized.

Should that state deserve a default destructor?
 I'm not adding anything. I am removing a mistake that C++ made (i.e.
 conflating destruction with deallocation)

That makes perfect sense to me. One thing that is troubling is the fact that the destructor runs twice. Is that not important? Could double destructor call be avoided if the object received a 'default destructor' upon clear(), which is not what the programmer wrote? The reason is, the programmer's destructor has already been executed when clear() is called anyway. If the system puts the object into the .init state, shouldn't it also decide what 'default destructor' could safely be run? Perhaps empty for a class consisting merely of fundamental types... Also, how about un-branding the object upon clear()? Would that solve the double destructor call? Ali
Jul 14 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-07-14 15:43:00 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 You mean class objects, right? I agree. I think it's okay to fill the 
 object with its stateless .init members, which would assuage the issue.

That risks breaking the object's invariants. Next thing you know you'll get an assertion error in the object's invariants and will look inside your object wondering how its private state could ever have gone like that. What really happened is that somewhere far far away clear() will have been called, putting your object in an invalid state. Try to debug that! In my opinion, if you need to clear an object's state, the object itself should be designed with that in mind (probably offering a clear() method). The object should be the one to decide if it can become zombie or not, not the user. clear() is memory safe (unlike delete), but beyond that it doesn't look much less dangerous to use to me. I'm also doubtful it won't violate immutability in the presence of immutable members. Take a look at this problem for instance: class A { immutable int i; this(int i) { this.i = i; } } A a = new A(10); immutable int* i = &a.i; assert(*i == 10); clear(a); assert(*i == 10); // i is immutable, isn't it? Be sure to try it with a struct too. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 14 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/14/2010 04:47 PM, Michel Fortin wrote:
 On 2010-07-14 15:43:00 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 You mean class objects, right? I agree. I think it's okay to fill the
 object with its stateless .init members, which would assuage the issue.

That risks breaking the object's invariants. Next thing you know you'll get an assertion error in the object's invariants and will look inside your object wondering how its private state could ever have gone like that. What really happened is that somewhere far far away clear() will have been called, putting your object in an invalid state. Try to debug that!

I think you're not properly balancing the advantages and the disadvantages of the system.
 In my opinion, if you need to clear an object's state, the object itself
 should be designed with that in mind (probably offering a clear()
 method). The object should be the one to decide if it can become zombie
 or not, not the user.

That disables any guarantee that could be reliably made.
 clear() is memory safe (unlike delete), but beyond that it doesn't look
 much less dangerous to use to me. I'm also doubtful it won't violate
 immutability in the presence of immutable members. Take a look at this
 problem for instance:

 class A {
 immutable int i;

 this(int i) {
 this.i = i;
 }
 }

 A a = new A(10);
 immutable int* i = &a.i;
 assert(*i == 10);
 clear(a);
 assert(*i == 10); // i is immutable, isn't it?

 Be sure to try it with a struct too.

Good point. Andrei
Jul 14 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-07-14 17:51:27 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 In my opinion, if you need to clear an object's state, the object itself
 should be designed with that in mind (probably offering a clear()
 method). The object should be the one to decide if it can become zombie
 or not, not the user.

That disables any guarantee that could be reliably made.

(Be sure to read the conclusion at the end before starting a reply.) It might disable guaranties as to how clear() behaves, but a global clear() that works with everything breaks guarenties (invariants) an object normally offer. A broken invariant normally indicates a broken object. If clear enters the picture, a broken invariant can mean anything. I'm trying to think of the ramifications with some of my code for examples. Calling clear() on most objects that passes through the D/Objective-C bridge is going to cause a crash. This is because upon construction, those objects keep a pointer to the corresponding Objective-C object. clear() would essentially make that pointer null, as well as reduce the reference count on the Objective-C object. That's "fine", until you call a method. Such a method assume the pointer is not null, and you'll get a segfault. Now, imagine that somewhere in the Cooca framework your object is retained and a call to one of its functions is made when a user click somewhere... it could happen 10 minutes after you called clear(). If clear() was to call the default constructor after calling the constructor, that'd be more acceptable, but even there the behaviour would be quite strange in my case because a D object could become associated with two Objective-C objects (the one before the clear that still thinks it's D counterpart exists, and the new one created by the constructor). So even by calling the destructor *and* the default constructor you could end up breaking invariants of the whole system. Conclusion: I'm not really against having a clear() function somewhere, but users of this function should be aware that it might causes problems. I'd put it in the same veins as calling the destructor manually, with the interesting addition to that is that it is memory safe. It might break the immutability of immutable members, might break any system that has some expectations about the lifetime of an object, and might breaks object invariants. Clearly, it's no different than calling the destructor, except that it is memory safe (which is certainly a desirable feature). Advertise it as low-level runtime-level function that is memory-safe and we'll all be fine. (Perhaps it belongs in druntime.) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 14 2010
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 07/14/2010 10:43 PM, Andrei Alexandrescu wrote:

 There is no early failure with dangling pointers.

There is: class A { void foo() {} } class B : A { override void foo() {} } A a = new B; A a2 = a; clear(a); a2.foo(); If you reset the object state to .init, foo will succeed and the program will happily crawl on. If you zero out the object's memory, the call to foo will fail. I'd prefer the latter. The same with an interface: interface I { void foo(); } class A : I { void foo() {} } void main() { A a = new A; I i = a; clear(a); i.foo(); // would segfault } One more (rare but possible): void bar() { } class A { void function() p = &bar; void foo() { p(); } } void main() { A a = new A; A a2 = a; clear(a); a2.foo; // would segfault }
 I'd probably want clear() to run the destructor and zero the object's
 memory.

No, because: class A { int x = -1; float y = 0; ... } You'd want that guy to be obliterated with the proper initializers for x and y.

Not that I fiercely disagree but ideally I'd want it to be obliterated to an invalid but easily recognizable state. It might help to discover dangling pointer errors early. Otherwise, leaving a destroyed object in a perfectly valid state may make debugging more fun than it needs to be. In my world, clear() would run the dispose handlers, unset the memory block's BlkAttr.FINALIZE (if the object is on GC heap), call the object's destructor, destroy the monitor and zero the memory. I guess a call to rt_finalize could be used as part of this procedure. Or something like that.
Jul 15 2010
parent PercentEwe <make example.org> writes:
== Quote from Max Samukha (spambox d-coding.com)'s article
 Not that I fiercely disagree but ideally I'd want it to be obliterated
 to an invalid but easily recognizable state. It might help to discover
 dangling pointer errors early. Otherwise, leaving a destroyed object in
 a perfectly valid state may make debugging more fun than it needs to be.

You could use: class A { int guard = 0xdeadbeef; this () { guard = 0; } invariant () { assert (guard == 0); } } Really annoying, though, and it makes more sense to set the guard in the destructor. (A compiler option to do something like this automatically would be nice.)
Jul 15 2010
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 14 Jul 2010 00:50:39 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 It adds misconception and confusion. delete must disappear from D.

Such answers only leave more questions open, and won't get you much street cred :) May I suggest writing an article (or just an NG post - something you can link to for all such future questions) detailing why delete was bad, why getting rid of it was good, and if you actually used delete, what should you now use instead of it, for all use cases? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 13 2010
prev sibling next sibling parent Trass3r <un known.com> writes:
 Such answers only leave more questions open, and won't get you much  
 street cred :) May I suggest writing an article (or just an NG post -  
 something you can link to for all such future questions) detailing why  
 delete was bad, why getting rid of it was good, and if you actually used  
 delete, what should you now use instead of it, for all use cases?

Yep, might be worth an article.
Jul 13 2010
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 14 Jul 2010 22:43:00 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 You mean class objects, right? I agree. I think it's okay to fill the  
 object with its stateless .init members, which would assuage the issue.

Then that object may be in an invalid state, in cases when valid states are created by the constructor. Also, what about classes which don't have a default constructor? It is my understanding that you are trying to add something to the language which would destroy an object without deallocating it (and deprecate everything that involves on-the-spot deallocation), in order to allow creating simpler and more efficient garbage collectors. The only correct solution seems to be to call the destructor, and mark the object instance as invalid. The release version needn't do anything, the debug version can stomp on the object's memory to make sure that any code that attempts to access the object crashes quickly. (This is practically the same as deallocation, as far as the user can see - the difference lies in that the GC doesn't do anything immediately.) -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 14 2010
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 15 Jul 2010 00:33:15 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 All classes have a state where all members are default initialized.

How is that state normally reached (for classes without a default constructor)?
 It is my understanding that you are trying to add something to the
 language which would destroy an object without deallocating it (and
 deprecate everything that involves on-the-spot deallocation), in order
 to allow creating simpler and more efficient garbage collectors.

I'm not adding anything. I am removing a mistake that C++ made (i.e. conflating destruction with deallocation). And the purpose is not to assuage or help GCs. The only purpose is memory safety.

 The
 only correct solution seems to be to call the destructor, and mark the
 object instance as invalid. The release version needn't do anything, the
 debug version can stomp on the object's memory to make sure that any
 code that attempts to access the object crashes quickly. (This is
 practically the same as deallocation, as far as the user can see - the
 difference lies in that the GC doesn't do anything immediately.)

For safety there's no debug and release. It's either safe or unsafe.

So your goal is to prevent new objects from being allocated at the same address for the sake of memory safety? If so, then something like this belongs in SafeD *only*, in my opinion. We have tools (stomping, valgrind, etc.) to allow catching bugs like these. "Memory safety", especially at the cost of performance, does not belong in a compiled language that allows pointer arithmetics.
 Adding a Boolean to each object to tell whether it was destroyed or not  
 complicates matters without bringing a palpable benefit.

I meant "mark the object instance as invalid" figuratively, not using a flag anywhere. ("Marking" would mean stomping on the object in the debug version to prevent further use of the object.) Now I understand that your goal is not to allow programmers to catch bugs, it's to stop the programmers from doing anything that might involve shooting themselves in the foot. Your approach has the following problems: 1) As discussed, the objects are left in an abnormal state (T.init without any work done by constructors). I don't think you can construct such objects normally. 2) When an object was deallocated via "delete", assuming it didn't have a destructor that accessed the object instance, the object's memory was not being accessed. This means that if an object was swapped out, it wouldn't need to be swapped back in just to destroy it. Your solution undoes this. (Does performance actually count as a factor at all in your design decisions?) However, I also noticed that your approach has an interesting advantage: after an object's memory is clobbered with T.init, it can be added to a free list for fast construction (when the GC doesn't detect any references if you want safety). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 14 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, July 14, 2010 16:28:40 Vladimir Panteleev wrote:
 On Thu, 15 Jul 2010 00:33:15 +0300, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:
 All classes have a state where all members are default initialized.

How is that state normally reached (for classes without a default constructor)?

It's the state that the object is in before the constructor is called. All of the object's members are initialized to their default value or whatever value you assigned to them at their point of declaration (which must be a value which can be determined at compile time). It's not necessarily a valid state for the object, logically speaking (with regards to invariants and the like), but it's a safe state memory-wise. - Jonathan M Davis
Jul 14 2010
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 15 Jul 2010 02:46:22 +0300, Jonathan M Davis  
<jmdavisprog gmail.com> wrote:

 On Wednesday, July 14, 2010 16:28:40 Vladimir Panteleev wrote:
 On Thu, 15 Jul 2010 00:33:15 +0300, Andrei Alexandrescu

 <SeeWebsiteForEmail erdani.org> wrote:
 All classes have a state where all members are default initialized.

How is that state normally reached (for classes without a default constructor)?

It's the state that the object is in before the constructor is called. All of the object's members are initialized to their default value or whatever value you assigned to them at their point of declaration (which must be a value which can be determined at compile time). It's not necessarily a valid state for the object, logically speaking (with regards to invariants and the like), but it's a safe state memory-wise.

That was obvious and not what I really asked, but thanks anyway :) -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 14 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, July 14, 2010 16:52:24 Vladimir Panteleev wrote:
 On Thu, 15 Jul 2010 02:46:22 +0300, Jonathan M Davis
 
 <jmdavisprog gmail.com> wrote:
 On Wednesday, July 14, 2010 16:28:40 Vladimir Panteleev wrote:
 On Thu, 15 Jul 2010 00:33:15 +0300, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:
 All classes have a state where all members are default initialized.

How is that state normally reached (for classes without a default constructor)?

It's the state that the object is in before the constructor is called. All of the object's members are initialized to their default value or whatever value you assigned to them at their point of declaration (which must be a value which can be determined at compile time). It's not necessarily a valid state for the object, logically speaking (with regards to invariants and the like), but it's a safe state memory-wise.

That was obvious and not what I really asked, but thanks anyway :)

Well, then I'm afraid that I don't get what you were asking, because that's what it sounded like you were asking. - Jonathan M Davis
Jul 14 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:
 With things being put in the pre-
 constructor state by clear(), it's not as obvious what's going on when things
go 
 wrong. Ideally, you'd want things to blow up when such an object was used,
with 
 it clearly indicating that it was because you used an object which isn't 
 supposed to exist anymore.

If you want the "failfast" (http://en.wikipedia.org/wiki/Failfast ) system, then you can use the last bit of the monitor or virtual table pointer to store store a boolean that denotes the cleared state of the object. This free space is not available for structs allocated on the heap, dynamic arrays, etc, and then you have to test this bit (in nonrelease mode only?) often, this slows down code a little. Bye, bearophile
Jul 14 2010
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 15 Jul 2010 03:05:34 +0300, Jonathan M Davis  
<jmdavisprog gmail.com> wrote:

 On Wednesday, July 14, 2010 16:52:24 Vladimir Panteleev wrote:
 On Thu, 15 Jul 2010 02:46:22 +0300, Jonathan M Davis

 <jmdavisprog gmail.com> wrote:
 On Wednesday, July 14, 2010 16:28:40 Vladimir Panteleev wrote:
 On Thu, 15 Jul 2010 00:33:15 +0300, Andrei Alexandrescu

 <SeeWebsiteForEmail erdani.org> wrote:
 All classes have a state where all members are default initialized.

How is that state normally reached (for classes without a default constructor)?

It's the state that the object is in before the constructor is called. All of the object's members are initialized to their default value or

 value
 you assigned to them at their point of declaration (which must be a
 value which
 can be determined at compile time). It's not necessarily a valid state
 for the
 object, logically speaking (with regards to invariants and the like),
 but it's a
 safe state memory-wise.

That was obvious and not what I really asked, but thanks anyway :)

Well, then I'm afraid that I don't get what you were asking, because that's what it sounded like you were asking. - Jonathan M Davis

By "reaching that state" I meant a state as would be visible by code other than the object constructor or destructor. As Michel said, Andrei's proposal leaves the object in a state where its invariants could fail. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 14 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, July 14, 2010 17:42:21 Vladimir Panteleev wrote:
 By "reaching that state" I meant a state as would be visible by code other
 than the object constructor or destructor. As Michel said, Andrei's
 proposal leaves the object in a state where its invariants could fail.

Ah, okay. That state could indeed be invalid from the perspective of the code logic. It is, however, defined. So, it's a lot like floats being NAN after an error. It shouldn't happen, but if it does, the result is well-defined. The main issue, however, is how this state is seen. It's not flagged in any way, so it's not necessarily clear when an error occurs that it's due to the object having been cleared rather than it being a valid object in an unexpected state. At least with NAN, it's pretty clear that you have an error due to an operation resulting in a NAN, and you can track it down. With things being put in the pre- constructor state by clear(), it's not as obvious what's going on when things go wrong. Ideally, you'd want things to blow up when such an object was used, with it clearly indicating that it was because you used an object which isn't supposed to exist anymore. So, clear() does result in a nice, defined state - which is far better than undefined behavior - but it's not a state where tracking down the error is necessarily going to be at all obvious or simple. So, it's a step in the right direction, but I'm not sure that it's enough. - Jonathan M Davis
Jul 14 2010
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 15 Jul 2010 04:00:49 +0300, Jonathan M Davis  
<jmdavisprog gmail.com> wrote:

 Ideally, you'd want things to blow up when such an object was used, with
 it clearly indicating that it was because you used an object which isn't
 supposed to exist anymore.

I suggested this as well, by stomping on the object's memory in debug builds. Andrei has different goals. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 15 2010
prev sibling next sibling parent "Rory McGuire" <rmcguire neonova.co.za> writes:
On Thu, 15 Jul 2010 09:08:24 +0200, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 On Thu, 15 Jul 2010 04:00:49 +0300, Jonathan M Davis  
 <jmdavisprog gmail.com> wrote:

 Ideally, you'd want things to blow up when such an object was used, with
 it clearly indicating that it was because you used an object which isn't
 supposed to exist anymore.

I suggested this as well, by stomping on the object's memory in debug builds. Andrei has different goals.

Surely you can't just stomp on the memory? You'd have to keep it allocated so nothing else ends up being allocated there, and you get weird inconsistent errors, debug mode or not.
Jul 15 2010
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 15 Jul 2010 11:03:07 +0300, Rory McGuire <rmcguire neonova.co.za>  
wrote:

 On Thu, 15 Jul 2010 09:08:24 +0200, Vladimir Panteleev  
 <vladimir thecybershadow.net> wrote:

 On Thu, 15 Jul 2010 04:00:49 +0300, Jonathan M Davis  
 <jmdavisprog gmail.com> wrote:

 Ideally, you'd want things to blow up when such an object was used,  
 with
 it clearly indicating that it was because you used an object which  
 isn't
 supposed to exist anymore.

I suggested this as well, by stomping on the object's memory in debug builds. Andrei has different goals.

Surely you can't just stomp on the memory? You'd have to keep it allocated so nothing else ends up being allocated there, and you get weird inconsistent errors, debug mode or not.

If you want to keep the stomped-on object allocated to prevent that, there is no problem doing it - just don't do immediate deallocation in debug builds, and let the GC collect the object when it sees no references. However, if you want to catch dangling pointer bugs with absolute certainty, the best solution is to use tools such as Valgrind, which keep track of which memory is safe to read, etc. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 15 2010