J
Jonan
Hello,
For several reasons I want to replace the built-in memory management with
some custom built. The mem management itlsef is not subject to my question -
it's ok to the point that I have nice and working allocation deallocation
routines. However, I don't want to loose the nice extras of new operator,
like - constructor calling, typecasting the result, keeping the array size,
etc.
For another bunch of reasons, outside this scope I want the memory
management to be global, and not per-class.
So it seemed pretty obvious to me that I could overload the global new
operator and do the work. And here start the series of problems with
mutually exclusive solutions:
- When I try to use STL they all refer to my new and delete operators. This
by itself is not bad, BUT. My memory manager (so to say) is static variable
(singleton based implemetantion) and so it has some lifecyle. Unfortunetely
some static variable in STL - like 'locale'-s managent have longer life and
at some points of program finish it refers to some memory that my manager
has already freed. Since I cannot make my object to live longer than STL's -
this leaded to different approach:
- I tried to overload the new operator in an unique way - i.e. with some
useless parameter to prevent STL from using it. so far so good. But
overloading delete operator in such a manner is not possible, since it does
not accept additional parameters. So I came up with solution in which for
allocation I use my custom made new operator and for deallocation - a
function call. With macroses it could look nice. But here comes the next
problem.
- Except deallocation delete operator calls destructors. This, by itself is
not a problem, BUT. For example on VC7 compiler the new[] operator allocated
sizeof(size_t) bytes more at the beginning to put the array size there and
__returns the pointer AFTER those sizeof(size_t) bytes__. Even that is not
SO bad. But when we add two more facts - (1) when the type allocated has no
destructor the new operator does NOT allocate that extra storage, (2) none
of the above stays in the C++ standard. So implementing delete[] on you own
involves knowledge whether passed type has destructor or not. And again -
this is pretty compiler specific solution if there is any at all.
Please, if anybody sees some mistake or misjudgement in my observation or
has an idea how I can workaround this and make it possible to use new and
delete without rewriting tons of automatic code - give my an advice.
Thank you in advance,
-Jonan
For several reasons I want to replace the built-in memory management with
some custom built. The mem management itlsef is not subject to my question -
it's ok to the point that I have nice and working allocation deallocation
routines. However, I don't want to loose the nice extras of new operator,
like - constructor calling, typecasting the result, keeping the array size,
etc.
For another bunch of reasons, outside this scope I want the memory
management to be global, and not per-class.
So it seemed pretty obvious to me that I could overload the global new
operator and do the work. And here start the series of problems with
mutually exclusive solutions:
- When I try to use STL they all refer to my new and delete operators. This
by itself is not bad, BUT. My memory manager (so to say) is static variable
(singleton based implemetantion) and so it has some lifecyle. Unfortunetely
some static variable in STL - like 'locale'-s managent have longer life and
at some points of program finish it refers to some memory that my manager
has already freed. Since I cannot make my object to live longer than STL's -
this leaded to different approach:
- I tried to overload the new operator in an unique way - i.e. with some
useless parameter to prevent STL from using it. so far so good. But
overloading delete operator in such a manner is not possible, since it does
not accept additional parameters. So I came up with solution in which for
allocation I use my custom made new operator and for deallocation - a
function call. With macroses it could look nice. But here comes the next
problem.
- Except deallocation delete operator calls destructors. This, by itself is
not a problem, BUT. For example on VC7 compiler the new[] operator allocated
sizeof(size_t) bytes more at the beginning to put the array size there and
__returns the pointer AFTER those sizeof(size_t) bytes__. Even that is not
SO bad. But when we add two more facts - (1) when the type allocated has no
destructor the new operator does NOT allocate that extra storage, (2) none
of the above stays in the C++ standard. So implementing delete[] on you own
involves knowledge whether passed type has destructor or not. And again -
this is pretty compiler specific solution if there is any at all.
Please, if anybody sees some mistake or misjudgement in my observation or
has an idea how I can workaround this and make it possible to use new and
delete without rewriting tons of automatic code - give my an advice.
Thank you in advance,
-Jonan