"Chris M. Thomasson" <no@[EMAIL PROTECTED]
> wrote in message
news:QH8Fk.39668$hX5.3465@[EMAIL PROTECTED]
>
> "Chris M. Thomasson" <no@[EMAIL PROTECTED]
> wrote in message
> news:%D8Fk.39667$hX5.14026@[EMAIL PROTECTED]
>> "Dmitriy V'jukov" <dvyukov@[EMAIL PROTECTED]
> wrote in message
>>
news:a5656716-2077-4177-97d0-340809d3959d@[EMAIL PROTECTED]
>> On Oct 2, 8:29 pm, "Chris M. Thomasson" <n...@[EMAIL PROTECTED]
> wrote:
>>
>>> > But how could I efficiently intermingle large blocks and small
blocks
>>> > from a
>>> > single reserved memory pool?
>>
>>> In one of my programs I used following scheme:
>>
>> [...]
>>
>> Please correct me if I am wrong, but it seems as if this particular
>> allocator interface would "need" to know what type it was dealing with
in
>> advance; correct? In other words, it probably could not be used to
>> overload global operator new/delete right? Or, is `derived_t' dealing
>> with internal allocator structures. Where am I going wrong here
Dmitriy?
>> You know, I was thinking about creating something special for C++. But,
I
>> am a C programmer, and felt the need to sup****t my language of choice.
>> The cool thing about C++ is that you can do exactly what you did. Also,
>> you can overload class local delete operator and have it automatically
>> return the size of the dynamic allocation be it single object or array.
>> If the user allocated an array, you simply divide this size of object
>> size, and bam you have array size. I think C++ is neat, but I have to
>> sup****t C++.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> Ummm... That last sentence should have read as:
>
> I think C++ is neat, but I have to sup****t C.
>
> ;^|
>
> [...]
>
>
>
>
> What do you think Dmitriy... Should I create pseudo general-purpose
> allocator for C++ only that is not able to overload global new/delete
> operator? It could be extremely efficient indeed if it took advantage of
> the fact that C++ can return the size of the deallocation directly to
the
> allocator. Humm... Its fairly enticing indeed!
Well, I could encourage user to no do anything like:
_____________________________________________________________
#include <cstdio>
int main() {
char* buf = new char[1234];
delete [] buf;
std::getchar();
return 0;
}
_____________________________________________________________
But instead, do something like:
_____________________________________________________________
template<std::size_t T_size>
class buf : public allocator_base<buf<T_size> > {
char mem[T_size];
};
int main() {
buf<1234>* b = new buf<1234>;
delete b;
b = new buf<1234>[5];
delete [] b;
std::getchar();
return 0;
}
_____________________________________________________________
The back-end sup****t code would be like:
_____________________________________________________________
#include <cstdio>
#include <cstdlib>
#include <new>
struct custom_allocator {
static void* allocate(std::size_t size)
throw(std::bad_alloc()) {
void* const mem = ::operator new(size);
std::printf("custom_allocator::allocate(%p, %lu)\n",
(void*)mem, (unsigned long)size);
return mem;
}
static void deallocate(void* const mem, std::size_t size)
throw() {
std::printf("custom_allocator::deallocate(%p, %lu)\n",
(void*)mem, (unsigned long)size);
::operator delete(mem);
}
};
template<typename T>
struct allocator_base {
void* operator new(std::size_t size) throw(std::bad_alloc()) {
return custom_allocator::allocate(size);
}
void* operator new[](std::size_t size) throw(std::bad_alloc()) {
return custom_allocator::allocate(size);
}
void operator delete(void* mem) throw() {
if (mem) {
custom_allocator::deallocate(mem, sizeof(T));
}
}
void operator delete [](void* mem, std::size_t size) throw() {
if (mem) {
custom_allocator::deallocate(mem, size);
}
}
};
_____________________________________________________________
Humm... AFAICT, this is pretty neat for a C guy to look at!
;^P
|
