C++ is love
-
I see you're using both
#pragma onceand#ifdef includeguards. Is that really necessary? GCC supports both, going back to at least version 4.8, so the #pragma doesn't even need to be wrapped in an #ifdef _MSC_VER. But maybe you know something I don't, or maybe you're using some other compiler that doesn't understand the #pragma? Also, picking nits, since I have nothing better to offer, I see that this is a memory pool for contrained memory environments. That must be a constrained, contained memory situation, correct? :)Keep Calm and Carry On
I used to put a test of the preprocessor in headers :
#pragma once
#ifdef HEADER_H
#error pragma once was ignored
#else
#define HEADER_H
#endifI have not used very many compilers but I never saw the error message. I use only VS now so I don't do that any more.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
I see you're using both
#pragma onceand#ifdef includeguards. Is that really necessary? GCC supports both, going back to at least version 4.8, so the #pragma doesn't even need to be wrapped in an #ifdef _MSC_VER. But maybe you know something I don't, or maybe you're using some other compiler that doesn't understand the #pragma? Also, picking nits, since I have nothing better to offer, I see that this is a memory pool for contrained memory environments. That must be a constrained, contained memory situation, correct? :)Keep Calm and Carry On
GCC throws a "#pragma once in main file" if I don't guard against them appearing. OTOH MSVC seems to like #pragma once to be in there for its source editors.
Real programmers use butterflies
-
I used to put a test of the preprocessor in headers :
#pragma once
#ifdef HEADER_H
#error pragma once was ignored
#else
#define HEADER_H
#endifI have not used very many compilers but I never saw the error message. I use only VS now so I don't do that any more.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
I could do that but I'd rather recover gracefully. What I did compiles with no warnings and that's my major concern.
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
-
GitHub - codewitch-honey-crisis/MemoryPool: Small fixed size sequential memory pool allocators for constrained memory environments[^] :laugh:
Real programmers use butterflies
-
I needed some garbage-collector like advantages without the overhead so I wrote a 123 line file to give me exactly that. I love C++, and right now I don't know why I ever messed with .NET. :thumbsup::thumbsup::thumbsup: I'm usually not one to holy roll about technology but this language absolutely rules. The only downside with it is it hides nothing (and it doesn't parse properly**), but hiding nothing is just as big an advantage as a liability. Oh how I missed you, C++. ** C++ should really be parsed with a GLR parser so you don't have to worry about incomplete types being a thing.
Real programmers use butterflies
-
I'm still kind of massaging the code. It's so simple it works as is and will probably remain basically the same, but I've tweaked little things like changed the template parameter from
CtoTCapacityI'm still not sure I like so I haven't recommitted yet but any changes will be minor.Real programmers use butterflies
-
honey the codewitch wrote:
The only downside with it is it hides nothing
Actually, it does. Time to move to Assembly.
Okay that's fair, except I can't think of much I can't get to in C++ with the right massaging of the compiler. I can manually build vtbls, i can make call stack frames myself, typically, I can even drop to inline assembly if I really want. So I see it more as giving you more tools than ASM. I don't think it takes anything away.
Real programmers use butterflies
-
Back in the days of yore, when I did my C programming, I discovered alloca(). Used inside of functions, instead of malloc() (for example), it would free allocated memory when you left the function. I didn't look into the workings but I'd presume it used the stack for memory. Update: Quick Search [^] and it's in C++, too - and it does use the stack for allocatons.
"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
One of the problems with stack allocation is on platforms like the ESP32 and most of the arduinos, they don't give you a lot of stack space. I know usually one grows up and the other grows down but I run out of stack declaring 2kB blocks sometimes so there might be some kind of artificial limit. That's why I usually use the heap for my pools.
Real programmers use butterflies
-
I needed some garbage-collector like advantages without the overhead so I wrote a 123 line file to give me exactly that. I love C++, and right now I don't know why I ever messed with .NET. :thumbsup::thumbsup::thumbsup: I'm usually not one to holy roll about technology but this language absolutely rules. The only downside with it is it hides nothing (and it doesn't parse properly**), but hiding nothing is just as big an advantage as a liability. Oh how I missed you, C++. ** C++ should really be parsed with a GLR parser so you don't have to worry about incomplete types being a thing.
Real programmers use butterflies
-
John Lennon said, "All you need is love."
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
And look what happened to him
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
No, that's basically how my code works.
Real programmers use butterflies
In that case you may be related to Tom Jomes[^] :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I'm economically agnostic. No systems devised by humans survive contact with them.
Real programmers use butterflies
-
Sounds like you're in regression. Next year you'll be hot for C and after that you'll start a club with Codewraith doing 1802 assembler for your own Zwölf.
Wrong is evil and must be defeated. - Jeff Ello Never stop dreaming - Freddie Kruger
That would make 3 people in the club - though I usually prefer C to assembler, I like a good delve into the madness from time to time.
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
-
Then that would be an actual garbage collector, which I'm trying to avoid. :-D 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
-
I'm economically agnostic. No systems devised by humans survive contact with them.
Real programmers use butterflies
-
When I saw your post, I wondered how badly you were going to get flamed, given the popularity of C# on this site. I never thought this thread would stay so civilized, let alone be fairly positive. :)
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.The day is not over yet. :rolleyes: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Okay that's fair, except I can't think of much I can't get to in C++ with the right massaging of the compiler. I can manually build vtbls, i can make call stack frames myself, typically, I can even drop to inline assembly if I really want. So I see it more as giving you more tools than ASM. I don't think it takes anything away.
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. -
Some of the references warn against its use. So far as I can tell, it's based upon usage and gotcha's that are common in C - in other words, C is for grownup who take responsibility for their actions. 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
"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
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.
-
GitHub - codewitch-honey-crisis/MemoryPool: Small fixed size sequential memory pool allocators for constrained memory environments[^] :laugh:
Real programmers use butterflies
