#define OR ||

Andrew P. Mullhaupt amull at Morgan.COM
Wed Feb 14 03:36:48 AEST 1990


In article <608 at torch.co.uk>, richard at torch.co.uk (Richard Nuttall) writes:
> wittig at 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.



More information about the Comp.lang.c mailing list