Some general questions about C and good practice

[KimmoA]

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! ^__^

 

[Spiros Bousbouras]

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 ?

 

[KimmoA]

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.

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.

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.

 

[Walter Roberson]

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

 

[Spiros Bousbouras]

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.

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.

Do you mean that it should say "high-score"?
Yes.


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.

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.

 

[KimmoA]

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?

 

[CBFalconer]

Spiros Bousbouras wrote:
.... snip ...

"_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.h> to 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.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Keith Thompson]

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.h> header 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".

 

[KimmoA]

To avoid invading the users name space. The user can #include
<stdbool.h> to 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.

 

[Keith Thompson]

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

 

[KimmoA]

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.

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

C99 has _Bool as a keyword; the new <stdbool.h> header 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!

 

[Keith Thompson]

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

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.

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

 

[KimmoA]

You are overreacting. A lot.

Well... maybe.

 

[Neil]

"_Bool" isn't that pretty. Why did they decide on this, rather than
"bool"? Or am I missing something now?

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.

 

[KimmoA]

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!

 

[J. J. Farrell]

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.

 

[Michael Wojcik]

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.

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.

 

[KimmoA]

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!

 

[Keith Thompson]

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.

 

[KimmoA]

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.