Re: C question for you old guys ;-)
Re: C question for you old guys ;-)
- Subject: Re: C question for you old guys ;-)
- From: Marcel Weiher <email@hidden>
- Date: Wed, 11 Jun 2003 15:00:03 +0200
On Wednesday, June 11, 2003, at 12:54 Uhr, Jay Vaughan wrote:
On Tuesday, June 10, 2003, at 01:23 AM, Jay Vaughan wrote:
I don't like them, and I'm not only not going to use them, I'm
going to see to it that anyone I know doesn't promote their use as
well! It's a terrible thing to do!
I'm not offering approval for you anyway, I'm cautioning the leagues
of programmers on this list you have tainted with bad programming
advice.
Only in your opinion, which is not shared by many on this list.
Don't offer new programmers bad advice just because it reflects some
'programmer cool'.
Don't get personal. Don't get personal based only on something that is
purely your own personal opinion. Don't get personal.
It reflects poorly on your "Senior Cocoa Software Engineer" status
more than anything. If you were truly senior, you would understand
the problems this 'hack' promotes in a project.
You might want to consider the case that he *does* understand the
"problems" and found them to be outweighed by the advantages in this
particular case. This is what is called an engineering trade-off,
which is always involved, especially when using the pre-processor.
For example, I certainly did not create my accessor + encoder + tester
macros lightly, and I am aware of the problems using macros can cause.
However, the benefits in those cases vastly outweigh the problems.
When I first saw John's suggestion, my immediate reaction was also
negative, because I had also seen the attempts to turn C into Pascal
using Macros, which I don't think are a good idea, and also because I
find the C++ way, where you have no idea what anything means any longer
deeply troubling and troublesome.
However, closer examination of this particular suggestion had me notice
that my initial reaction was an over-reaction, that 'is' neatly solves
a particular problem in a very minimalist fashion, and precisely
without the negative impacts that you seem to associate with it, and of
which you have offered no substantive evidence apart from
extrapolation. But extrapolation doesn't cut it, because everybody
knows that *abuse* of the pre-processor can be a bad thing.
[more of embarrassing hyperbole and ad-hominems deleted]
Sorry, but 'fixing' the (val == CONSTANT) vs. (val = CONSTANT) problem
with a #define like you suggest is a sloppy habit and a poor use of C.
Only in your completely unsubstantiated opinion. Care to back it up
with something that is not extrapolation or hyperbole?
The reason it is a bad habit is that if I see someone doing that in
code on a project I'm working on, I can only wonder what *ELSE* was
#define'd to make the code readable
That would be your problem, wouldn't it?
... and short of inspecting the entire cooked pre-processor output
myself personally throughout the entire project, there would be no way
of making for sure that I didn't miss some stupid pre-processor hack
buried somewhere which changes the way everything 'looks' just to make
it easier to 'read'.
This is simply wrong, because this particular pre-processor definition
does NOT change things that are there, it only adds. So it is like
everything else that is added: the first time you see it, you will
probably have to look it up, unless you can figure it out yourself.
After that, it is OK. How this is different from a function-definition
that you haven't seen before, or a message-selector you haven't seen
before is something you have so far failed to explain.
It might be cool, but it is definitely *BAD*.
Repetition of hyperbole does not strengthen your case, it weakens it.
Complete chaos *has* happened, and *does* happen, if you promote
language-semantic modification with the pre-processor in any large'ish
demographic of programmers. This completely invalidates the purpose
of the pre-processor in the first place, which is to safely make code
more readable!
See above.
The truly senior lesson here, off-topic for cocoa-dev but relevant
since cocoa-dev originated the thread that started this all, is > simple:
*READ* your code, people. Don't just blankly stare at it and assume
you think you know what you're doing with it, no matter how 'senior'
you are. Programmer arrogance is fatal! It takes a humble pass of
code to spot the difference between '=' and '==', and nothing else.
Well, this makes me doubt your credentials, not just a little bit, but
a lot. The simple fact is that the '=' and '==' are sufficiently
similar that it is easy to miss, even on close/repeated inspection.
The human mind works that way.
And, despite what John C. Randolph says, using #define to make things
'easier' for you to avoid having to read your code *IS* a bad habit.
Have I mentioned before that repeating hyperbole without substantiation
does not strengthen your case?
READ the code. Don't just stare at it. And for gods sake, please
don't use #define to make changes to language semantics!!!!
For god's sake: try to understand that this addition is not a *change*
to language semantics.
Marcel
(who probably hasn't written a million lines of C, partly because he
knows how to use the pre-processor...)
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
f0249ab8b1af193ef5addcf39fdff5ca
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.