Hey! Some questions about C that have been bugging me for a while...
1) Is inline a valid C keyword or not? I was kind of surprised of not
finding it in C, to be honest. My "The C Programming Language" book
doesn't mention it.
2) I understand that C doesn't care about whitespace that much, but why
did they make it impossible to use the minus ('-') char in variable
names? I now have to incorrectly name my "hi-score" variable "hiscore".
:(
3) Is using "const" in C considered good practice? I have had little
need to do so so far thanks to #define.
4) I kind of hate C-like comments. I use C++ comments mostly in my C
programs. Is this evil?
5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
PS: I started with C++ and went "back" to C after several years of not
getting anything done thanks to the damn OOP. In C, I'm all creative
again! ^__^
-- http://www.kimmoa.se/ 66  3638 
KimmoA wrote:
Hey! Some questions about C that have been bugging me for a while...
1) Is inline a valid C keyword or not? I was kind of surprised of not
finding it in C, to be honest. My "The C Programming Language" book
doesn't mention it.
It is valid in C99 but not in C89.
>
2) I understand that C doesn't care about whitespace that much, but why
did they make it impossible to use the minus ('-') char in variable
names? I now have to incorrectly name my "hi-score" variable "hiscore".
Because the compiler wouldn't be able to tell
whether hi-score subtracts score from hi or is
the name of a single variable. If it's any consolation
to you hi-score is also incorrectly named.
3) Is using "const" in C considered good practice? I have had little
need to do so so far thanks to #define.
It is good practice for declaring constant objects. If for
example a function is not supposed to modify an
argument , then you use const. #define wouldn't help in
this case.
>
4) I kind of hate C-like comments. I use C++ comments mostly in my C
programs. Is this evil?
C comments are beautiful ; C++ comments are ugly.
5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
Makes sense as opposed to what ?
Spiros Bousbouras wrote:
1) Is inline a valid C keyword or not? I was kind of surprised of not
finding it in C, to be honest. My "The C Programming Language" book
doesn't mention it.
It is valid in C99 but not in C89.
Hmm... I guess I'm following C99, then. I'm not explictly telling my
compiler (MinGW) about this, though.
2) I understand that C doesn't care about whitespace that much, but why
did they make it impossible to use the minus ('-') char in variable
names? I now have to incorrectly name my "hi-score" variable "hiscore".
Because the compiler wouldn't be able to tell
whether hi-score subtracts score from hi or is
the name of a single variable.
Yeah, but why not require spaces in between for that operation? You
should code with "air"... :(
Of course, nothing can or will be changed by now, but it's still nice
to hear the reasoning. Was C designed with obfuscation contests in
mind? ;)
If it's any consolation to you hi-score is also incorrectly named.
Do you mean that it should say "high-score"?
C comments are beautiful ; C++ comments are ugly.
I find C as a whole to be rather beautiful. At least relatively.
However, the comments are just crappy IMO. Just like in CSS, you have
to end them, and they use two different chars. /* This doesn't
encourage me to comment! */
At least C++-like comments are two of the same char and don't need to
be ended!
// Aaah! I like commenting stuff this way!
I guess that this, again, has to do with the nature of C and the almost
total lack of care about whitespace.
At least it (C99?) accepts C++-style comments.
5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
Makes sense as opposed to what ?
As opposed to having a special data type called "bool". If nothing
else, it helps telling me what's a "boolean" and what's a "high number"
variable.
-- http://www.kimmoa.se/
In article <11**********************@e3g2000cwe.googlegroups. com>,
KimmoA <ki****@gmail.comwrote:
>Hey! Some questions about C that have been bugging me for a while...
>2) I understand that C doesn't care about whitespace that much, but why
did they make it impossible to use the minus ('-') char in variable
names? I now have to incorrectly name my "hi-score" variable "hiscore".
:(
hi_score
(Note, though, that there are various restrictions having to do
with starting identifiers with underscores, or ending identifiers
with _t or a few other prefixes that I don't recall offhand.)
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
KimmoA wrote:
Spiros Bousbouras wrote:
1) Is inline a valid C keyword or not? I was kind of surprised of not
finding it in C, to be honest. My "The C Programming Language" book
doesn't mention it.
It is valid in C99 but not in C89.
Hmm... I guess I'm following C99, then. I'm not explictly telling my
compiler (MinGW) about this, though.
Or it could be that your compiler is implementing
some C99 extensions bur not all of them.
>
2) I understand that C doesn't care about whitespace that much, but why
did they make it impossible to use the minus ('-') char in variable
names? I now have to incorrectly name my "hi-score" variable "hiscore".
Because the compiler wouldn't be able to tell
whether hi-score subtracts score from hi or is
the name of a single variable.
Yeah, but why not require spaces in between for that operation? You
should code with "air"... :(
Of course, nothing can or will be changed by now, but it's still nice
to hear the reasoning. Was C designed with obfuscation contests in
mind? ;)
I was only guessing about the reasoning. Extra space
would make the code longer and back in those days
they didn't have a lot of memory.
>
If it's any consolation to you hi-score is also incorrectly named.
Do you mean that it should say "high-score"?
Yes.
>
C comments are beautiful ; C++ comments are ugly.
I find C as a whole to be rather beautiful. At least relatively.
However, the comments are just crappy IMO. Just like in CSS, you have
to end them, and they use two different chars. /* This doesn't
encourage me to comment! */
I find the visual symmetry between /* and */ very pleasing.
>
At least C++-like comments are two of the same char and don't need to
be ended!
But they are automatically ended by newline. If I
had a multiline comment it would drive me crazy
if I had to type at the beginning of each line //. It
gets on my nerves with shell or awk and you only
need to type # there.
>
// Aaah! I like commenting stuff this way!
I guess that this, again, has to do with the nature of C and the almost
total lack of care about whitespace.
At least it (C99?) accepts C++-style comments.
Yes , it's C99.
>
5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
Makes sense as opposed to what ?
As opposed to having a special data type called "bool". If nothing
else, it helps telling me what's a "boolean" and what's a "high number"
variable.
C99 has _Bool in stdbool.h. But internally they
may be still stored as an int.
Spiros Bousbouras wrote:
5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
>
Makes sense as opposed to what ?
As opposed to having a special data type called "bool". If nothing
else, it helps telling me what's a "boolean" and what's a "high number"
variable.
C99 has _Bool in stdbool.h. But internally they
may be still stored as an int.
"_Bool" isn't that pretty. Why did they decide on this, rather than
"bool"? Or am I missing something now?
-- http://www.kimmoa.se/
"KimmoA" <ki****@gmail.comwrites:
Hey! Some questions about C that have been bugging me for a while...
1) Is inline a valid C keyword or not? I was kind of surprised of not
finding it in C, to be honest. My "The C Programming Language" book
doesn't mention it.
"inline" is a valid keyword in C99, but not in C89/C90.
C89 is the 1989 ANSI standard, the first official standard for the
language. In 1990, ISO adopted the ANSI standard (with some cosmetic
changes that don't affect the language in any way, such as renumbering
the sections of the standard document); ANSI then adopted the ISO
standard. C89 and C90 are two different standard documents that
describe the same language.
C99 is the 1999 ISO standard. Officially, it supersedes and replaces
the C90 standard, but very few implementations fully support it.
Unfortunately, it is not yet possible to use C99 features in portable
code.
C90 is almost completely supported, but few compilers yet implement
all of C99. Many compilers implement *some* C99 features, but
different compilers don't necessarily implement the *same* C99
features. And a lot of the new C99 features require support in the
runtime library, which may come from a different provider than the
compiler.
"inline" in particular was a fairly common extension even before C99.
2) I understand that C doesn't care about whitespace that much, but why
did they make it impossible to use the minus ('-') char in variable
names? I now have to incorrectly name my "hi-score" variable "hiscore".
:(
Just call it "hi_score". "hi-score" already has a meaning:
"hi - score". I suppose C could have required whitespace around
operators, but the language itself tends not to impose style rules,
and sometimes you might want to use operators without whitespace for
emphasis:
x + y*z
3) Is using "const" in C considered good practice? I have had little
need to do so so far thanks to #define.
It's good practice, but remember that "const" doesn't mean "constant";
it means read-only. Unlike in C++, an object declared "const" doesn't
give you something you can use in a constant expression; it just means
that you can't modify the object.
const int x = 42;
x = 43; /* illegal, x is const */
switch(some_expr) {
case x: /* illegal, x is not a constant expression */
...
}
4) I kind of hate C-like comments. I use C++ comments mostly in my C
programs. Is this evil?
It means your program can't be compiled by a strict C90 compiler. It
also means that, if you post your code here, you're likely to have
syntax errors. News software often wraps long lines. If a "/*
.... */" is wrapped, it's still a comment; if a "// ..." comment is
wrapped, the end of it is no longer part of a comment, and will
introduce a syntax error *if you're lucky*. (If you're unlucky, it
will happen to compiler anyway.)
5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
C99 has _Bool as a keyword; the new <stdbool.hheader defines "bool",
"false", and "true". (Why the ugly keyword? "bool" is a legal
identifier in C90, and a lot of C90 code defines its own bool type;
making "book" a keyword would have broken such code.)
The comp.lang.c FAQ is at <http://www.c-faq.com/>. Read section 9,
"Boolean Expressions and Variables".
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
CBFalconer wrote:
"_Bool" isn't that pretty. Why did they decide on this, rather than
"bool"? Or am I missing something now?
To avoid invading the users name space. The user can #include
<stdbool.hto put define 'bool' as a synonym for _Bool, and to
define true and false.
This way C90 programs that did internal definitions for bool, true,
false can still compile under C99.
.... at the expense of beautiful code and, IMO, rendering _Bool useless.
(Why the capital 'B' anyway?)
I didn't even know about C90. I thought that there were only two real
standard specifications of C ever: C89 and C99.
-- http://www.kimmoa.se/
"KimmoA" <ki****@gmail.comwrites:
CBFalconer wrote:
"_Bool" isn't that pretty. Why did they decide on this, rather than
"bool"? Or am I missing something now?
To avoid invading the users name space. The user can #include
<stdbool.hto put define 'bool' as a synonym for _Bool, and to
define true and false.
This way C90 programs that did internal definitions for bool, true,
false can still compile under C99.
... at the expense of beautiful code and, IMO, rendering _Bool useless.
(Why the capital 'B' anyway?)
What expense? If you want to use "bool", "false", and "true" in C99
code, just put a "#include <stdbool.h>" at the top of your source
file.
The capital 'B' is there so the keyword is in the namespace reserved
to the implementation. The identifier "_bool" can legally be used in
C90 user code in some restricted circumstances; the identifier "_Bool"
cannot.
But you don't need to use "_Bool" at all.
I didn't even know about C90. I thought that there were only two real
standard specifications of C ever: C89 and C99.
C90 is the same language as C89 (see my other response in this thread
for details).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
C99 is the 1999 ISO standard. Officially, it supersedes and replaces
the C90 standard, but very few implementations fully support it.
Unfortunately, it is not yet possible to use C99 features in portable
code.
I wonder how good MinGW is at this. It's supposed to be "gcc for
Windows".
"inline" in particular was a fairly common extension even before C99.
Ah. It makes sense, really. Seems like an awfully useful keyword. But
what about macro "functions"? Which one is superior? Do they have
different uses? I assume the latter.
2) I understand that C doesn't care about whitespace that much, but why
did they make it impossible to use the minus ('-') char in variable
names? I now have to incorrectly name my "hi-score" variable "hiscore".
:(
Just call it "hi_score". "hi-score" already has a meaning:
"hi - score". I suppose C could have required whitespace around
operators, but the language itself tends not to impose style rules,
and sometimes you might want to use operators without whitespace for
emphasis:
x + y*z
Yeah. I find "x=y+z-i*h;" code to be really ugly and unreadable. Yet I
see it in most code I study. Maybe that's one of the reasons I don't
really like open source -- I can't read other people's programs. :)
Also, I like to abuse '('s and ')'s. I find this to enhance the
readability greatly. I just don't trust the implementation to do the
math expression in the correct order! In highschool, my TI screen was
filled with them...
5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
C99 has _Bool as a keyword; the new <stdbool.hheader defines "bool",
"false", and "true". (Why the ugly keyword? "bool" is a legal
identifier in C90, and a lot of C90 code defines its own bool type;
making "book" a keyword would have broken such code.)
C90 is hereby my primary personal enemy.
The comp.lang.c FAQ is at <http://www.c-faq.com/>. Read section 9,
"Boolean Expressions and Variables".
Aha! A useful resource!
-- http://www.kimmoa.se/
"KimmoA" <ki****@gmail.comwrites:
Keith Thompson wrote:
>C99 is the 1999 ISO standard. Officially, it supersedes and replaces
the C90 standard, but very few implementations fully support it.
Unfortunately, it is not yet possible to use C99 features in portable
code.
I wonder how good MinGW is at this. It's supposed to be "gcc for
Windows".
The gcc folks publish the current C99 status of gcc. See
<http://gcc.gnu.org/c99status.html>. (The server seems to be down at
the moment.)
>"inline" in particular was a fairly common extension even before C99.
Ah. It makes sense, really. Seems like an awfully useful keyword. But
what about macro "functions"? Which one is superior? Do they have
different uses? I assume the latter.
They have different uses. Function-like macros can be very tricky.
Macros are expanded textually, and it's very easy to mess things up.
[snip]
Also, I like to abuse '('s and ')'s. I find this to enhance the
readability greatly. I just don't trust the implementation to do the
math expression in the correct order! In highschool, my TI screen was
filled with them...
Parentheses affect which operands are associated with which operators.
They don't (necessarily) affect evaluation order.
5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
C99 has _Bool as a keyword; the new <stdbool.hheader defines "bool",
"false", and "true". (Why the ugly keyword? "bool" is a legal
identifier in C90, and a lot of C90 code defines its own bool type;
making "book" a keyword would have broken such code.)
(Sorry, I meant that making "bool" a keyword would have broken such
code.)
C90 is hereby my primary personal enemy.
You are overreacting. A lot.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
C90 is hereby my primary personal enemy.
You are overreacting. A lot.
Well... maybe. ;)
-- http://www.kimmoa.se/
KimmoA wrote:
Spiros Bousbouras wrote:
>>>>5) I feel kind of naked without bool, but I understand that by the way
computers work, an int holding only 0 or 1 makes the most sense. Or
something. Does it?
Makes sense as opposed to what ?
As opposed to having a special data type called "bool". If nothing
else, it helps telling me what's a "boolean" and what's a "high number"
variable.
C99 has _Bool in stdbool.h. But internally they
may be still stored as an int.
"_Bool" isn't that pretty. Why did they decide on this, rather than
"bool"? Or am I missing something now?
--
http://www.kimmoa.se/
You could use typedef or enum to get a bool.
// and /* */ will both work
// did not make it into C till now becuase the purist do not like //,
they prefer /* */.
I my opinion a pure style issue.
like
highScore
HighScore
high_score
nHighScore
ect.
Neil wrote:
You could use typedef or enum to get a bool.
I guess...
// did not make it into C till now becuase the purist do not like //,
they prefer /* */.
When is "now"? I assume that C99 was made in 1999...
highScore
HighScore
high_score
nHighScore
ect.
CamelCase is evil!
-- http://www.kimmoa.se/
KimmoA wrote:
Neil wrote:
// did not make it into C till now becuase the purist do not like //,
they prefer /* */.
When is "now"? I assume that C99 was made in 1999...
It was. Few compilers yet implement C99 fully, though many implement //
comments. They were also available as an extension in many C compilers
long before C99 became a standard.
In article <11**********************@p79g2000cwp.googlegroups .com>, "Spiros Bousbouras" <sp****@gmail.comwrites:
KimmoA wrote:
2) I understand that C doesn't care about whitespace that much, but why
did they make it impossible to use the minus ('-') char in variable
names? I now have to incorrectly name my "hi-score" variable "hiscore".
Because the compiler wouldn't be able to tell
whether hi-score subtracts score from hi or is
the name of a single variable. If it's any consolation
to you hi-score is also incorrectly named.
I'll note that in COBOL, which does allow the hyphen in identifier
names (and where, indeed, it is used to excess), this can make for
some ugly code. Subtraction in COBOL programs is most often done
with the SUBTRACT verb, but sometimes it's done with the COMPUTE verb
and the "-" operator, and often it's done as part of an inline
expression; and requiring whitespace in those last two contexts often
has unpleasing results.
For example, in reference modification:
move foo(ws-start-pos:ws-curr-len - 1) to
bar(ws-end-pos - 1:ws-remaining-len)
or some such. Yes, more linear whitespace can be sprinkled in there,
but hyphens are simply visual noise when they're mixed with the minus
symbol. It's better to do without them.
And, of course, it's an unnecessary complication for the language
syntax, which means more work for anyone describing or trying to
understand the syntax, and more work for the parser.
Alternatives for delimiting parts of identifier names are the
underscore and mixed-case.
4) I kind of hate C-like comments. I use C++ comments mostly in my C
programs. Is this evil?
C comments are beautiful ; C++ comments are ugly.
The last I checked, "C++ comments" included the C90 comment syntax,
and matched the C99 comment syntax.
C99 comment syntax is not part of C90, though it is a common
extension. If you use it, you may encounter problems with some C90
implementations. Personally, I think it's ugly and not particularly
useful.
--
Michael Wojcik mi************@microfocus.com
Even 300 years later, you should plan it in detail, when it comes to your
summer vacation. -- Pizzicato Five
Michael Wojcik wrote:
I'll note that in COBOL, which does allow the hyphen in identifier
names (and where, indeed, it is used to excess), this can make for
some ugly code. Subtraction in COBOL programs is most often done
with the SUBTRACT verb, but sometimes it's done with the COMPUTE verb
and the "-" operator, and often it's done as part of an inline
expression; and requiring whitespace in those last two contexts often
has unpleasing results.
I didn't know that it had both a "SUBTRACT" keyword AND a '-' operator.
Weird stuff. COBOL scares me even more than obfuscated C code. ;)
The last I checked, "C++ comments" included the C90 comment syntax,
and matched the C99 comment syntax.
Note that I meant "C++-style comments". Any C++ program is per
definition (of its creator, Bjarne Stroustrup) also a C program (or was
it the other way around, or vice versa?). Anyway... it's
backwards-compatible!
-- http://www.kimmoa.se/
"KimmoA" <ki****@gmail.comwrites:
[...]
Note that I meant "C++-style comments". Any C++ program is per
definition (of its creator, Bjarne Stroustrup) also a C program (or was
it the other way around, or vice versa?). Anyway... it's
backwards-compatible!
No, it isn't. C++ is *nearly* a superset of C, but there are plenty
of valid C programs that are not valid C++ programs, and some that are
valid C++ programs but with a different meaning.
Examples:
Any C program using "class", "new", "delete", "try", "throw", or any
other C++ keyword as an identifier.
Any C program that assigns the result of malloc to a pointer variable
(of a type other than void*) without a cast. (This is good style in
C, illegal in C++.)
A C90 program that has a "/" delimiter (division operator) immediately
followed by a "/* ... */" comment. (This is poor style in C.)
And so forth.
C and C++ are two different languages.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
That's what I meant. Sorry.
-- http://www.kimmoa.se/
KimmoA wrote:
Any C++ program is per
definition (of its creator, Bjarne Stroustrup) also a C program
I haven't done a thorough search of Bjarne's book, but I certainly don't
recall ever seeing any statement to that effect. Even when C++ was
implemented primarily as a C preprocessor filter, it was strongly
regarded as an entirely separate language.
KimmoA wrote:
Keith Thompson wrote:
>C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
That's what I meant. Sorry.
Stroustrup says no such thing. He does say:
"With minor exceptions, C++ is a superset of C (meaning C89, defined by
ISO/IEC 9899:1990). Most differences stem from C++'s greater emphasis
on type checking. Well-written C programs tend to be C++ programs as
well. A compiler can diagnose every difference between C++ and C."
He also says:
"...[G]reat importance was attached to retaining a high degee of
compatability with C;... this precluded cleaning up the C syntax."
jmcgill wrote:
KimmoA wrote:
Keith Thompson wrote:
C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
That's what I meant. Sorry.
Stroustrup says no such thing. He does say:
"With minor exceptions, C++ is a superset of C (meaning C89, defined
by ISO/IEC 9899:1990). Most differences stem from C++'s greater
emphasis on type checking. Well-written C programs tend to be C++
programs as well. A compiler can diagnose every difference between
C++ and C."
He also says:
"...[G]reat importance was attached to retaining a high degee of
compatability with C;... this precluded cleaning up the C syntax."
He also said, ". . . good C programs tend to be C++ programs. For
instance, every program in [K&R 2] is a C++ program."
Now, that last bit is an exaggeration, as much of K&R 2 uses implicit
in in a number of places. Anyway, I think that statement is where the
"every C program is a C++ program" idea tends to come from.
Brian
Default User wrote:
He also said, ". . . good C programs tend to be C++ programs. For
instance, every program in [K&R 2] is a C++ program."
You have an edition/page number for that?
"KimmoA" <ki****@gmail.comwrites:
Keith Thompson wrote:
>C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
That's what I meant. Sorry.
That's not right either.
There is rarely any good reason for well-written C to avoid using
"new", "delete", "class", etc. as identifiers.
And well-written C definitely shouldn't cast the result of malloc()
(doing so can mask errors).
The only exception is when you have some real requirement to write
code that will compile as either C or C++. In real life, such a
requirement is almost vanishingly rare.
If you want to write C++, do so. If you want to write C++ while
restricting yourself to a C-like subset of the language, you're free
to do that as well. But if you want to write C, just write C.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
KimmoA posted:
Keith Thompson wrote:
>C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
That's what I meant. Sorry.
Incorrect. See Keith's reasons up-thread (to name but a few).
--
Frederick Gotham
I have now looked it up (yes -- I just HAD to!). Instead of quoting all
you people have said, I'll just write a reply.
In "The C++ Programming Language" (Special Edition), on the bottom of
page 13 (chapter 1, section 1.5), he (Bjarne) says:
"However, good C programs tend to be C++ programs. For example, every
program in [The C Programming Language book], is a C++ program."
This must be where I got it from. Sure... I misquoted him, but it's
been a while since I read it. You can't say that it's entirely false,
though!
-- http://www.kimmoa.se/
KimmoA wrote:
I have now looked it up (yes -- I just HAD to!). Instead of quoting all
you people have said, I'll just write a reply.
All "that" you people have said; a "general" reply. Sigh. I'm being too
trigger-happy with the big, red, shiny "post" button...
-- http://www.kimmoa.se/
KimmoA wrote:
Keith Thompson wrote:
>C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
That's what I meant. Sorry.
That's garbage. Yes, I know that BS has that printed in various of his
C++-pushing books, but it is a lie. When BS says "any well-written C
program" he means "any C program that obeys the style that I, BS, have
laid down and is the same as I, BS, have laid down for C++." The fact
is that his version of "well-written C program" involves many things
that are at least stylistic blunders in C. If you want to quote BS
about C++, feel free to do so in come appropriate forum, which
comp.lang.c is not, but almost everything he says about C amounts to
self-promotion and C++ advocacy. He is no authority on "well-written C".
KimmoA wrote:
I have now looked it up (yes -- I just HAD to!). Instead of quoting all
you people have said, I'll just write a reply.
In "The C++ Programming Language" (Special Edition), on the bottom of
page 13 (chapter 1, section 1.5), he (Bjarne) says:
"However, good C programs tend to be C++ programs. For example, every
program in [The C Programming Language book], is a C++ program."
This must be where I got it from. Sure... I misquoted him, but it's
been a while since I read it. You can't say that it's entirely false,
though!
Since it is entirely false, I se no reason to avoid saying so. It is
also entirely false for you to claim that we can't say that it's
entirely false. It is *not* true that "good C programs tend to be C++
programs." It is probably true that C programs that BS writes tend to
be C++ programs, but who cares?
Martin Ambuhl wrote:
Yes, but any well-written C is supposed to compile as a C++ program.
That's what I meant. Sorry.
That's garbage. Yes, I know that BS has that printed in various of his
C++-pushing books, but it is a lie. When BS says "any well-written C
program" he means "any C program that obeys the style that I, BS, have
laid down and is the same as I, BS, have laid down for C++." The fact
is that his version of "well-written C program" involves many things
that are at least stylistic blunders in C. If you want to quote BS
about C++, feel free to do so in come appropriate forum, which
comp.lang.c is not, but almost everything he says about C amounts to
self-promotion and C++ advocacy. He is no authority on "well-written C".
Hmm... "BS" sounds like something else...
Why can't I quote Bjarne about C++ here? I'm not saying that it's the
Truth, or that I even agree with it. It's just a quote. I actually got
the feeling that Bjarne in fact likes C.
-- http://www.kimmoa.se/
Keith Thompson wrote:
>
.... snip ...
>
The only exception is when you have some real requirement to write
code that will compile as either C or C++. In real life, such a
requirement is almost vanishingly rare.
Such as when you are selling cloaked C source that is likely to be
compiled by idiots who don't know how to specify a C compilation,
and you don't want to waste your time holding their quivering
little hands.
--
"I was born lazy. I am no lazier now than I was forty years
ago, but that is because I reached the limit forty years ago.
You can't go beyond possibility." -- Mark Twain
--
Posted via a free Usenet account from http://www.teranews.com
KimmoA said:
Keith Thompson wrote:
>C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
Whoever told you that doesn't know what they're talking about.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
KimmoA said:
Martin Ambuhl wrote:
>[Bjarne Stroustrup] is no authority on "well-written C".
Hmm... "BS" sounds like something else...
Why can't I quote Bjarne about C++ here?
But you did, so obviously you can. But it's not a good idea; this is
comp.lang.c, not comp.lang.c++. If you want to talk about C++, it might be
better to do so in comp.lang.c++, yes?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote:
Why can't I quote Bjarne about C++ here?
But you did, so obviously you can.
"Can't" as in... "can't"! :)
this is comp.lang.c, not comp.lang.c++. If you want to talk about C++, it might
be better to do so in comp.lang.c++, yes?
Yes, but I'm a C coder. The C++ reference(s) seemed relevant in the
discussion.
-- http://www.kimmoa.se/
KimmoA wrote:
Martin Ambuhl wrote:
>.... If you want to quote BS
about C++, feel free to do so in come appropriate forum, which
comp.lang.c is not,
Why can't I quote Bjarne about C++ here? I'm not saying that it's the
Truth, or that I even agree with it. It's just a quote. I actually got
the feeling that Bjarne in fact likes C.
Who said you can't. I certainly didn't. I wrote that comp.lang.c was
not an appropriate newsgroup for posting about some other language. We
don't give a rat's ass about C++ or about what BS has to say about it.
If you insist on posting about C++ in comp.lang.c, or about Lisp in a
COBOL newsgroup, or about Forth in a Fortran newsgroup, you can do that
too. But you are also free to join all the other off-topic toads in the
killfile.
"KimmoA" <ki****@gmail.comwrote:
Keith Thompson wrote:
C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
Then C++ has failed fundamentally, because most well-written C programs
of any reasonable complexity do not compile as C++.
Richard
"KimmoA" <ki****@gmail.comwrote:
In "The C++ Programming Language" (Special Edition), on the bottom of
page 13 (chapter 1, section 1.5), he (Bjarne) says:
"However, good C programs tend to be C++ programs. For example, every
program in [The C Programming Language book], is a C++ program."
This must be where I got it from. Sure... I misquoted him, but it's
been a while since I read it. You can't say that it's entirely false,
though!
I not only _can_ say that it's entirely false, I _do_ say that it's
entirely false, and if Bjarne really wrote that, more than a little
dishonest of him.
Richard
Richard Bos wrote:
if Bjarne really wrote that
I hope you're not suspecting that I'm making this shit up. Becuase I'm
not.
-- http://www.kimmoa.se/ rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
"KimmoA" <ki****@gmail.comwrote:
In "The C++ Programming Language" (Special Edition), on the bottom of
page 13 (chapter 1, section 1.5), he (Bjarne) says:
"However, good C programs tend to be C++ programs. For example, every
program in [The C Programming Language book], is a C++ program."
This must be where I got it from. Sure... I misquoted him, but it's
been a while since I read it. You can't say that it's entirely false,
though!
I not only _can_ say that it's entirely false, I _do_ say that it's
entirely false, and if Bjarne really wrote that, more than a little
dishonest of him.
It's also entirely possible that at the time he wrote that, it was
true -- C++ did evolve out of C, after all. It seems to me that
"dishonest" involves more intent than I think can be accurately
ascribed here.
(On the other hand, the larger point, that C and C++ are stylistically
very different, and good C and good C++ do not tend to resemble each
other, remains valid despite what Dr Stroustrup may have written.)
Charlton
Richard Bos wrote:
"KimmoA" <ki****@gmail.comwrote:
In "The C++ Programming Language" (Special Edition), on the bottom of
page 13 (chapter 1, section 1.5), he (Bjarne) says:
"However, good C programs tend to be C++ programs. For example, every
program in [The C Programming Language book], is a C++ program."
This must be where I got it from. Sure... I misquoted him, but it's
been a while since I read it. You can't say that it's entirely false,
though!
I not only _can_ say that it's entirely false, I _do_ say that it's
entirely false, and if Bjarne really wrote that, more than a little
dishonest of him.
Richard
Careful who you accuse of dishonesty. Check the acknowledgement section
of K&R2.
I have as much right to talk about C as just about anyone else. I have
the experience (incl. up-to-date experience) with C, and I have made my
contribution to C (check your history: it was major).
-- Bjarne Stroustrup; http://www.research.att.com/~bs
Charlton Wilbur wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
>"KimmoA" <ki****@gmail.comwrote:
>>In "The C++ Programming Language" (Special Edition), on the bottom of
page 13 (chapter 1, section 1.5), he (Bjarne) says:
"However, good C programs tend to be C++ programs. For example, every
program in [The C Programming Language book], is a C++ program."
This must be where I got it from. Sure... I misquoted him, but it's
been a while since I read it. You can't say that it's entirely false,
though!
I not only _can_ say that it's entirely false, I _do_ say that it's
entirely false, and if Bjarne really wrote that, more than a little
dishonest of him.
Those words are in the book, where he says they are. They do not mean
what he wants them to mean.
It's also entirely possible that at the time he wrote that, it was
true -- C++ did evolve out of C, after all. It seems to me that
"dishonest" involves more intent than I think can be accurately
ascribed here.
All the examples in K&R2 will compile in a conforming C++ compiler.
That is *NOT* the same thing as a specification that C++ is a proper
superset of C, which is the implication that Stroustrup's words are
being twisted in order to support.
Follup-To: comp.lang.c++
jmcgill wrote:
Default User wrote:
He also said, ". . . good C programs tend to be C++ programs. For
instance, every program in [K&R 2] is a C++ program."
You have an edition/page number for that?
Third Edition, chapter 1.6, pg. 13-14.
Brian
Default User wrote:
jmcgill wrote:
>Default User wrote:
>>He also said, ". . . good C programs tend to be C++ programs. For
instance, every program in [K&R 2] is a C++ program."
You have an edition/page number for that?
Third Edition, chapter 1.6, pg. 13-14.
Are you aware that Kernighan and Ritchie used Bjarne's compiler to
validate all their examples? Of *course* they work.
Stroustrup is not saying that C++ is specified to be a proper superset
of C. Did I not quote the same thing from the same book as a
counterpoint to what KimmoA was claiming? That "any well-written C
is supposed to compile as a C++ program?"
I guess it depends on whether you interpret words like 'supposed to' as
being a specification of some kind.
C can be expected to compile on a C++ toolchain if it is written in such
a way that it does compile. That's all we can really take from
Stroustrup's and K&R's references to each other, because that's little
more than a happy coincidence or a cooked-up example.
Followup-To: comp.lang.c++
jmcgill <jm*****@email.arizona.eduwrites:
Follup-To: comp.lang.c++
I'll follow-up to where I want to follow up to, thanks much.
All the examples in K&R2 will compile in a conforming C++ compiler.
That is *NOT* the same thing as a specification that C++ is a proper
superset of C, which is the implication that Stroustrup's words are
being twisted in order to support.
The larger claim is that C++ is a proper superset of *well-written* C.
Well, here's a trivial counterexample. (Not nearly so trivial as
using 'new' or 'delete' as variable names, of course, but that's
hardly playing fair.)
#include <stdlib.h>
int main (void)
{
char *s = malloc (25);
free (s);
return 0;
}
That's idiomatic C -- in particular, the *lack* of cast on the result
of malloc() is considered good style because a cast there may hide
errors. (The magic number 25 is bad style, but you knew that.) It
fails to compile in C++ because C++ does not allow implicit casts of
void pointers.
So the only way to make the assertion that "well-written C is a proper
subset of C++" true is to redefine "well-written C" to include only
things that are also valid C++.
(I don't have K&R2 close at hand, and so can't check if any of the
examples use implicit casts of void pointers. That would make a handy
refutation of Stroustrup's statement.)
Charlton rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
"KimmoA" <ki****@gmail.comwrote:
>Keith Thompson wrote:
C and C++ are two different languages.
Yes, but any well-written C is supposed to compile as a C++ program.
Then C++ has failed fundamentally, because most well-written C programs
of any reasonable complexity do not compile as C++.
The major reason for this, I think, is that casting the result of
malloc() (or calloc() or realloc()) is not required (and strongly not
recommended) in C, but necessary in C++. If it were not for that, I
think that most well-written C *would* be valid C++. (I'm ignoring
things like <stdio.hvs. <cstdio>, which were added to C++ relatively
late in its development.)
But apparently the fact that casting the result of malloc() in C is a
bad idea wasn't clearly understood in the early days of ANSI C. The
examples in K&R2 do cast the result of malloc(). And the K&R2 errata
list, <http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>, says:
142(6.5, toward the end): The remark about casting the return
value of malloc ("the proper method is to declare ... then
explicitly coerce") needs to be rewritten. The example is correct
and works, but the advice is debatable in the context of the
1988-1989 ANSI/ISO standards. It's not necessary (given that
coercion of void * to ALMOSTANYTYPE * is automatic), and possibly
harmful if malloc, or a proxy for it, fails to be declared as
returning void *. The explicit cast can cover up an unintended
error. On the other hand, pre-ANSI, the cast was necessary, and it
is in C++ also.
At the time K&R2 was written, and at the time that Mr. Stroustrup made
his statement that well-written C tends to be valid C++ (I don't have
the exact wording), it was a reasonable statement. As both languages
have evolved, along with our understanding of them, it has become
somewhat less true.
C is, as always, *nearly*, but not quite, a subset of C++. It's still
reasonably straightforward to write code that's valid in both C and
C++ (write good C code, add casts for malloc() and friends, avoid
identifiers that are keywords in C++ but not in C, and a few other
things). But there is rarely a good reason to do so.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jmcgill wrote:
Default User wrote:
jmcgill wrote:
Default User wrote:
>
He also said, ". . . good C programs tend to be C++ programs. For
instance, every program in [K&R 2] is a C++ program."
You have an edition/page number for that?
Third Edition, chapter 1.6, pg. 13-14.
Are you aware that Kernighan and Ritchie used Bjarne's compiler to
validate all their examples? Of course they work.
So? That doesn't make them C++ programs according to the ISO Standard
for that language. They aren't.
C can be expected to compile on a C++ toolchain if it is written in
such a way that it does compile.
Which the examples given weren't.
Followup-To: comp.lang.c++
No.
Brian
Charlton Wilbur said:
<snip>
>
(I don't have K&R2 close at hand, and so can't check if any of the
examples use implicit casts of void pointers. That would make a handy
refutation of Stroustrup's statement.)
"We used Bjarne Stroustrup's C++ translator extensively for local testing of
our programs, and Dave Kristol provided us with an ANSI C compiler for
final testing." - Brian W Kernighan and Dennis M Ritchie, in the preface to
K&R2.
Since the implicit conversion of void * to T * is illegal in C++, and since
K&R tested their code on a C++ compiler (heaven knows why, but there it
is), I think it unlikely that they rely on such conversions. See also the
errata for the K&R2 book, at: http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
"Default User" <de***********@yahoo.comwrites:
jmcgill wrote:
>Default User wrote:
jmcgill wrote:
Default User wrote:
He also said, ". . . good C programs tend to be C++ programs. For
instance, every program in [K&R 2] is a C++ program."
You have an edition/page number for that?
Third Edition, chapter 1.6, pg. 13-14.
Are you aware that Kernighan and Ritchie used Bjarne's compiler to
validate all their examples? Of course they work.
So? That doesn't make them C++ programs according to the ISO Standard
for that language. They aren't.
It's unlikely that they would be. K&R2 was first published in 1988;
the ISO C++ Standard wasn't published until 1998. The C++ language
changed considerably in those ten years.
>C can be expected to compile on a C++ toolchain if it is written in
such a way that it does compile.
Which the examples given weren't.
The examples in K&R2 are, as far as I know, valid C++ *as of the time
they were written*.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On 12 Sep 2006 15:19:15 -0700, in comp.lang.c , "KimmoA"
<ki****@gmail.comwrote:
>Any C++ program is per
definition (of its creator, Bjarne Stroustrup) also a C program
If you're lucky, you will now get a response from Bjarne himself,
pointing out that he never said that.
>(or was it the other way around, or vice versa?).
hmm
>Anyway... it's backwards-compatible!
Ya reckon?
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Az Tech |
last post by:
Hi people,
(Sorry for the somewhat long post).
I request some of the people on this group who have good experience
using object-orientation in the field, to please give some good ideas
for...
|
by: Michael B. |
last post by:
I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization.
Of course, I...
|
by: pamelafluente |
last post by:
Hi Guys,
I am trying to include my little script in my html report.
I have done an external JS file which contains it.
If you remember, you have helped me to detect if the asp page was
present...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
