Mem pool question

[Jerry Adair]

Hi,

I have been playing around with the suggestions and code shown in

http://www.parashift.com/c++-faq-lit...html#faq-11.14

regarding memory allocation/deallocation (mem pools). I think I understand
what the FAQ was getting at (emphasis on "think") so I concluded that
attempting to make a delete statement on an area of memory that was created
in a pool with the placement new operator (overloaded) would not allow me to
call an overloaded delete operator with the signature that included the pool
in the parm list, which was shown in the FAQ example. Am I correct? The
sample code is below. I hard-wired the template selector for this example
after creating a pool_alloc template class in an effort to separate the
different types of memory blocks.

// main.cpp
#include <iostream>

class MemoryPool
{
public:
void *calloc( unsigned size )
{
void *memory = malloc( size );
if( !memory ) { cout << "Out of memory!\n"; return 0; }
memset(memory, 0, size);
return memory;
}
void deallocate( void *block )
{
free( block );
}
};

template <short BLOCK_TYPE = 0>
class pool_alloc
{
public:
inline void * operator new( unsigned s, MemoryPool& p )
{ return p.calloc(s);}

// I want to call this delete
void operator delete( void *mem, MemoryPool& p )
{ if( mem ) p.deallocate( mem );}
};

class Foo : public pool_alloc<1>
{
public:
Foo():fooInt(0){};
Foo( MemoryPool& p, unsigned len ) {};
~Foo() {};

private:
int fooInt;
};

int main( void )
{
Foo *fooP;
MemoryPool p;

fooP = new(p) Foo( p, 3 );

// with this delete statement
//but don't think it's possible or even makes sense
delete fooP;

}

When I compile this code I get the error I thought I'd get:

error: no suitable `operator delete' for `Foo'

And when I add a delete operator without the MemoryPool reference in the
signature, all is well. That too makes sense to me. I don't think there's
a way to call the delete operator and have it "know about" the pool where
the alloc'd memory resides. Again, am I on the right track here?

Thanks in advance,

Jerry

[Chris Thomasson]

And when I add a delete operator without the MemoryPool reference in the

signature, all is well. That too makes sense to me. I don't think
there's a way to call the delete operator and have it "know about" the
pool where the alloc'd memory resides. Again, am I on the right track
here?

I am sorry if this response is basically way OT wrt your Standard C++
question... But for some reason, I felt the need to mention it to you.

:^0

Anyway and FWIW, you can indeed associate a block of allocated memory with
the "slab" it belongs to. This can be as simple as defining a "common value"
for your slabs state to align themselves on. More precisely, the slabs state
will be aligning themselves on boundaries that are compatible with the
"common value". Now, you can define whether the memory blocks will go after
the slab state, or before it... Now, you can grab a pointer to the slab that
a arbitrary memory block belongs to by rounding a pointer to the block up,
or down (e.g., depends on how your define block placement), to a value that
is aligned on a 'common value' boundary. Once your on the boundary you can
cast the aligned pointer to a ptr to a slabs state. Here is brief outline:

http://groups.google.com/group/comp....019dc04362be41

http://groups.google.com/group/comp....3aeaa6ebf5181f
So, technically speaking, if you use something that is analogous to the
above technique, you can use the normal signature of 'operator delete'... No
need to pass a pool pointer when you can simply round a pointer to a block
to the next, or previous "common value" boundary.
----
P.S. and, only if your interested!

I am in the middle of doing 100% complete implementation of a stack-based
allocation scheme. If your even remotely interested, go ahead keep a
periodic watch on the following thread in this group:

http://groups.google.com/group/comp....eee1f61fdbb52c
(everything is fairly low-level at this point, the user-level interface will
be arriving soon...)

Once I get to the threading aspects, I will include comp.programming.threads
in the conversation. Luckily for me this allocator is very thread-local, so
I can Standard C++ to implement most of its logic.

[Roland Pibinger]

On Wed, 14 Mar 2007 15:23:16 -0400, "Jerry Adair" wrote:

>I have been playing around with the suggestions and code shown in
http://www.parashift.com/c++-faq-lit...html#faq-11.14

regarding memory allocation/deallocation (mem pools). I think I understand
what the FAQ was getting at (emphasis on "think") so I concluded that
attempting to make a delete statement on an area of memory that was created
in a pool with the placement new operator (overloaded) would not allow me to
call an overloaded delete operator with the signature that included the pool
in the parm list, which was shown in the FAQ example. Am I correct? The
sample code is below. I hard-wired the template selector for this example
after creating a pool_alloc template class in an effort to separate the
different types of memory blocks.

// main.cpp
#include <iostream>

class MemoryPool
{
public:
void *calloc( unsigned size )
{
void *memory = malloc( size );
if( !memory ) { cout << "Out of memory!\n"; return 0; }
memset(memory, 0, size);
return memory;
}
void deallocate( void *block )
{
free( block );
}
};

template <short BLOCK_TYPE = 0>
class pool_alloc
{
public:
inline void * operator new( unsigned s, MemoryPool& p )
{ return p.calloc(s);}

// I want to call this delete
void operator delete( void *mem, MemoryPool& p )
{ if( mem ) p.deallocate( mem );}
};

class Foo : public pool_alloc<1>
{
public:
Foo():fooInt(0){};
Foo( MemoryPool& p, unsigned len ) {};
~Foo() {};

private:
int fooInt;
};

int main( void )
{
Foo *fooP;
MemoryPool p;

fooP = new(p) Foo( p, 3 );

// with this delete statement
//but don't think it's possible or even makes sense
delete fooP;

// it's possible but probably doesn't make sense
fooP->~Foo();
pool_alloc<1::operator delete (fooP, p);

Best wishes,
Roland Pibinger