|
fair enough, yet in all my years, I have yet to see a significant (key word there) performance improvement doing macros like this. Nor have I seen a test process to validate the macro. I'm more in line with the "hey, looks like it works!" and people move on.
I've not used gcc much, but 99% of the time, inefficiency is caused by poor choices and algorithms. People mallocing 10MB "just in case" when the structure is only 16k. I had a sequential loop through a 10 key structure array. I thought to myself "hmm, let's try a hash lookup from stl, it should be faster." Nope, 5x slower. Okay, lets not do that. But go back to my original point - ignore the compiler making this more efficient, how would you possibly debug that macro?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
What I would do is like I did for TFT_eSPI. Put the code into routines, and then switch out the macro instantiations to calls to the routine. It's a little work, but mostly just editor search and replace.
I will forgive TFT_eSPI for this code. I checked the output at godbolt.org . Those macros do what they're supposed to.
Specifically, they write various types of data to an SPI bus very quickly. It's inherently low level. The library code that builds on it could be cleaner, but is nowhere near as unintelligible.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Greetings Kind Regards
May I please inquire the alternative. I do not see how a function inline or not would be sufficient as the macro is referencing many local variables. All those terms of course can be passed to a function but now you have an ugly function call. In my own current project a number of methods perform identical logic utilizing local variables of identical name as part of their different duties. Though the macro itself is ugly has heck and difficult to debug the aforementioned methods are much cleaner in appearance. I would be happy and eager to learn of a superior method.
Thank You Kindly
|
|
|
|
|
You are absolutely right. In C++ you could make this an inline member function and turn all those local variables into member variables. That would make it a clean function call with the struct as a single parameter. Hmm, in C you could possible package all those local variables into a local struct which could then be passed as a single argument to in inline function?
|
|
|
|
|
Thank you for your kind and helpful reply. A perfect solution is now obvious id est package as you described then hide package and inline call via macro. Voila Presto Bingo. A single term exempli gratia CALL_GREAT_CODE_HERE_BEHIND_THIS_MACRO This is why I love macros.
|
|
|
|
|
The alleged argument is that the macro makes code easier to read and is more efficient.
Reading: sure, if you wrote the macro it's perfectly clear in YOUR head what is does. But you cannot debug it. You are embedding a time bomb in your code for support. But wtf cares about support and long term issues? I argue this just creates additional code entropy.
Efficiency: prove it. I'm going to write on my whiteboard to start a project. If you write macros like this, because it makes the code run faster - prove it. In 45 years of coding, we're dealing with 0.01% of issues, if that. Modern compilers are modern. Well, I hope gcc is. The real danger has to do with what is behind the compiler. Add in one dll from MS and all of your macros are screwed. Meanwhile you have the support legacy of this macro noise.
If you are going to complicate your code, justify it. Otherwise, stop screwing the poor slob who comes along 5 years later.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
appearance has nothing to do with test, maintainability and understanding. Don't get me wrong, there is a place for macros - SIMPLE macros. I'll get silly, I can take a function at 1000 lines and turn it into a macro. How is that helpful?
#define _DO_STUFF_ <insert 1000="" lines="" of="" <gobbledegook="">
No. Sorry, just no. Modern compilers are efficient. People that write huge macros are either using their preferences, trying to be cute, or have never been held accountable. It's a disease, get therapy.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I have done something like this just a few times and I remember them fairly clearly. One was because of performance reasons and the other was because C does not have templates. This does not appear to be either case. In fact, it's a single-pass pseudo-loop. I have done that too but never in a macro and never when there wasn't at least a few breaks in the "loop." I see no good reasons at all for this monstrosity.
"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?"
|
|
|
|
|
Rick York wrote: I have done something like this just a few times and I remember them fairly clearly.
Don't worry, Rick. We won't tell anyone. 
Rick York wrote: I see no good reasons at all for this monstrosity.
Same. Peter (above) mentioned a good point, the code was written in C89 before the inline keyword. So, can only guess it was for performance. Personally, I think I would've taken the performance hit of a function call. Assuming it was written in the 90s due to C89... a function call wasn't that bad IMO.
Jeremy Falcon
|
|
|
|
|
That's why function templates were created in C++. All of the compile time features without adding overhead or degradation in execution speed. When I am coding in C++, I rarely use/utilize macros.
Which isn't to say that macros, properly implemented aren't useful. Take, example, the need to "stringize" a set of characters. You can't really beat:
#define STRINGIZE(x) #x
One more thing... too often, macros are used to provide some way to represent a value, as opposed to using a const variable declaration.
One should eschew this:
#define PI 3.1415927f
in favor of this:
const float PI = 3.1415927f;
|
|
|
|
|
1,000% agree. To be honest, my C++ is weak. I've always done "C in C++" but maybe it's time I revisit that.
Jeremy Falcon
|
|
|
|
|
I got a stack overflow in my SVG code. It never used to do that before, and I barely changed anything. I just removed a few divisions in some relatively innocuous routines. Furthermore, reverting the changes didn't fix it.
There's something else going on. Well, on little embedded devices there's not a whole lot of memory protection. When you stack overflow it clobbers the stack so you can't get even a partial stack trace.
Okay. My code is cross platform. I'll fire it up on my PC under MSVC++
Compile errors. Turns out what I thought was a harmless feature add makes MSVC++'s compiler just scream. 100 errors for less than 10 lines of code. I removed the feature. It's a shame too, as it was a real convenience.
Got it building.
Put together my test code - basically just de-arduino-ing it and then making it spit the graphics as ascii art to the console. No big deal.
Run it. No crash. No stack overflow.
Which tells me the problem is the one I didn't want to try and solve. Now I need to figure out what's taking all the stack, rather than what is recursing indefinitely.
I did move 2KB off the stack but it's still dying on me.
This code is non-trivial. It's the SVG parsing code, and took me forever to create it. I tried to keep it light on the stack but apparently it's not light enough.
Pruning for stack space in a veritable labyrinth of function calls is not my idea of fun.
I have a dentist appointment later today which seems appealing by comparison. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: . It never used to do that before, and I barely changed anything. I just removed a few divisions in some relatively innocuous routines.
lol.
Famous last words...
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Like I said, I reverted the changes and the problem still occurs.
I know better than not to verify that.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I sympathise. Many years ago I worked on a desktop financial calculator which had 32K of EPROM for all the code and 16K of battery backed RAM for everything else, all the persistent storage and workspace, display buffer, the lot, and the number of times we had late nights reworking the code to save a few bytes here and there so it would fit in the EPROM, or shaving the stack usage so our variables survived ... a very character building time.
modified 21-Aug-24 5:52am.
|
|
|
|
|
Rust.
(I'm sorry I felt this had to be done)
|
|
|
|
|
I do not know anything about rust, but does rust have infinite stack ?
|
|
|
|
|
Please explain why RUST would have solved this problem. Honest and curious question.
stack issues are common in embedded systems, no matter what development language you choose.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Saw this absolutely stupid wording on my start screen today: "Matriculate your shopping over to [our browser] to help ensure low prices..."
Evidently MS, in their infinite stupidity, has re-enabled ads on the start screen even though I turned them off earlier. Looking into this more: Yes, yes they did. (Evidently on one of their 'minor point' updates.)
And the person who thinks 'matriculate' is a catchy word to entice people with should be fired, and not hired for anything more than cleaning toilets. 
Maybe this would keep them away from a keyboard: Chinese finger torture[^]
|
|
|
|
|
There's always a possibility that there's a LLM behind this. It appears to be a common thing now, to write marketing copy from a prompt.
|
|
|
|
|
If so, the person behind that decision should be fired, and not hired for anything more than cleaning toilets.
|
|
|
|
|
I'm not even sure I'd hire someone that lazy to clean toilets. I'd be afraid they wouldn't use any cleaners.
|
|
|
|
|
Make them lick it clean, then.
|
|
|
|
|
I see a lot of clean bathrooms at MS just saying
|
|
|
|
|
Maybe they just couldn't spell Ma*****ate.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
