Path: utzoo!attcan!uunet!sco!seanf
From: seanf@sco.COM (Sean Fagan)
Newsgroups: comp.std.c
Subject: Re: Macro sustitution inside quotes
Message-ID: <5611@scolex.sco.COM>
Date: 11 Apr 90 09:11:02 GMT
References: <636@mahendo.Jpl.Nasa.Gov> <1281@necisa.ho.necisa.oz> <12534@smoke.BRL.MIL> <1284@necisa.ho.necisa.oz>
Sender: news@sco.COM
Reply-To: seanf@sco.COM (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
Lines: 84


In article <1284@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes:
>String concatenation and the # operator just isn't keeping with the
>style of the language.  The # operators are particularily revolting:
>
>    #define string(s)	# s
>
>It is not obvious or intuitive what kind of expansion occurs.  

I have to agree with you there.  I get confused about # and ## all the time,
which, considering what I do for a living, means it's not going to be fun
for everyone who is relearning C (I suspect people learning it from scratch
will not have this problem).

>Whereas:
>
>    #define string(s)	"s"
>
>evaluates in the way you would expect.

Yes.  On "my" compiler, it certainly does.  It expands as "s", no matter
what is passed into string.

>Apart from that, # operators break things.  

Uhm, what does it break, pray tell?  I know of no valid construct in C which
allows '#' (except preprocessor directives, and I have never seen anyone use
a p.p. directive *inside* a macro).

>Why weren't the Reiser
>conventions just formalised?  Oh no, that would be too easy.

Because some of us think it is really stupid, disgusting, etc.  Perhaps you
also want to check for '*/' inside of quotes?  Or how about non-paramater
macros?  (Checking for parameter expansions *only* was more difficult in my
implementation, albeit not much.)

>There is no basis in the language for string concatenation.  It is
>at odds with the lexical and syntactic structure of the language.

Maybe.  However, I happen to like it.  It is easy to remember, and breaks
nothing.

>Function calls:
>
>    f(a, b)
         ^
>Not:
>
>    f(a b)

Uhm, actually, it did.  Note that the space is optional in C, both K&R, 
Reiser, and ANSI.

>The preprocessor and language weren't broken.  But they got `fixed' anyway.

You pointed it out yourself.  The "Reiser" conventions.  Other people were
*not* doing it that way, and it was not used in K&R.  The preprocessor was
lacking, in terms of stringizing (although I really really want a
characterizer 8-)), and concatenating strings is a truly *marvelous*
thing to do.  There is one program in AT&T's distribution which has a 7k
long string.  All but the first line begins at the first character, and is
really difficult to read.  Using string concatenation, it ends up being
*much* easier, and is very difficult to confuse it with the rest of the
program (consider:

	char *p = "to declare a variable of type int in C, use \
	int a; \
	Simple, no?";

versus

	char *p = "to declare a variable of type in in C, use "
		"int a; "
		"Simple, no?";

I prefer the latter.  If you don't, maybe you should stick with fortran?)

-- 
-----------------+
Sean Eric Fagan  | "It's a pity the universe doesn't use [a] segmented 
seanf@sco.COM    |  architecture with a protected mode."
uunet!sco!seanf  |         -- Rich Cook, _Wizard's Bane_
(408) 458-1422   | Any opinions expressed are my own, not my employers'.