Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > John McCarthy died today.

Reply
Thread Tools

John McCarthy died today.

 
 
Stefan Ram
Guest
Posts: n/a
 
      11-10-2011
James Kuyper <(E-Mail Removed)> writes:
>On 11/08/2011 05:10 PM, Keith Thompson wrote:
>> while (1) {
>> int c = getchar();
>> if (c == EOF) break;
>> process_char(c);
>> }

>I generically dislike while(1) loops


What I do sometimes in difficult cases is the looping loop:

for( int looping = 1; looping; )
{ int const c = getchar();
if( c == EOF || feof( stdin )|| ferror( stdin ))looping = 0;
else process( c ); }

 
Reply With Quote
 
 
 
 
Joe Pfeiffer
Guest
Posts: n/a
 
      11-10-2011
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:

> James Kuyper <(E-Mail Removed)> writes:
>>On 11/08/2011 05:10 PM, Keith Thompson wrote:
>>> while (1) {
>>> int c = getchar();
>>> if (c == EOF) break;
>>> process_char(c);
>>> }

>>I generically dislike while(1) loops

>
> What I do sometimes in difficult cases is the looping loop:
>
> for( int looping = 1; looping; )
> { int const c = getchar();
> if( c == EOF || feof( stdin )|| ferror( stdin ))looping = 0;
> else process( c ); }


Of course, your looping loop doesn't translate a while(1). The while()
equivalent (going back to the OP's logic, and switching the if to what I
prefer) would be

looping = 1;
while (looping) {
int c = getchar();
if (c != EOF)
process(c);
else
looping = 0;
}
 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-10-2011
On 2011-11-10, Joe Pfeiffer <(E-Mail Removed)> wrote:
> (E-Mail Removed)-berlin.de (Stefan Ram) writes:
>
>> James Kuyper <(E-Mail Removed)> writes:
>>>On 11/08/2011 05:10 PM, Keith Thompson wrote:
>>>> while (1) {
>>>> int c = getchar();
>>>> if (c == EOF) break;
>>>> process_char(c);
>>>> }
>>>I generically dislike while(1) loops

>>
>> What I do sometimes in difficult cases is the looping loop:
>>
>> for( int looping = 1; looping; )
>> { int const c = getchar();
>> if( c == EOF || feof( stdin )|| ferror( stdin ))looping = 0;
>> else process( c ); }

>
> Of course, your looping loop doesn't translate a while(1). The while()
> equivalent (going back to the OP's logic, and switching the if to what I
> prefer) would be
>
> looping = 1;
> while (looping) {
> int c = getchar();
> if (c != EOF)
> process(c);
> else
> looping = 0;
> }


Many times in the past, I have found useful the following approach:

Code a loop with no guard condition, but with a break at the end.

Then use explicit continue statements to continue iterating:

for (; {
int c = getchar();

/* look at C and handle cases which should continue */
switch (c) {
case '{':
...
continue;
case '!':
...
continue;
EOF:
break;
}

break;
}

This also solves the problem that "break" inside the switch does not
break out of the loop. We break out of the loop by falling to the end;
to continue the loop we use continue, which is not intercepted
by switch.
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      11-10-2011
On Nov 9, 11:25*pm, Keith Thompson <(E-Mail Removed)> wrote:
>
> Or here's another idea. *Leave "=" the way it is, and let compilers
> issue an optional warning when "=" is used in a context where "=="
> is probably what was meant.
>

I've used compilers which did that

while(ch = fgetc(fp))

would trigger a warning

while( (ch = fgetc(fp)) != 0)

would not.
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      11-10-2011
On Nov 9, 9:25*pm, Keith Thompson <(E-Mail Removed)> wrote:

<snip>

> Changing "=" to ":=" as you propose is an all-or-nothing change.
> If the C201X standard made such a change (it won't), there would
> be a transition period of, probably, a couple of decades in which
> you could either ignore the new standard altogether (the most
> likely outcome for most programmers), *or* you could maintain two
> versions of every single C source file. *That maintenance could be
> largely automated, but there would be as many inconsistent automated
> solutions as there are development environments.
>
> Oh, and try getting agreement from the C++ standard committee while
> you're at it. *And Objective-C (I don't know whether there's a
> committee for that, but Objective-C is closely upward-compatible
> with C).


what about C#, Java, Python
or is that just too much?

<snip>
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      11-10-2011
Kaz Kylheku <(E-Mail Removed)> writes:
> On 2011-11-08, Edward Rutherford <(E-Mail Removed)> wrote:
> > Keith Thompson wrote:
> >
> >> Using "=" for assignment was not, in my opinion, a good idea. Any
> >> attempt to change it now would be far worse.

> >
> > With this attitude, the language will never improve!

>
> Inextensible languages like C do improve or at least evolve by creating
> spin-offs which are new languages. Some are backward-compatible (Objective C).
> Some have a lot of backward compatibility (C++). Others are incompatible
> (Java).
>
> Speaking of which, even though Java is not meant to be compatible with C, its
> assignment operator is = and comparison is ==.
>
> Oops!


As is JavaScript's, and perl's, and LUA's, and python's ...

Was the decision really such a bad mistake if it's been willingly
repeated so often?

I'll pin my colours to the mast - I do not consider the choice of those
tokens to be a mistake.

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-10-2011
Nick Keighley <(E-Mail Removed)> writes:
> On Nov 9, 9:25*pm, Keith Thompson <(E-Mail Removed)> wrote:
> <snip>

[...]
>> Oh, and try getting agreement from the C++ standard committee while
>> you're at it. *And Objective-C (I don't know whether there's a
>> committee for that, but Objective-C is closely upward-compatible
>> with C).

