Re: Custom allocator trouble
Hello
Lance Diduck wrote:
On May 25, 12:24 pm, Dizzy <d...@roedu.net> wrote:
Hello
Because my allocation needs are very basic I do not
think I should deal with the complexity of writting a general allocator
(ie an allocator that may allocate chunks of various sized bytes alligned
for various types) but a simple one that only needs to allocate space for
a single value of a known type throughout the allocator lifetime.
The "allocate chunks" part of the code should not know anything about
alignment, other than it returns a max aligned pointer on every call.
Classes and primitives that handle arrays will handle the alignment
part for itself.
If by "max aligned pointer" you mean a pointer aligned for any access
doesn't this turns into suboptimal use of the allocation memory ? I mean
since I know at compile time that all the objects allocated will be of the
same type I should be able to use this information to get memory aligned
for that type. Getting memory aligned for any type might prove suboptimal
(ie one might need to have some padding which would waste memory).
To use a class like your "SimpleAllocator" you would do this
(Stroustrup mentions this technique in D&E)
struct SimpleAllocator{
//class "owns" a region of memory
//determined when class is constructed
SimpleAllocator(void* data, size_t len );
void* allocate(size_t n);
void deallocate(void*);
size_t max_size()const;// max contiguous block
bool operator==(SimpleAllocator const&)const;//for use
later
};
Now make a helper class
struct SimpleAllocHelper{
void * operator new(size_t n,SimpleAllocator&s){
char* r=reinterpret_cast<char*>(s.allocate(n
+sizeof(SimpleAllocator*) );
void**alloc=&(r);
alloc=&s;//store for later use
return r+sizeof(SimpleAllocator*) ;
}
Hmm, how is this returning a max aligned pointer ? As far as I see it
returns an address just after a "SimpleAllocator" object but we don't know
if that address is aligned for any type of access do we (it should be
aligned for SimpleAllocator access because it's the next SimpleAllocator in
line)? The caller won't be able to safely use the returned address with any
type.
//for exceptions
void operator delete(void* p,SimpleAllocator&s){
char* r=reinterpret_cast<char*>(p);
void adj=r-sizeof(SimpleAllocator*);
s.deallocate(adj);
}
void operator delete(void* p){
if(!p)return;
char* r=reinterpret_cast<char*>(p);
void adj=r-sizeof(SimpleAllocator* );
SimpleAllocator*a=reinterpret_cast<SimpleAllocator*>(adj);
a->deallocate(adj);
}
private:
void * operator new(size_t);//no access to default operator new
};(implement same logic for array forms of new/delete
Hmm I do not know how safe and standard compliant is to convert random
pointers to char* and do pointer arithmetic on this then convert back to
SimpleAllocator.
And it
gets even more complicated when Info is not a POD type.
stateful allocators is perhaps the most cumbersome of all the
allocators models. You will spend most of your time figuring out how
to make sure every object that needs to use a particular memory region
actually does.
For the moment I just try to solve the alignment and internal management
issues using 100% standard compliant code. And it will need to work for
non-POD types. Not being able to use new/delete isn't a big issue for now
(is more of a feature issue).
Thanks for the help.
--
Dizzy
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]