C++ is love
-
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
-
Only use code that runs as expected on the [DeathStation 9000](https://enacademic.com/dic.nsf/enwiki/2748465)!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
(fill in clever retort of your choice) Ravings en masse^
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
go ahead. my C++ is rusty so I'm sure there's stuff to be improved.
Real programmers use butterflies
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.
-
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
-
W∴ Balboos, GHB wrote:
I'd presume it used the stack for memory.
Yep, exactly. I had the habit of making objects "stackable" whenever possible, for example strings had fixed size straight into the struct, so the whole object was a single contiguous dataspace easily allocatable in the stack and passed around with a memcpy. Of course it isn't alwasy the best option but I like it when it is.
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
-
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.
-
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
-
I had a programmer who was notorious for declaring char somestr[256]; and RETURNING somestr out of the function to be used by others. "But it runs fine in the debugger" was his last refrain... LOL
declaring it on the stack? ouch. I only return char*s from functions if I'm using some kind of memory management scheme that allows for it. Unless you implement one C and C++ ... doesn't. I can't judge people too badly though, considering I just got schooled on using leading underscores in my local member names (a habit I picked up from C#) But still, you should understand scoping if you're going to get paid to code in the thing.
Real programmers use butterflies
-
(fill in clever retort of your choice) Ravings en masse^
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
[
W∴ Balboos, GHB wrote:
(fill in clever retort of your choice)
Amazon.co.uk : glass retort](https://www.amazon.co.uk/s?k=glass+retort&hvadid=80401819685055&hvbmt=be&hvdev=c&hvqmt=e&tag=mh0a9-21&ref=pd_sl_7xksutbpbn_e)[^]
-
Only use code that runs as expected on the [DeathStation 9000](https://enacademic.com/dic.nsf/enwiki/2748465)!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
[
W∴ Balboos, GHB wrote:
(fill in clever retort of your choice)
Amazon.co.uk : glass retort](https://www.amazon.co.uk/s?k=glass+retort&hvadid=80401819685055&hvbmt=be&hvdev=c&hvqmt=e&tag=mh0a9-21&ref=pd_sl_7xksutbpbn_e)[^]
That retort is a better retort than I had thought of retorting.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
go ahead. my C++ is rusty so I'm sure there's stuff to be improved.
Real programmers use butterflies
- 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 checkmemory_resourceclass/header
- ditch the
-
- 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 checkmemory_resourceclass/header
- 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
- ditch the
-
- 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
- you don't want to introduce bunch of names from
stdinto 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 toMemoryPooland 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;-constis needless 5)if(!TCapacity)will give you a warning (on /W4 maybe) ifTCapacityis 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 withstatic_assertand ensure that 0 is not valid value or make specialization for that cas.
-
- 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
-
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.
- gotta love C++, since rules for reserved names are even more complex that, depending on scope, case, number of underscores... 3) or
static_assertto keep it in the family language.
- gotta love C++, since rules for reserved names are even more complex that, depending on scope, case, number of underscores... 3) or
-
- you don't want to introduce bunch of names from
stdinto 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 toMemoryPooland 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;-constis needless 5)if(!TCapacity)will give you a warning (on /W4 maybe) ifTCapacityis 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 withstatic_assertand 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
- you don't want to introduce bunch of names from
-
And some more: 7) You invoke undefined behavior in `~DynamicMemoryPool` by calling
deleteoperator instead ofdelete[]8) i guesscapacity,used,nextshould beconst-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
-
whoops, and yeah your probably right. i love const and i hate const because i always forget it.
Real programmers use butterflies
- you want to disable copy and move operations (constructor and assign operation) on
StaticMemoryPooland copy operations onDynamicMemoryPool10)~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= defaultto 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).
- you want to disable copy and move operations (constructor and assign operation) on
-
- you want to disable copy and move operations (constructor and assign operation) on
StaticMemoryPooland copy operations onDynamicMemoryPool10)~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= defaultto 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
- you want to disable copy and move operations (constructor and assign operation) on
