C++ is love
-
Quote:
Some of the references warn against its use. Simply put - know what you're doing when you do it. Don't free() it - well, duh! That's the point of using it. Beware of stack overflows. Always keep your wits about you with memory usage. Don't use in recursive functions or loops. In a loop, index the allocations into an array of pointers, or, if you want to reuse the same one, allocate it before the loop . . . just like the other memory functions. Seems standard enough - for the grownups in the room
Don't use alloca(), it's not part of the C standard.
I read that too; mentioned it somewhere in this thread. That would be like "Don't Use that Graphics Library - it's not part of the C Standard".*
"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
-
I read that too; mentioned it somewhere in this thread. That would be like "Don't Use that Graphics Library - it's not part of the C Standard".*
"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
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.
-
Would you mind if I gave you a small critique on that code?
go ahead. my C++ is rusty so I'm sure there's stuff to be improved.
Real programmers use butterflies
-
Make your own vtbls and call stack frames? Do tell. When do you find this useful? My naughtiest code changed an object's class at runtime by changing its vptr. The two classes in question had a common base class and owned other objects, so this avoided a messy deep copy and fixing pointers to the morphed object. I wonder how many OO languages could do that.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.The call stack frames can be useful for doing things like method logging frameworks The vtbl manipulation is useful if your making a library to do hardcore COM interop
Real programmers use butterflies
-
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