>
> what about C#, Java, Python
> or is that just too much?


If C made such a change, there would be no particular motivation
for C#, Java, or Python to follow suit. C++ and Objective-C have
C compatibility as a significant selling point.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-10-2011
Phil Carmody <(E-Mail Removed)> writes:
<snip>
> I'll pin my colours to the mast - I do not consider the choice of those
> tokens to be a mistake.


No, me neither, though I have a slight preference for an asymmetric
symbol for assignment since the operation is asymmetric.

More to the point, I don't recall any "hard" bug being caused by a =/==
confusion. Sure, it happens, but the bug shows up immediately the code
is tested. In contrast, A </<= error (which can be either a typo or a
misunderstanding) can often be quite hard to track down. Does anyone
recall a =/== bug that was anything but trivial?

--
Ben.
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-10-2011
"Phil Carmody" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Kaz Kylheku <(E-Mail Removed)> writes:


>> Speaking of which, even though Java is not meant to be compatible with C,
>> its
>> assignment operator is = and comparison is ==.
>>
>> Oops!

>
> As is JavaScript's, and perl's, and LUA's, and python's ...
>
> Was the decision really such a bad mistake if it's been willingly
> repeated so often?


Those languages were likely implemented in C. In which case, they would be
quite receptive to the idea of using "=" and "==".

And if they had considered using ":=" and "=" instead, they would quickly
have found that mixing up ":="/"=" and "="/"==" (between writing the C code
and testing fragments of the new language) caused too many problems!


> I'll pin my colours to the mast - I do not consider the choice of those
> tokens to be a mistake.


In the original C, or the derived languages? Once the decision to use "="
for assignment in C was made, using "==" for equality was reasonable. Using
..EQ. would be too naff, and using context was not possible as assignments
also occur in expressions.

(I think PL/I allowed "=" for both assignment/equality, maybe it did use
context, but that was quite hairy to implement anyway.)

--
Bartc

 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      11-10-2011
I think in C the assignment = is OK. But if C is to be used to model HW circuits then the blocking and non-blocking assignment is different. There is ways around!
For example, use an object way that the next property for HW objects to change values. C++ people usually don't like to talk about HW related properties such as pointers in C and pointer operations and stacks in compilers. Thus C is better to extend its usage in HW descriptions in the future. ANSI ASCII was an encode to express color letters in BBS in 199X. And that time those BBS programs are most written in C. Now html/xml/CSS take over the jobs!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
DVD Verdict reviews: JOHN WAYNE-JOHN FORD FILM COLLECTION and more! DVD Verdict DVD Video 0 06-06-2006 08:23 AM
Printer & File Sharing Died =?Utf-8?B?Sm9obiBSYXR6ZW5iZXJnZXI=?= Wireless Networking 10 06-18-2005 07:50 PM
format first name from -john- to -John- ? RN ASP .Net 3 02-27-2005 05:34 AM
REVIEW: "The Hanged Man's Song", John Sandford (John Camp) Rob Slade, doting grandpa of Ryan and Trevor Computer Security 0 01-26-2004 04:28 PM
REVIEW: "The Devil's Code", John Sandford (John Camp) Rob Slade, doting grandpa of Ryan and Trevor Computer Security 0 07-03-2003 06:43 PM



Advertisments