Re: Overloading class new and delete operators with parameters

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Douglas Peterson (Tergiver_at_nospam.msn.com)
Date: 01/25/05 

Date: Tue, 25 Jan 2005 12:00:16 -0500

"Tom Widmer" <tom_usenet@hotmail.com> wrote in message
news:uc9C$ugAFHA.2640@TK2MSFTNGP14.phx.gbl...
> Be careful with alignment. Shifting alignment by 4 bytes might slow down
> or even break access to any 64-bit variables you have in your object (e.g.
> long long, double, etc.). Instead you might either put the 4 bytes at the
> end of the allocation (aligned on a 4 bytes boundary), or shift the start
> of the object by 8 bytes rather than 4, to ensure better alignment.
>
> Tom

Adding the bytes at the end requires that the delete operator know its size.
That would force you to use an external map, in which case we don't need to
add anything to the object at all.

This leads me back to believing that storing the allocator pointer as a
private class member of Object is the right decision (I don't want to
maintain an external map). Since derived classes cannot access it, there
should be no issue with it becoming invalid during destruction, and because
it's a class member the compiler can work out any alignment issues. And it
even makes the source code for Object a bit less cryptic.

class Object
{
public:
    virtual ~Object() {}

    void * operator new (size_t size, Allocator * allocator, size_t extra =
0)
    {
        Object * obj = (Object*) allocator->Alloc(size + extra);
        obj->__allocator = allocator;
        return obj;
    }

    void operator delete (void * p, Allocator * allocator, size_t)
    {
        allocator->Free(p);
    }

    void operator delete (void * p)
    {
        ((Object*)p)->__allocator->Free(p);
    }

private:
    Allocator * __allocator;
};

Is it 100% safe? No, but the only way __allocator could become invalid is if
the compiler added code to mark the block of memory in between call to the
destructor and the call to the delete operator. I can't see this happening
in any compiler simply because it's common practice to create variable
length structures (as the 'extra' parameter here allows) which the compiler
cannot be aware of at compile time. Sure it can mark what bytes it knows
about, but why would it?

Some debug implementations of free() will mark memory that has been deleted,
but that of course takes place inside the free() call and is not an issue
here.

I think I can live with the odds on this one.

Relevant Pages

  • Re: Isnt it time there was a standard align statement?
    ... C language actually allowed some portable control over data ... /* per member alignment (obviously padding before the first ... fatal with compiler specific switches - and that's no business of the ...
    (comp.lang.c)
  • Re: I am learning C: a little problem with a simple source code
    ... One can turn off particular warnings with this compiler, ... For each driver, if the size is unsupported, the driver can give up. ... Similarly, it'd be nice to pass a 'size_t' for the alignment, too. ...
    (comp.lang.c)
  • Re: register attribute
    ... The point of dynamic data structures is that the mass of ... I recall the alignment problem being reported in Byte ... > the programmer will know but the compiler won't. ...
    (comp.lang.fortran)
  • Re: Isnt it time there was a standard align statement?
    ... same method of specifying data alignment. ... The hardware is the same, ... fatal with compiler specific switches - and that's no business of the ... A vector math portability library. ...
    (comp.lang.c)
  • Re: How does C cope if architecture doesnt address bytes?
    ... >>which the malloc() call occurs, figure out the type of the pointer which ... alignment in the implementation, rather than in either part of it. ... compiler and library are so strictly separate that there is no ... # The pointer returned if the allocation succeeds is suitably aligned so ...
    (comp.lang.c)