This, this right here... is why people hate macros...
-
Bruh
#define SUBMIT_FIELD(p) \
do { \
if (!quoted) \
entry_pos -= spaces; \
if (p->options & CSV_APPEND_NULL) \
((p)->entry_buf[entry_pos]) = '\0'; \
if (cb1 && (p->options & CSV_EMPTY_IS_NULL) && !quoted && entry_pos == 0) \
cb1(NULL, entry_pos, data); \
else if (cb1) \
cb1(p->entry_buf, entry_pos, data); \
pstate = FIELD_NOT_BEGUN; \
entry_pos = quoted = spaces = 0; \
} while (0)I mean dude, make it an inline function already. :laugh:
Jeremy Falcon
Would the call to the inline function be "submitField(p, quoted, entry_pos, spaces, entry_buf, cb1, data, pstate);"?
-
Bruh
#define SUBMIT_FIELD(p) \
do { \
if (!quoted) \
entry_pos -= spaces; \
if (p->options & CSV_APPEND_NULL) \
((p)->entry_buf[entry_pos]) = '\0'; \
if (cb1 && (p->options & CSV_EMPTY_IS_NULL) && !quoted && entry_pos == 0) \
cb1(NULL, entry_pos, data); \
else if (cb1) \
cb1(p->entry_buf, entry_pos, data); \
pstate = FIELD_NOT_BEGUN; \
entry_pos = quoted = spaces = 0; \
} while (0)I mean dude, make it an inline function already. :laugh:
Jeremy Falcon
I do believe the technical term is 'ick'.
Software Zen:
delete this; -
Bruh
#define SUBMIT_FIELD(p) \
do { \
if (!quoted) \
entry_pos -= spaces; \
if (p->options & CSV_APPEND_NULL) \
((p)->entry_buf[entry_pos]) = '\0'; \
if (cb1 && (p->options & CSV_EMPTY_IS_NULL) && !quoted && entry_pos == 0) \
cb1(NULL, entry_pos, data); \
else if (cb1) \
cb1(p->entry_buf, entry_pos, data); \
pstate = FIELD_NOT_BEGUN; \
entry_pos = quoted = spaces = 0; \
} while (0)I mean dude, make it an inline function already. :laugh:
Jeremy Falcon
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.
-
Does it predate C99, when
inlinefirst 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
-
Bruh
#define SUBMIT_FIELD(p) \
do { \
if (!quoted) \
entry_pos -= spaces; \
if (p->options & CSV_APPEND_NULL) \
((p)->entry_buf[entry_pos]) = '\0'; \
if (cb1 && (p->options & CSV_EMPTY_IS_NULL) && !quoted && entry_pos == 0) \
cb1(NULL, entry_pos, data); \
else if (cb1) \
cb1(p->entry_buf, entry_pos, data); \
pstate = FIELD_NOT_BEGUN; \
entry_pos = quoted = spaces = 0; \
} while (0)I mean dude, make it an inline function already. :laugh:
Jeremy Falcon
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?"
-
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
-
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.
-
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
-
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. :laugh:
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
-
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.
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
-
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?
-
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.
-
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
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.
-
Bruh
#define SUBMIT_FIELD(p) \
do { \
if (!quoted) \
entry_pos -= spaces; \
if (p->options & CSV_APPEND_NULL) \
((p)->entry_buf[entry_pos]) = '\0'; \
if (cb1 && (p->options & CSV_EMPTY_IS_NULL) && !quoted && entry_pos == 0) \
cb1(NULL, entry_pos, data); \
else if (cb1) \
cb1(p->entry_buf, entry_pos, data); \
pstate = FIELD_NOT_BEGUN; \
entry_pos = quoted = spaces = 0; \
} while (0)I mean dude, make it an inline function already. :laugh:
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 aconstvariable declaration. One should eschew this:#define PI 3.1415927fin favor of this:const float PI = 3.1415927f; -
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 aconstvariable declaration. One should eschew this:#define PI 3.1415927fin 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
-
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
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_ 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.