|
In this case, they should have used straight inline code.
Not a fan of macros,
but using C most of the time, system wide macros probably means I probably use some.
I don't write them, though.
"ghost writers from the sky"
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I should preface this by saying, I absolutely love C. It's served me well over the years, but macro abuse is real. There needs to be a helpline for victims of it. 
Jeremy Falcon
|
|
|
|
|
Ditto. I agree.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Does it predate C99, when inline first hit C?
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Good question. I think it was written in C89.
Jeremy Falcon
|
|
|
|
|
I have a few at least as large. I hate it also except when I finally get it to compile.
|
|
|
|
|
Would the call to the inline function be "submitField(p, quoted, entry_pos, spaces, entry_buf, cb1, data, pstate);"?
|
|
|
|
|
I do believe the technical term is 'ick'.
Software Zen: delete this;
|
|
|
|
|
Put your man pants on... Charlie is in the room.
Doing something like this is evil, not acceptable and pure unsupportable garbage. I call it whiz kid code. When the kid moves on, or dies (whiz kids are getting older) the FIRST thing that will happen is a lot of cussing. The second thing that will happen is this will get tossed into a function - screw the inline nonsense. I'm not even sure that's relevant anymore unless you are in a restricted embedded environment. It's not supportable, you cannot debug it, why the f*** would you do this?
Because you want to be cute. Show your macro balls. You need to be taken to the back parking lot and beat on. The next time you think to do this (and I've actually seen worse) your eye will start to twitch and your right hand tremble...
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.
|
|
|
|
|
You did mention embedded, so I am commenting in light of that.
My experience on embedded is the damned GCC compiler does not like to inline your functions unless they're extremely trivial. Even if you put "inline"
In fact I treat "inline" strictly as a linker flag. It tells the linker to just use the first implementation it finds. Good for header only libraries. Inline isn't good for much else.
There's a compiler extension attribute to force a function to be inline in GCC. I've had to use it before. I don't know when it was introduced.
So absent that attribute, such a macro may be necessary. I've seen it in TFT_eSPI code as well, on the performance critical paths. I'm pretty sure this is why.
Edit: I don't think this is the case with the code in the OP. I'm speaking generally about this technique.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
