|
Not much improvement, just a few observations:
1. Identifiers starting with underscores are reserved. If you use them then your program is non-conforming for no good reason.
2. The comparison against capacity in both the static and dynamic classes result in never being able to use the last byte of the pool: The "used()>=capacity" should be "used()>capacity". To test it instantiate a pool of 10 bytes and allocate 6. The (capacity() - used()) is then 4, but a further allocation of 4 fails. A further allocation of 3, on the other hand, succeeds and (capacity() - used()) is then 1.
3. The static pool could benefit from a #warning directive when C is too large. Right now a 8MB C when instantiating it (1024 * 1024 * 8) would almost certainly overflow the stack, and 8MB is not a lot of memory.
|
|
|
|
|
1. I thought they were only reserved for globals. I stand corrected.
2. Good catch.
3. The static pool can and often is declared as a global, making it heap/not stack, which is where it's primarily designed to go. DynamicMemoryPool is probably a better choice if you need a locally scoped pool because it always allocates from the heap.
Thanks!
Real programmers use butterflies
modified 15-Dec-20 8:36am.
|
|
|
|
|
1) gotta love C++, since rules for reserved names are even more complex that, depending on scope, case, number of underscores...
3) or static_assert to keep it in the family language.
|
|
|
|
|
1) ditch the using namespace std; in header files,
2) you don't have virtual destructor for MemoryPool and
3) if you're using C++17 you might want to check memory_resource class/header
|
|
|
|
|
1) forgive me for asking, but why? edit: whoops that was an error. if anything it was supposed to be inside the file's namespace
2) MemoryPool is an interface - a pure abstract base. what is the purpose of a virtual destructor in such a contract as it holds no resources? - never mind. I was thinking about the call chain backwards. derived classes need to have their destructor called if the base goes out of scope. i forgot. I'm rusty.
3) I'm targeting C++11 for now because reasons having to do with the platforms this is primarily for.
Real programmers use butterflies
modified 15-Dec-20 20:50pm.
|
|
|
|
|
1) you don't want to introduce bunch of names from std into client's scope, can cause all kind of nasty problems for users. C++ name lookup is complex as it is.
2) if I got a pointer to MemoryPool and tried to delete the referenced object, I would invoke undefined behavior, even thought virtual methods are strongly suggesting me that I should be able to do it
Some more points, since you said C++ is love:
4) virtual void* alloc(const size_t size)=0; - const is needless
5) if(!TCapacity) will give you a warning (on /W4 maybe) if TCapacity is 0, but
6) the bigger problem is uint8_t m_heap[TCapacity], since zero-sized arrays is not standard C++
So I would either go with static_assert and ensure that 0 is not valid value or make specialization for that cas.
|
|
|
|
|
1&2 - see my edited post
4, i use const descriptively, even if it doesn't do anything, unless there's a reason I shouldn't
5, yeah that's a nasty habit of mine
6 I introduced a static_assert to fix that in my later code.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: 4, i use const descriptively, even if it doesn't do anything, unless there's a reason I shouldn't
To whom this description is directed? Users of the interface don't not care about it. Implementer of the interface is free to leave it out when override the function, since compiler ignores const when doing overload resolution. It is just implementation thing leaking into syntax of function signature, but not really affecting it. You can keep it class implementing abstract function to prevent changes to the parameter in the function's body, but in the base class it just confusing.
|
|
|
|
|
And some more:
7) You invoke undefined behavior in ~DynamicMemoryPool by calling delete operator instead of delete[]
8) i guess capacity, used, next should be const-qualified
C++ IS LOVE 
|
|
|
|
|
whoops, and yeah your probably right. i love const and i hate const because i always forget it.
Real programmers use butterflies
|
|
|
|
|
9) you want to disable copy and move operations (constructor and assign operation) on StaticMemoryPool and copy operations on DynamicMemoryPool
10) ~StaticMemoryPool() {} don't provide user-defined special members functions if they are not really necessary and if you do have to define them because language rules deleted them, use = default to retain possible triviality of these operations
General rule is if you need to provide a single user-defined SMF, you need to provide them all. It was called rule-of-three, now it's known as rule-of-five.
Think about using clang-format and clang-tidy (they integrate well with VS these days).
|
|
|
|
|
Okay I am aware of the rule of five but I don't actually want copy and move operations to work, consequently, no move and copy operations. Currently if I try to do those things, I'm pretty sure it doesn't compile. What's wrong with that?
Real programmers use butterflies
|
|
|
|
|
Are you sure it does not compile? Copy and move operations does not produce error
Rules for which SMFs get deleted by compiler and which remain defaulted are a bit complex, so that's why it's better to be explicit about it and = delete those that you don't want and = default those that you want to keep.
The second point is to always prefer = default over {} since you retain triviality which is actual concept. Trivial type are easier to handle, subject to more optimizations and can be used in wider range of situations. It something that you probably don't need for arena allocator, so in this case it would be about habit and consistency.
|
|
|
|
|
Now that you mention it I'm not sure. I guess I should be explicit.
Real programmers use butterflies
|
|
|
|
|
raddevus wrote: How much can you sell it for?
That's capitalism, and htcw does not believe in that.
|
|
|
|
|
I'm economically agnostic. No systems devised by humans survive contact with them.
Real programmers use butterflies
|
|
|
|
|
I'm gonna reuse the heck out of this sentence.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
honey the codewitch wrote: I'm economically agnostic
that is a copout, and you know it. 
|
|
|
|
|
It's not. It's the truth. I'm married to a communist, but that doesn't make me one.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I'm married to a communist
I shudder at the thought.
|
|
|
|
|
He's nice. He likes to share, and has a fondness for bureaucracy which I find in explicable.
I'm pretty much the antithesis to that so we balance.
Still, to each their own.
Real programmers use butterflies
|
|
|
|
|
|
Then that would be an actual garbage collector, which I'm trying to avoid. 
Actually what I'm doing is kind of clever.
I allow you to allocate a "MemoryPool" on the heap or the stack, and then allocate memory from that pool. It does not allow you to delete. However, all allocated segments are always contiguous and sequential, leading to a number of performance advantages. Instead of deleting single allocations you can freeAll() to reset/recycle the entire pool and invalidate the memory therein. It's actually quite nice for a lot of basic processing scenarios. it's just inefficient for mutable data where sizes can change - which it's not designed for.
Real programmers use butterflies
|
|
|
|
|
That's what AAA games use (and maybe non-AAA too, I only know what DICE did, as I worked there) - arena allocators.
When a level starts, it allocates from its own "arena", and when the level is done, the arena is wiped.
Lessens the risk of memory leaks and gives full control and trackability of all allocations.
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
Blasphemy! Quick, fall on your knees and repent, or you will see hordes with torches and pitchforks gathering. While the .Net guys are not as fanatically religious as Holy Order of the Javaites, they could still burn you like their steaks at a stake (*).
(*) FTMS - fixed that myself.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
