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