Re: C-programmer needs Forth advice
- From: John Passaniti <nntp@xxxxxxxxxxxxxxxxx>
- Date: Thu, 01 Dec 2005 06:55:00 GMT
Jeff M. wrote:
First off, macros are great. These macros are just plain bad. You may use them. Fine. (Why should I care?) However, that is a gross misuse of a language feature.
So, care to tell me *why* or are you just going to repeat yourself?
Second, there is no such thing as a "local macro". Macros in C are handed by the pre-compiler, and affect ALL other files processed after them.
This is completely wrong. It's not even a matter for debate. Learn C before you comment on it.
But even if you were right, the solution is obvious to anyone who understands C: Scope the macros with an #undef.
One of the worst macros ever that I've had to deal with was in the Mersenne Twister code written by Takuji Nishimura and Makoto Matsumoto (http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/mt19937ar.c) that a programmer put into our code-base and subsequently had gobs of error messages out of [seemingly] "nowhere". These lines:
#define N 624 #define M 397
Caused no end of headaches for many hours. Your macros are of a similar vein. And since you can't guarantee compile order, you are just asking for problems. What if another programmer later decided to do this:
void some_func(int _x) { /* do something here */ }
My macros are *nothing* like the example you provided. The names I picked have a simple and obvious relationship to the structure members. The macros you have don't have any obvious relationship to anything.
But ignoring that, I have no idea what your "guarantee compile order" comment means, because this is a single file and I *can* guarantee compile order. As far as what prevents someone from writing the function you offered, it's called a compiler and the mechanism is a syntax error. The expansion of your function would be this:
void some_func(int this->x) {
/* do something here */
}And that would immediately fail as a syntax error. At that point, the clueless programmer would scratch their head and actually *read* the code and understand the conventions being used.
The *only* sin here is not adding a comment explaining the rationale for the macros. Since my purpose was to illustrate that adapt2.c could be factored further, and since this wasn't intended to be production code, I didn't care.
This is now an error because of your macro. But obviously your standards are different. Okay. ;)
It's more than an error-- it's a *syntax* error that the compiler wouldn't even compile.
Are you seriously suggesting that "good programming" is the ability to write functions without understanding the environment they are compiled in? Man, you must really hate Forth then, as you're free to change the environment in all sorts of interesting ways-- far beyond mere macros in C.
Of course, the debugger I have is fine. I certainly *could* go to the top of each of the functions that is called, set a breakpoint, and set one at the end. What a pain! Also, that actually requires me to have access to the source code of those functions. I very well may be using a 3rd party library, in which case your argument is moot.
What a pain?!!! Do you really understand how to use your debugger? Do you understand that when you put a breakpoint on a line, what you are *really* doing is identifying to the debugger a displacement into your compiled code and setting a breakpoint there?
Your argument is nonsense on multiple levels. But if it really bothers you and your debugger is insane and strictly line-based, a moments editing solves the problem:
while (! converged( newPoints( moveDown( subdivide(&i))))) ;
Your comment about not having source code and third-party functions also doesn't make sense. We aren't talking about cases where you don't have source code-- we're talking about debugging *this* code.
Now, how much easier is it for me to just set one breakpoint at the first part of my code that begins using those functions and gets the results of each and just passes them on? There is little [to no] performance hit, and only makes life easier for anyone maintaining the code in the future. [...]
Sounds like you're someone who doesn't operate below the C level and you rely on a debugger operating at a high level of abstraction to insulate you from the machine-level reality underneath. Your need to reformat source code to set breakpoints is a clear sign of that.
So I guess in a weird way, you've brought up a valid point; if I am dealing with programmers who can't operate below the level of C, then you're right-- reformatting the source is necessary. Thankfully, my reformatted version above addresses that, and even more thankfully, being an embedded systems programmer, I don't really have to deal with that issue at all.
Readability != maintainability. They may be closely related (in good code), but they are not the same. And when working on a project that takes many years, with programmers switching between systems/projects and new hires, maintainability is far more important (imo). YMMV.
I didn't claim readability is the same as maintainability. But I do believe that if your code isn't readable, then it isn't (by definition) maintainable.
.
- References:
- Re: C-programmer needs Forth advice
- From: Jeff M.
- Re: C-programmer needs Forth advice
- From: John Passaniti
- Re: C-programmer needs Forth advice
- From: Jeff M.
- Re: C-programmer needs Forth advice
- Prev by Date: Re: C-programmer needs Forth advice
- Next by Date: Re: GForth Memory Map
- Previous by thread: Re: C-programmer needs Forth advice
- Next by thread: Re: C-programmer needs Forth advice
- Index(es):
Relevant Pages
|