John McCarthy died today.

[Stefan Ram]

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 ); }

 

[Joe Pfeiffer]

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;
}

 

[Kaz Kylheku]

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.

 

[Malcolm McLean]

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.

 

[Nick Keighley]

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>

 

[Phil Carmody]

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

 

[Keith Thompson]

<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.

 

[Ben Bacarisse]

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?

 

[BartC]

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.)

 

[88888 Dihedral]

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!

 

[Kenny McCormack]

<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.

Add AWK & Perl to the list. The point is that one of the selling points of
those languages is that the syntax (including the structure and the
operators) is C-like. If you change C, then they'd either have to change as
well, or lose that selling point.

And anyway, isn't it a standard dogma of this group that C and C++ are
completely different languages with almost nothing in common? That's what I
hear all the time...

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

 

[Lauri Alanko]

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

Python does not have assignment expressions, so the issue is moot.


Lauri

 

[Phil Carmody]

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

Probably so. They didn't consider themselves hostages to some
egregious 'mistake', that they had to escape from forthwith,
that's for sure. It still makes them valid data points against
the hypothesis that the choice was a mistake.

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!

In some of those languages, the visual similarity is minuscule, so I
don't think that would be an issue - their test inputs are simply not
comparable to the language the compiler/interpreter's written in.

In the original C, or the derived languages?

In C. And I support its borrowing in all languages that want to inherit
some C-like syntax, as long as holistically it's coherent enough.

Once the decision to use
"=" for assignment in C was made, using "==" for equality was
reasonable.

No more or less reasonable than something like =?, though. OK, the
set of arbitrary and vaguely sensible things it could have been isn't
huge, but it's certainly not a singleton.

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.)

Whilst I don't have a background in those languages, I do not feel
that I am lacking in any way! (But I'm happy to have studied scheme,
for example.)

Phil

 

[Jorgen Grahn]

.

And anyway, isn't it a standard dogma of this group that C and C++ are
completely different languages with almost nothing in common? That's what I
hear all the time...

They are completely different languages, with a lot in common.

/Jorgen

 

[Kaz Kylheku]

They are completely different languages, with a lot in common.

Your English dictionary must have something bizarre under the "completely"
entry.

 

[Charles Richmond]

Your English dictionary must have something bizarre under the "completely"
entry.

It is analogous to what George Bernard Shaw said:

"England and America are two countries separated by a common language."

 

[Kaz Kylheku]

It is analogous to what George Bernard Shaw said:

"England and America are two countries separated by a common language."

I'm working on a program that can be built either with a C or C++ compiler.
Most of the time I forget about this, losing my awareness of "this has to be
valid C++ too", and I neglect to build it as C++ for weeks or months.

Yet, the C++ port very rarely breaks and is easy to fix.

I just tried a C++ build: zero warnings! According to the ChangeLog, the last
time I did C++-related maintenance was on Oct 2, which was 131 commits ago. So
did 131 commits to a C program without caring that it's also C++, yet it still
compiles cleanly as C++.

C++ is a very close dialect of C, and can easily be treated as another porting
target for a C program.

 

[Kenny McCormack]

C++ is a very close dialect of C, and can easily be treated as another porting
target for a C program.

uh oh. Kiki isn't going to like this...

 

[Keith Thompson]

I'm working on a program that can be built either with a C or C++ compiler.
Most of the time I forget about this, losing my awareness of "this has to be
valid C++ too", and I neglect to build it as C++ for weeks or months.

[...]

Out of curiosity, why are you doing this? What advantage do you gain
by writing code that can compile in either language? Conversely,
what would you lose by not worrying at all about C++ compatibility
(go ahead and call that variable "class" if you like)?

My impression is that the actual need for this is much rarer than
many people seem to think it is. (I do not include you in those
"many people").

 

[Kaz Kylheku]

I'm working on a program that can be built either with a C or C++ compiler.
Most of the time I forget about this, losing my awareness of "this has to be
valid C++ too", and I neglect to build it as C++ for weeks or months.

[...]

Out of curiosity, why are you doing this? What advantage do you gain
by writing code that can compile in either language?

I can write in a "better C", which is safer, but still compiles with C
compilers.

Conversely,
what would you lose by not worrying at all about C++ compatibility
(go ahead and call that variable "class" if you like)?

One example would be that I can't build the code any more with C++ to check
that all external names are meeting type-safe linkage and the one-definition
rule.

In C, I can have "extern int x;" in in one module, and "struct foo x = { 0 };"
in another. It will link.

If you change a C program such that a function has different parameters, but
due to some broken dependencies in your build system, some dependent modules
are not recompiled, you will get a broken link. Of course, it goes away
if you do a complete rebuild, but you could waste time chasing a bug
which isn't there.

This is fixed in C++: it will catch your broken build system. Type
safe linkage won't let an int (int, char *) call go to an
int (int, char *, char *) function.

(Ironically, I had such a problem recently and didn't catch it because
I had the project configured for the C compiler!)

The real question is, why not break away from C compatibility
and just use arbitrary C++?

That's the real reason for doing this: portability. I believe that C compilers
are still more widely available. Also more widely installed. If we look at just
GNU/Linux systems, g++ will never be present without gcc. But gcc will be
present without g++.

By the way, coding this way may come upon you as a feature request
from users! Years ago I developed that Kazlib library and I made sure
the headers were squeaky clean for C++ use.

But what did some people do? They took the .c files into their C++ projects and
compiled them as C++. So I got e-mails like, "hey your code breaks C++,
can we patch it".

This is probably one niche area where you need to write
in this common dialect: whitebox-reuse libraries that can be dropped
into C or C++ projects.

That's probably when I became more receptive to the idea that hey;
you can write C and C++ at the same time.

My impression is that the actual need for this is much rarer than
many people seem to think it is. (I do not include you in those
"many people").

It's usually not a need, but an easily obtained "nice to have".

You won't see this done very often not because it is awkward or cumbersome
(which it isn't) but because (no surprise) most of the development world
doesn't really care about portability at all, let alone portability of C++ code
to C compilers.