Return to Answer

This is one of those 'chicken or egg' times where to get past the discovery cost you need to know already the answer, and apparently one of those where its hard to get direct specific help or info ;) In other words, this is a classic place where people get stuck, like that stretch of road with no gas stations for miles, and you forgot your phone charger. :) So...

If the goal is to measure and allocate, with the possibility of using pools, then you need to think first bout the minimum set of livable code to get started. For the sake of explanation, if you are partial to classes, you could make one class, an let that stand for a heap, or instead use a set of functions that take a handle or a heap name. Its really an issue of semantics to be honest. Next decision is new or malloc; I'm partial to malloc because many times I'm dealing with low level constructs and I know in most implementations that new calls malloc, and I don't have to worry about the complexity of overloading new, and worrying about that on all platforms. However I have many times built systems or components around overloading or hooking new. And of course the core problem or difference, is that 'new' must know the type before the allocation, where as 'malloc' doesn't care and with malloc you resolve to a type after the allocation. All that detail is to give you an idea and some context for making design decisions in these types matters :)

If the goal is to measure and allocate, with the possibility of using pools, then you need to think first bout the minimum set of livable code to get started. For the sake of explanation, if you are partial to classes, you could make one class, an let that stand for a heap, or instead use a set of functions that take a handle or a heap name. Its really an issue of semantics to be honest. Next decision is new or malloc; I'm partial to malloc because many times I'm dealing with low level constructs and I know in most implementations that new calls malloc, and I don't have to worry about the complexity of overloading new, and worrying about that on all platforms. However I have many times built systems or components around overloading or hooking new. And of course the core problem or difference, is that 'new' must know the type before the allocation, where as 'malloc' doesn't care and with malloc you resolve to a type after the allocation. All that detail is to give you an idea and some context for making design decisions in these types matters :)

You have a million choices for how you could choose to implement this. Some of those choices should revolve around both the target platforms and the overall design goals. Those considerations will break any ties, until you feel comfortable enough with different implementation costs enough to grow the design from the plat form and general design concerns first. So until then, here are some ways that wont cost you in terms of complexity (management burden) or in dealing with removal or changes if you change your mind...

You have a million choices for how you could choose to implement this. Some of those choices should revolve around both the target platforms and the overall design goals. Those considerations will break any ties, until you feel comfortable enough with different implementation costs enough to grow the design from the platform and general design concerns first. So until then, here are some ways that wont cost you in terms of complexity (management burden) or in dealing with removal or changes if you change your mind...

This is one of those 'chicken or egg' times where to get past the discovery cost you need to know already the answer, and apparently one of those where its hard to get direct specific help or info ;) In other words, this is a classic place where people get stuck, like that stretch of road with no gas stations for miles, and you forgot your phone charger. :) So...

If the goal is to measure and allocate, with the possibility of using pools, then you need to think first bout the minimum set of livable code to get started. For the sake of explanation, if you are partial to classes, you could make one class, an let that stand for a heap, or instead use a set of functions that take a handle or a heap name. Its really an issue of semantics to be honest. Next decision is new or malloc, I'm partial to malloc because many times I'm dealing with low level constructs and I know in most implementations that new calls malloc, and I don't have to worry about the complexity of overloading new, and worrying about that on all platforms. However I have many times built systems or components around overloading or hooking new. And of course the core problem or difference, is that 'new' must know the type before the allocation, where as 'malloc' doesn't care and with malloc you resolve to a type after the allocation. All that detail is to give you an idea and some context for making design decisions in these types matters :)

This is all one way to get you the bare minimum at a bare minimum cost that satisfies the requirements. It does not address allocating classes that have virtual functions if those are in scope for profiling or management, as you cant anticipate the size the c++ environment you are using needs with out overloading or hooking new, or if you are relying on the constructor in one of the odd ways that couldn't be handled by some other init function. Otherwise a stuct is a class is a arbitrary alloc and is all the same, when you cast. If you are partial to new and need the inherent virtual table or constructor semantics, then you must hook new, but that's a whole 'nother animal, which you need to really study to make sure you are doing what new needs and would have to signal your code handling new which bucket this applied to. But otherwise the above concept is the same.

If the goal is to measure and allocate, with the possibility of using pools, then you need to think first bout the minimum set of livable code to get started. For the sake of explanation, if you are partial to classes, you could make one class, an let that stand for a heap, or instead use a set of functions that take a handle or a heap name. Its really an issue of semantics to be honest. Next decision is new or malloc; I'm partial to malloc because many times I'm dealing with low level constructs and I know in most implementations that new calls malloc, and I don't have to worry about the complexity of overloading new, and worrying about that on all platforms. However I have many times built systems or components around overloading or hooking new. And of course the core problem or difference, is that 'new' must know the type before the allocation, where as 'malloc' doesn't care and with malloc you resolve to a type after the allocation. All that detail is to give you an idea and some context for making design decisions in these types matters :)

This is all one way to get you the bare minimum at a bare minimum cost that satisfies the requirements. It does not address allocating classes that have virtual functions if those are in scope for profiling or management, as you cant anticipate the size the c++ environment you are using needs for those without overloading or hooking new, or if you are relying on the constructor in one of the odd ways that couldn't be handled by some other 'init' function. Otherwise a stuct is a class is a arbitrary alloc and is all the same, when you cast. If you are partial to new and need the inherent virtual table or constructor semantics, then you must hook new, but that's a whole 'nother animal, which you need to really study to make sure you are doing what new needs and would have to signal your code thats handling new, which bucket this applied to. But otherwise the above concept is the same.