Eliminate class allocators and deallocators?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Oct 7 18:47:45 PDT 2009


Denis Koroskin wrote:
> On Thu, 08 Oct 2009 04:39:20 +0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Denis Koroskin wrote:
>>> On Thu, 08 Oct 2009 04:13:12 +0400, Andrei Alexandrescu 
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> Denis Koroskin wrote:
>>>>> I'm not sure you will convince people to use foo.recycle() instead 
>>>>> of foo.delete(). Not only it's slower, I believe recycling an 
>>>>> object works for hiding bugs: accessing a recycled object - 
>>>>> obviously a bug - will no longer be detected.
>>>>
>>>> Is anyone under the illusion that today there's any detection going on?
>>>>
>>>> Andrei
>>>  There is none, but it's possible. It's just not implemented.
>>
>> It's not possible if you allow actual memory reuse! Now I'm not sure I 
>> understand what you want.
>>
>> Andrei
> 
> In our custom memory management system, deallocated memory gets filled 
> with a debug data, which is checked for consistency when memory gets 
> allocated again. Any write to that memory we be noticed. Not 
> immediately, but still, it's better than nothing. Microsoft C++ debug 
> runtime does the same.
> 
> Under Windows (2000 and later) you can also mark a range of memory as 
> not accessible (by calling VirtualProtect on that memory with a 
> PAGE_NOACCESS flag). Any read/write attempt with cause an immediate 
> access violation exception. This is not widely used, probably because 
> it's slow, but when you have a memory damage (caused by modifying some 
> memory via a dangling pointer) performance is of lesser importance.
> 
> I believe similar mechanisms exist for nixes, too.

There are (anyway, page-level marking is not the right level of 
granularity).

My overall point is twofold:

1. new and delete were symmetric in C++. In D they aren't and aren't 
supposed to be symmetric. The delete keyword should be deprecated and 
the functionality of delete should be relegated to a function.

2. Mostly as a consequence of (1), class-level operators new and delete 
are misdesigned and should be eliminated. Object 
factories/pools/regions/etc. should be the way to go for custom class 
allocation.

Heck, others are shunning new and we're clinging on to it?


Andrei



More information about the Digitalmars-d mailing list