andrewsr@police.rutgers.edu (Richard L Andrews) (01/24/90)
Being new to C I have a few questions which must have been addressed before in this newsgroup. If someone has the previous stuff I would really appreciate an E-mail. Thanks. Ok, I have read K&R (II) and Koenig's C Traps and Pitfalls. I know that a potential problem in coding is the mixup of `&' and `&&' (and `|' and `||' etc). Now, what is potentially wrong with: #define AND && #define OR || #define EQ == It seems to me that when reading code this is what I do anyway. Ex. if (a && b) => if (a AND b) I do not advocate #defining code until it looks different (aka making C look like pascal), but this seems harmless. Also, just to open a bag of worms, what other books do people recommend? (And not beginner stuff). -- // Richard L Andrews II |"Like any good philosophical discussion, the \X/ andrewsr@topaz.rutgers.edu| conclusion is left unresolved." -McLaughlin
roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (01/31/90)
In article <1922@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes: > > [using preprocessor to redefine language] > > I know I fight on a losing battle; but it will not be easy to > missionize me. So let the flames begin ... > The following joke circulated in another group a while back: >From: schooler@venera.isi.edu Date: Tue, 25 Jul 89 18:12:57 -0700 Subject: california codin' Just wanted to check out that you gnarly dudes are using the latest and greatest software technology fer yer rad code to make it easy for the dudes who have to read it. The hip new way to write readable C code involves the use of a few simple defines. #define like { #define man ;} #define an ; #define SayBro /* #define CheckItOut */ SayBro like, this is some rad shit, so CheckItOut like a = b an c = d man SayBro , like who needs help from them compiler choads anyway? THIS is the way to write CLEAR code. I mean really! CheckItOut like SayBro this is ShellSort straight out of the white book, but in a readable form. CheckItOut man #define YoDude for( #define OK ) #define is = #define AND && #define as #define Do #define long #define some #define make #define shit #define FAROUT shell(v, n) SayBro sort v[0]...v[n-1] into increasing order CheckItOut int v[], n; like int gap, i, j, temp; YoDude gap is n/2 an as long as gap > 0 Do some shit an make gap /=2 OK YoDude i is gap an as long as i < n Do some shit an make i++ OK YoDude j is i - gap an as long as j >= 0 AND v[j] > v[j+gap] Do some shit an make j -= gap OK like temp is v[j] an v[j] is v[j+gap] an v[j+gap] is temp man FAROUT man SayBro like, B there OB square! CheckItOut Thanks to franklin a davis Thinking Machines Corp. Cambridge, MA 02142 617-876-1111 for putting it (again) on the net. -- The guy who said "The good die young" may have been talking about turkeys... Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof
ken@cs.rochester.edu (Ken Yap) (02/01/90)
|This is the old slogan: UNIX users always *know* what they do; C users always |*know* what they do. To my experience, practice and the discussions in |comp.lang.c prove the contrary. So why not help them to avoid some common |pitfalls by defining some adequate macros? But macros introduce their own pitfalls too. I once wanted to strangle the programmer who wrote #define K *1000 so that one could write: resistance = 10K; You can imagine what happened when somebody declared the variable K.
roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (02/01/90)
In article <1990Jan25.192545.1570@twwells.com> bill@twwells.com (T. William Wells) writes: | |EQ is relatively harmless, but also pointless. There are better |ways to make sure you don't substitute an = for an ==. | Those being...? -- You'ld be surprised how much plastic is used in a Citroen BX. (Try rear-ending somebody sometime...) Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof
tneff@bfmny0.UU.NET (Tom Neff) (02/02/90)
In article <1031@carmine1.UUCP> yedinak@cell.mot.COM (Mark A. Yedinak) writes: >There are several underlying issues within this discussion which should >really be considered. First, if programmers would learn (that is TRULY >learn) the languages they work in, there would be no need for this >discussion. This seems to me to be less a matter of education than of belief. In my experience, programmers who substitute old familiar tokens for new ones do KNOW the new language -- they have to in order to write the defines -- they just don't LIKE it. They think the new way is "dumb" and the old way was "better" or "just fine." I have heard all sorts of irrational justifications. Only when they BELIEVE in the new language, by having succumbed to its charms (or having been forced to use it on pain of termination!) do they change their minds. At a less obnoxious level than preprocessor defines, this occurs all the time with algorithms and packages. We are all familiar with the "itinerant" systems or applications programmer who has "his libraries" that go with him wherever he goes. In the days when everyone programmed FORTRAN this was a straight shot, but now that we live in Babel he often spends his fifth through tenth weeks (never the first!) REWRITING his libraries into whatever the new lingo is. In a bustling shop full of experienced primadonnas this can be quite an issue, as each new worker arrives with his OWN way of "doing everything" and tosses it into the pot. Again, only when faced with the executioner's halberd will some of these folks deign to use a FOREIGN package. :-) > Hence, the reason so much time was spent to develop a >standard. With a standard everyone is talking the same language and >there is not room for ambiguity in interpretation, as there will be if >every developer uses the preprocessor to customize their source code. Oops, I seem to be talking to myself. The above is in left field, the Standards have little to say about this phenomenon. The original poster wanted to do something PERFECTLY legal within the ANS document. What was interesting and discussible about it was that it's lousy programming practice, even if permitted by the standard. >Also, if more developers would spend time designing their code, rather >than just hacking it out, we would all be better off. Etcetera, but I can't leave without sideswiping this bromide. One man's hacked-out code is another man's correct design. Everyone's best at something, not always the same thing. I have people I would go to in a moment and say, "Task XAP is crashing every 10 minutes, I need a hack >>NOW<< to keep it afloat somehow because our customers are screaming at us!," and know I was in good hands, but would never go to and say "We need a solid overall design for a portfolio database" because I know I'd get a mess. And conversely. Good design is a great thing, but there is a maxim: Project requirements will grow until your design busts. Neff's Corollary: No act of good programming goes unpunished.
djones@megatest.UUCP (Dave Jones) (02/02/90)
My news-system has been broken, first here then there, for a week or
more. It looks as though I may have missed some SLM's (silly little
macros) -- those infuriating little hacks that send you grepping around
in .h files. A while back, I decided to keep a file of the most disgusting
of the lot, all taken from actual practice. It has not grown very long,
because I have not been reading much code lately, having been in high
hack mode for months. The list follows. Should I add '#define OR ||'
and '#define AND &&'? In other words, is this from real code, or was
somebody just thinking out loud?
Notice that the most serious offender in the SLM category has a place of
dishonor at the very top. SLM's are presented with their original
comments.
#define NULL 0
#define NULL ((char*)0)
#define MAGIC '\0' /* silly terminating character value */
#define forward /*empty*/
#define const /*empty*/
#define public /*empty*/
#define PUBLIC
#define forever for(;;)
#define PRIVATE static
#define TINY short
#define HUGE long
#define RECORD struct
#define TRUE (1==1)
#define FALSE (0==1)
#define TRUE (0==0)
#define FALSE (0!=0)
typedef enum { FALSE, TRUE } Bool;
#define TRUE (1)
#define FALSE (0)
#ifndef TRUE
#define TRUE 1
#endif
#ifndef FALSE
#define FALSE 0
#endif
#define OK 1
#define OK 0robert@isgtec.UUCP (Robert Osborne) (02/03/90)
In article <1941@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes: >>Besides, even if you *do* have the ability to run the preprocessor seperately, >>doing so will destroy lots of potentially-useful information (like #defined >>error codes, etc.) >I like *partial* preprocessing :-) What did I say the other day? Let the >machine do the dirty work ... If you could see the myriads of #define's and >#ifdef's in my code! If you need myriads of defines and ifdef's, your not letting the machine do the dirty work -- writing lots of defines and ifdefs *IS* dirty work! >>Well, if I want to do that on VMS, first I have to port "awk"... >I don't understand why you *must* do it in VMS; why don't you copy your >programs to UNIX? Nice attitude Georg! What if one doesn't have UNIX? If one is writing a program that must run under VMS copying programs to UNIX isn't much help. >This is the old slogan: UNIX users always *know* what they do; C users always >*know* what they do. To my experience, practice and the discussions in >comp.lang.c prove the contrary. So why not help them to avoid some common >pitfalls by defining some adequate macros? You are missing the point entirely Georg, redefining the language using macros is one of the biggest pitfalls there is. From your flippant responses to the critisims of your method I see you don't care about who has to maintain your code, or what machine/OS they have to maintain it on. That's ok but some of us do or have to care! As an aside, how many people actually get caught by & vs && or = vs ==? I know I have been caught a couple of times by =/==, but never by a &/&& or a |/||. >To summarize, I see that some of my concrete suggestions were not optimal, but >I don't depart from the principle that programmers should be supported by >making some language constructs clearer and by avoiding typical pitfalls of the >language. Programmers should avoid typical pitfalls of the language. Programmers should also write code that is clear, concise, and maintainable. Your macros fail on all three of these counts. -- Robert A. Osborne {...uunet!mnetor,...utzoo}!lsuc!isgtec!robert
chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips) (02/03/90)
On 29 Jan 90 19:27:27 GMT, dmocsny@uceng.UC.EDU (daniel mocsny) said: daniel> In article <33948@ucbvax.BERKELEY.EDU> jwl@ernie.Berkeley.EDU.UUCP (James Wilbur Lewis) writes: >In article <1922@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes: >- if (n < MAX AND_THEN a[n] > b.k) >- >- is *not* irritating to read and maintain. It explicitly says what was >- intended by the programmer. >Irritation is in the mind of the maintainer! YOU might like it, but believe >me, if I ran across code like this I'd be tempted to seize a heavy blunt >object and track down the author! daniel> ... daniel> The C preprocessor has no problem looking at #define's and transforming daniel> the following code back into standard C. So what is wrong with having daniel> a tool that de-customizes programmer A's syntax back into a form daniel> pleasing to programmer B? ... Nothing so long as those creating their own language via the pre-processor _actually provide_ a de-customizer to those who will maintain the code. (No, the preprocessor itself is _not_ an acceptable substitute, because of constants, etc.) How many macro manglers out there have been considerate enough to provide such a tool? How many have taken the effort to ensure that the output always compiles _identically_ to the mangled version? Raise your hands. Ah, congratulations to the both of you. :-) -- Chuck Phillips -- chuckp%ncr-fc.FtCollins.NCR.COM uunet!ncrlnk!ncr-sd!chuckp%ncr-fc ccncsu.ColoState.EDU!chuckp%ncr-fc
amull@Morgan.COM (Andrew P. Mullhaupt) (02/03/90)
In article <=9F1URFxds30@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > Hey, if anything goes I'm sure I could convince C to accept something like: > [ example of preprocessor induced confusion deleted ] OK fine. Nobody is arguing that you cannot mess up C source by an over-active preprocess fixation. However, most of the people who are advocating replacing parts of C with other stuff have something more structured in mind. Even C resorts to this practice with the definition of certain standard macros. The matter is clearly about what constitutes generally versus specifically readable code. Where readability is concerned, the preprocessor giveth, and the preprocessor taketh away. Beauty is as always in the eye of the beholder. Most of the arguments here are probably due to two different sets of beholders. I'm guessing, but I think one set are people who program mostly in C on UNIX for systems, and they want C to look like C. The other set, are applications programmers with special requirements who are forced through circumstance to use C against their will. (Gee- is it too late to get complex arithmetic put in ANSI C? :-)). So in short: Anything does not go. But if you want to ban using the preprocessor to improve the appearance of source, it's OK by me as long as you start with getchar. Later, Andrew Mullhaupt
chip@tct.uucp (Chip Salzenberg) (02/03/90)
According to amull@Morgan.COM (Andrew P. Mullhaupt): >Right you are Bill, but doesn't it seem like the continual need to >warn people off this trick says something about C? It says two things: > >1. A lot of people end up not liking how C code looks. Actually, a lot of people _start_ not liking how C code looks. Eventually they realize the error of their ways -- or leave. :-) -- Chip Salzenberg at ComDev/TCT <chip%tct@ateng.com>, <uunet!ateng!tct!chip> "The Usenet, in a very real sense, does not exist."
bill@twwells.com (T. William Wells) (02/04/90)
In article <1933@gmdzi.UUCP>, Georg Wittig writes: : bill@twwells.com (T. William Wells) writes: : : >EQ is relatively harmless, but also pointless. There are better : >ways to make sure you don't substitute an = for an ==. : : Please do tell me those better ways. Well, besides using a compiler that checks for them, writing a tiny program to do the checking for you is one. Such programs aren't a big deal to write; a simple sed script might be enough. Now, I don't make enough of this particular error to make such a program worthwhile for me; but you may. Writing such scripts, personalized for your own gremlins, is a good way to deal with them. : : const == variable instead of : variable == const : : is *not* better for the following reasons: Ugh, I agree. --- Bill { uunet | novavax | ankh } !twwells!bill bill@twwells.com
shaw@paralogics.UUCP (Guy Shaw) (02/07/90)
In article <21944@unix.cis.pitt.edu>, yahoo@unix.cis.pitt.edu (Kenneth L Moore) writes: > I think that more info can be transferred more effectively using a mentor > approach. There is nothing wrong with asking questions and getting > answers quickly and easily. This is especially true if you are getting > up to speed on a new editor/language/OS. > > Of course this breaks down if the mentor is an asshole. In that case the > "mentor" should be sent packing and a replacement found. > > I think that any good manager would not allow RTFM to be a viable > response to a legitimate question. Good luck finding a mentor who will put up with a lazy acolyte. Often, RTFM is a the best response from a mentor. The reason that the mentor "system" (whether it be official or unofficial) has endured for so long, in spite of its inefficiency, is because there are things that can be taught that way that go beyond what can be gotten from books, or any other method. Good mentors are a rare and precious resource. Using them simply as a more convenient substitute for reference books is an abuse of their time. Of course, "assholes" can say RTFM, too (usually to hide the fact that they don't know, either). So, the RTFM test, by itself, tells you very little. For your own sake, the next time you decide to send someone packing, I hope many other more important things are taken into consideration. If not your best mentors will be sent packing, and you won't even know what you missed. The sad thing is, it seems there are so many who don't know what they missed and don't know what I'm talking about. Sorry. Back to comp.lang.c. -- Guy Shaw Paralogics paralogics!shaw@uunet.uu.net or uunet!paralogics!shaw
richard@torch.co.uk (Richard Nuttall) (02/09/90)
wittig@gmdzi.UUCP (Georg Wittig) writes: <macros defines deleted> > Similar macros I use for the different types of loops. The advantages > are: > - ``IF'' is close enough to ``if'', so it can be understood easily. > - The programmer cannot forget the ``{}'' in the then-part or in the > else-part. > - ``END_IF'' clearly says *what* is finished --- ``}'' doesn't. > The programmer only has to remember: ``IF -- END_IF'' is the secure way > of saying ``if'' --- no problems with {}. > (Please don't tell me that ``END_IF'' are 5 keystrokes more than ``}''. > I hope those times are gone forever.) > I know I can't use bc or indent or the electric c mode of emacs any > more; but I consider that a weakness of those tools :-) > BTW, I often have to use machines and operating systems that don't have > those tools at all. So why worry too much? :-) But *every* system has a > tool called C preprocessor! Rather than defining the macros in C, use your editor to define the macros, so that when you type IF, it inserts (for example) if (X) { } /* end if */ putting your cursor at the X. ELSE can be defined to be } else { X and so on. This has the same 4 'advantages' you quote and doesn't have the disadvantages you mention. In addition, other people can now read your code. -- Richard Nuttall | stc!datlog!torch!richard Manager, X Technology | richard@torch.co.uk Torch Technology, Great Shelford, | Tel : +44 223 841000 X 308 Cambridge, CB2 5LQ, England | Fax : +44 223 840223
amull@Morgan.COM (Andrew P. Mullhaupt) (02/14/90)
In article <608@torch.co.uk>, richard@torch.co.uk (Richard Nuttall) writes: > wittig@gmdzi.UUCP (Georg Wittig) writes: > > Similar macros I use for the different types of loops. The advantages > > are: [ Attempt at 'C for humans...' deleted ] > > Rather than defining the macros in C, use your editor to define the macros, > so that when you type IF, it inserts (for example) > > if (X) > { > > } /* end if */ > > putting your cursor at the X. > > and so on. > > This has the same 4 'advantages' you quote and doesn't have the disadvantages > you mention. In addition, other people can now read your code. > Except that presumably, now he can't.* If he tries to edit code he's already written, it's already been translated to intermediate (C) code. Then we have to go back over the 'non-existence of uniform editor' ground. Like me, Georg might use more than one OS and language on a daily basis. There isn't always a convenient way to uniformly specify to each editor and in each environment what to do. (I suppose there is one but I never heard of an MVS version of 'Emacs'...) You are also up against the problem of finding a least common denominator editor which is smart enough to know that sometimes (C) you're supposed to translate 'IF' and sometimes (FORTRAN, PL/I, etc.) you're not. I really think that C serves best as an intermediate language. It goes across machines pretty well within the same OS (as long as you don't count BSD and System V as the same OS), except for the inevitable byte ordering and alignment hogwash. Versions which include 'typeof' are decidedly easy targets, and those which inline str* aren't bad either. Later, Andrew Mullhaupt * I wouldn't be so sure about the other people, either, but that's another issue.