is there any way for an object to make it self no longer usable? eg

class someclass {
	string somevalue;
	bool someflag;
	int somelength;
	this (value,length,flag) {
		somevalue = value;
		someflag = flag;
		somelength = length;
	}
	void modify_value(string new_value){
		somevalue = new_value;
	}
	void finalize_data(){
		//do something with data
		//make this invalid
		// eg delete this or this = null
	}
}

I don't want to use a private flag to tell weather the object is valid or not

You can encapsulate it in a wrapper, which will control access to the object and reject if necessary.

On Saturday, 19 July 2014 at 13:46:08 UTC, Kagamin wrote:
> You can encapsulate it in a wrapper, which will control access to the object and reject if necessary.

how ?
surely not by writing another class with wrapper methods for the existing one.

On Saturday, 19 July 2014 at 12:02:50 UTC, Sean Campbell wrote:
> is there any way for an object to make it self no longer usable? eg
>
> class someclass {
> 	string somevalue;
> 	bool someflag;
> 	int somelength;
> 	this (value,length,flag) {
> 		somevalue = value;
> 		someflag = flag;
> 		somelength = length;
> 	}
> 	void modify_value(string new_value){
> 		somevalue = new_value;
> 	}
> 	void finalize_data(){
> 		//do something with data
> 		//make this invalid
> 		// eg delete this or this = null
> 	}
> }
>
> I don't want to use a private flag to tell weather the object is valid or not

You do realize that if you do this then anywhere in your code you'll have to check if the object is valid before use? If the objects lifetime is "random"(because the object itself can decide when to destroy itself), then there is no way to know when it will be destroyed.

If you do this you are potentially asking for a lot of access violation errors or undefined behavior.

In any case, an easy way is to allow the object to allocate and deallocate itself.

If the object knows the ptr and size that was used to allocate itself it is trivial to deallocate itself.

http://dlang.org/phobos/core_memory.html

On Saturday, 19 July 2014 at 17:05:27 UTC, Sean Campbell wrote:
> surely not by writing another class with wrapper methods for the existing one.

If you don't want to write the class, you can write a generator for it. See BlackHole wrapper for an example.

On Saturday, 19 July 2014 at 17:28:13 UTC, Frustrated wrote:
> If you do this you are potentially asking for a lot of access violation errors or undefined behavior.

Of course, the object should not be used after destruction. The trick is to reliably diagnose it. If such uses are not intercepted, they may remain unnoticed. GC can't solve the issue, because it's not a memory resource, which is released.

You can also try class invariant.