Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Aug 2001 01:46:57 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        John Merryweather Cooper <jmcoopr@webmail.bmi.net>
Cc:        obrien@FreeBSD.ORG, "hackers @ FreeBSD . ORG" <hackers@FreeBSD.ORG>
Subject:   Re: the =+ operator
Message-ID:  <3B779401.E07DB4DB@mindspring.com>
References:  <3B73F0BC.548D40B3@home.com> <3B757D14.B344931@mindspring.com> <20010811121857.A41578@johncoop> <20010812150226.A5074@dragon.nuxi.com> <20010812152443.C39719@johncoop>

next in thread | previous in thread | raw e-mail | index | archive | help
John Merryweather Cooper wrote:
> > > Prototypes are an overwhelmingly "Good Thing(tm)"
> > > as behind-your-back implicit parameter conversion is death to serious
> > > numerical work.  At least now, some control can be exercised over
> > parameter
> > > conversions . . .
> >
> > Who ever said anything about not being able to do that in Terry's view?
> > You are taking one statement and running wildly with it.
> >
> In my view, he was advocating chucking ANSI-89 and returning to the wild
> days of K&R.  I think that would be very bad.  Clearly, you disagree with
> my understanding.

Not my intent; I'm well known to dislike many of the decisions
that the X3J11 committe made; in comp.lang.c, there was a long
firefight, which only ended after dmr@research.att.com came down
on my side of the argument and said:

	Let me begin by saying that I'm not convinced that
	even the pre-December qualifiers (`const' and `volatile')
	carry their weight; I suspect that what they add to the
	cost of learning and using the language is not repaid in
	greater expressiveness. `Volatile', in particular, is a
	frill for esoteric applications, and much better expressed
	by other means.  Its chief virtue is that nearly everyone
	can forget about it.  `Const' is simultaneously more
	useful and more obtrusive; you can't avoid learning about
	it, because of its presence in the library interface.
	Nevertheless, I don't argue for the extirpation of
	qualifiers, if only because it is too late. 

	The fundamental problem is that it is not possible to
	write real programs using the X3J11 definition of C.
	The committee has created an unreal language that no
	one can or will actually use.  While the problems of
	`const' may owe to careless drafting of the
	specification, `noalias' is an altogether mistaken
	notion, and must not survive.

See http://www.lysator.liu.se/c/dmr-on-noalias.html for the
full text of his posting.

He also has a couple of choice words on prototypes requiring
themselves.

> In benchmarking IBM's VisualAge C++ (Version 4.0), this seems to be the
> case, at least for me.  I chose this compiler because it is easy, with the
> tools available for me to monitor the stages of compilation since each
> stage has a separate DLL.  Using SciTech's MGL 5.0 Beta 2 Library, it is
> clear that Lexing/pre-processing take up the lion's share of the time.
> Obviously, your mileage differs.  I would like to have your understanding
> of what's happening--and not this "troll-mine."

What's happeneing is that compiler users outnumber compiler
writers, 100,000 to 1.

Ergo, if a compiler writer can make a change that saves 1 hour
of user time, he has saved 100,000 hours or user time.

That is over 11 man years.

Clearly, all tradeoffs should be made in favor of compiler users,
not in favor of compiler writers, for the betterment of mankind.


> I know it's ambiguous.  In fact, I think it's the most poorly
> standardized/described language to date.  However, since C++ is quite
> popular, apparently my opinion doesn't carry much weight.  :)

The popularity of C++ was one of the driving factors behind
the inclusion of prototypes.

Even using symbol "decoration", the approach used by both GCC
and Microsoft Visual C++, there is enough information present
for parameter errors to be identified and corrected at link
time.  The problem at the time, however, is that there was a
race between Microsoft and Borland to have the "fastest
compiler"; not that this doesn't mean "the compiler that puts
out the fastest code" or "the compiler that makes the jobs
done by the programmers who use it take the shortest amount
of time".  So we got standardization of a language in which
there were exposed bolts like "volatile" and "const", which
make the compiler writer's job (defined as compiling fast)
easier, since barring these keywords, they were allowed to
make assumptions that broke previously working code.


> From the reading I've done, I believe this conclusion is justified.
> Doubtless there are other opinions though . . .

	The C Programming Language
	Brian W. Kernighan, Dennis M. Ritchie
	Prentice-Hall
	ISBN: 0-13-110163-3

	P. 212:

	17. Anachronisms

	    Since C is an evolving language, certain obsolete
	constructions may be found in older programs.  Although
	most versions of the compiler support such anachronisms,
	ultimately they will disappear, leaving only a portability
	problem behind.
	    Earlier versions of C used the form =op instead of
	op= for assignment operators.  This leads to ambiguities,
	typified by
		x=-1
	Which actually decerments x since the = and the - are
	adjacent, but which might easily be intended to assign -1
	to x.
	    The syntax of initializers has changed: previously,
	the equals sign that introduces an initializer was not
	present, so instead of
		int  x      = 1;
	one used
		int  x      1;
	This change was made because the initialization
		int  f      (1+2)
	resembles a function declaration closely enough to confuse
	the compilers.

In general, this is not a "call to better days" (though the days
before prototypes, when stack variables were all sign extended to
int were certainly easier to do interesting things with); it is
simply noteing that we should not forget history, nor believe that
thigs were always as they are now, or that the way they are now
is somehow better, merely because "now" is more recent.

Some of the explanations for the =op that were posted to this
list were truly ridiculous, in light of the actual history, which
was available with only a little poking (yes, the authors of the
code knew what they were doing, at the time the code was written).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B779401.E07DB4DB>