Reset class member variables

Daniel Keep daniel.keep.lists at gmail.com
Sat Sep 8 19:46:11 PDT 2007



Sean Kelly wrote:
> [snip]
>
> Or if there's some reason that the object must be re-initialized in
> place--say, to preserve its address.  One could argue that this
> necessity indicates a poor program design, but I imagine there are cases
> where it may apply.

Or you might just be dealing with thousands of frequently created and
destroyed tiny, tiny objects and yes the overhead of
allocating/deallocating *is* an issue.

Like pretty sparkly particles -- free lists are your friend! :)

> For what it's worth, this would be quite easy to accomplish if D
> supported placement new as a default construction method (rather than
> requiring the user to override operator new to do so).  Then,
> re-initializing an object would be as simple as:
> 
> this = new(this) typeof(this);
> 
> (assuming the runtime doesn't do anything too weird in _d_new)

That makes me uneasy because then you can't overload new(void*) for
anything.  Maybe...

void* inplace(TypeInfo ti, size_t size, void* custom_arg)
{
    return custom_arg;
}

this = new.inplace(this) typeof(this);

So make a special case of the unified function call syntax such that if
you have a function whose first two arguments are (TypeInfo,size_t),
then it can be called as a "member" of new.  This allows classes to
override new as necessary, whilst still providing a way to do more
general overloads.

>> And if that's the case you might want to think about making the object
>> a struct (so a value-type, allocated on the stack) anyway.

Sorry, pretty sparkly particles must persist across stack frames :(

	-- Daniel



More information about the Digitalmars-d mailing list