class allocators should be more encapsulated

Bruno Medeiros brunodomedeiros+spam at com.gmail
Sat Dec 30 17:38:11 PST 2006


Thomas Kuehne wrote:
> Luís Marques <luismarques at gmail.com> schrieb:
>> Frits van Bommel wrote:
>>> Yes they do take parameters, and the reason is indeed to customize how 
>>> memory is allocated. But unless they throw an exception, they do have to 
>>> actually _allocate_ some memory. If they don't throw, the return value 
>>> must be a void* to a newly-allocated piece of memory.
>>> So what I gather you're trying to do (potentially return a pointer to an 
>>> already-existing object) isn't acceptable behavior for a custom allocator.
>> You are right. If I return an existing object it will be initialized to 
>> default values. I guess that means the solution to a singleton pattern 
>> proposed by Burton Radons does not work 
>> (http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=14520)
>>
>> Still, it's a pity that "new ClassType()" cannot be used to 
>> transparently return an existing object (conditionally or not).
> 
> Where is the problem?
> 
> #
> # class Some{
> #    int dummy;
> # 
> #    this(){
> #       static Some existing;
> #       if(existing is null){
> #          existing = this;
> #       }else{
> #          this = existing;
> #       }
> #    }
> # }
> # 
> # import std.stdio;
> # 
> # int main(){
> #    Some a = new Some();
> #    Some b = new Some();
> #    a.dummy = 13;
> #    writefln("b.dummy: %s", b.dummy);
> # 
> #    return 0;
> # }
> #
> 
> If you use this pattern alot, the GC will have to do some more cleaning.
> 
> Thomas
> 

Whoa there, 'this' assigning? I feel a disturbance in the Source. I 
think that is not valid behavior, from an OO point of view. The spec 
doesn't mention anything like that (AFAIK), and from the implementation 
point of view, it's undefined behavior: From some small tests I've made 
you can only change the 'this' pointer as if it was an inout ref, if 
'this()' is not called as a parent constructor (that is, as a part of 
the construction of a subclass).
I would say this merits a bug.

---- Code: ----
import std.stdio;
import stdext.stdio;

class Foo {

   static bool first = true;
	
   this() {
     if(first){
       first = false;
       writeln("IN FIRST, this= ", cast(void *)this);
       this = new FooBaz();
       writeln("END FIRST, this= ", cast(void *)this);
     }
   }

}

class FooBar : Foo {
   int[100] iar;
   this() {
     writeln("IN FooBar(), this= ", cast(void *)this);
   }
}

class FooBaz : Foo {
   this() {
     writeln("IN FooBaz(), this= ", cast(void *)this);
   }
}


int main(char[][] args) {
	
	writeln(">>> NEW Foo:");
	Foo foo = new Foo();
	writeln("foo= ", cast(void *)foo);
	
	Foo.first = true;
	writeln(">>> NEW FooBar:");
	FooBar myfoo = new FooBar();
	writeln("#myfoo= ", cast(void *)myfoo);
	writeln("#myfoo as FooBaz ", cast(FooBaz) myfoo);
	writeln("#myfoo as FooBar ", cast(FooBar) myfoo);

	return 0;
}

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D



More information about the Digitalmars-d mailing list