"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!
;^D
|
