|
OriginalGriff wrote: Self governing car is not a rodent that has lost direction! (10)
Self governing
car AUTO
not NO
a rodent that has lost direction MOUS
AUTONOMOUS
|
|
|
|
|
And that, my friend, means you are up tomorrow! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
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.
| 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: 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
|
|
|
|
|
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
| 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 |
|
|
|
|
|
Yeah which is why i don't use it.
I have StaticMemoryPool<C> which can allocate a fixed amount of data from the heap or the stack (capacity C known at compile time) and DynamicMemoryPool which allocates a capacity specified at runtime, but always from the heap.
using dynamic stack allocations is messy because its intertwined with scope. Plus it goes out of scope with the function ends making wrapping it not a thing. Maybe that's why it's warned against. *shrug* I really don't know.
Real programmers use butterflies
|
|
|
|
|
It's only scope, certainly how I used it, was within the function - scope was never a problem. Memory wasn't humongous, then, so allocations were done with care, anyway. There was expanded and extended memory.* It's built in (usually) and automatic. About the only complaint I found really valid is that it's existence in a compiler is not (or was not) guaranteed as it was an official standard. It happened to be everywhere I was (QuickC, MS-C, Wacom-C) on DOS and NT, manly;
Now I live in a stateless world of web development. I will say, however, that with the 400 users, an occasional server request gets an out-of-memory error. I increased it in php.ini a couple of times, but for the most part, the DBA and I share info and he forces filters them to not ask for a million records. A better long-term solution.
*I made a page-swapper so I could access lots of it smoothly beyond the 64K in the original page frame.
| 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 |
|
|
|
|
|
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".*
| 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 |
|
|
|
|
|
Only use code that runs as expected on the DeathStation 9000!
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 |
|
|
|
|
|
|
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.
|
|
|
|
|
Thank you. I've been trying to remember the name of that system for ages. I had been meaning to use it in QA, but it's probably too arcane for 99% of those who post questions there.
Keep Calm and Carry On
|
|
|
|
|
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
|
|
|
|
|
Yes, in C#, we (used to) use underscores for local member names. In C++, we used 'm_' for member names. The 'm' told us that it was a class (or struct) member.
|
|
|
|
|
i should have known. i went back to that style and I absolutely hate it.
Real programmers use butterflies
|
|
|
|
|
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
|
|
|
|
|
How much can you sell it for? And/or can you get 1 million (or more) devs to use it?
That's our modern (cynical) measure for success so get on board. 
|
|
|
|
|
I gave it away under the MIT license. It was just a little bit of code anyway.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I gave it away under the MIT license.
GitHub link, or it didn't happen. 
|
|
|
|
|
|
I see you're using both #pragma once and #ifdef include guards. 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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
