So what Standard are we working off?

[Al Balmer]

Richard Heathfield posted:



A "fortnight" is exactly two weeks where I'm from.

Yes, but how long is the "last minute"?

 

[Al Balmer]

Oh! You were so close. You meant to say: "Of course it does". I
personally endorse the inclusion of pop-count operations in the C
standard library as well. Also bit scanning instructions. Following
the impeccable reasoning you just presented.

So, in the end, you'd have assembly language. Hasn't that already been
done?

 

[Morris Dovey]

Stephen Sprunk (in [email protected]) said:

| As far as the internals in the .c file, I wouldn't say anyone goes
| to pains to make the code into the common subset of C and C++, but
| one shouldn't go out of their way to make code uncompilable as C++
| (e.g. using new or class as identifiers). This is one reason you
| see a lot of casts in "C" code that aren't needed -- someone put
| them in so they could compile as C++ too.

The bulk of the casts I've seen in C code (for which I've been able to
ask the authors) has been to "shut the compiler up" so as to be able
to claim that the program compiled "clean".

I've horrified more than few clients by going through source modules
and removing /all/ of the casts, doing a bit of clean up, andthen
recompiling in the compiler's most twitchy mode. They're amazed to see
that the compiler was making legitimate complaints and to recognize
how (normally) trivial it is to clean the code up - and that it then
compils without warnings or errors.

I'm not out to make life difficult for C++ programmers; but neither am
I willing to allow C problems to be masked with casts. YMMV.

 

[Keith Thompson]

At a minimum, C headers should be digestible by a C++ compiler (with
extern "C" {...} wrapped around them) so that C++ programs can link
with C libraries. This greatly expands the number of people that can
use your code and costs virtually nothing.

Ok, I can see that.

As far as the internals in the .c file, I wouldn't say anyone goes to
pains to make the code into the common subset of C and C++, but one
shouldn't go out of their way to make code uncompilable as C++
(e.g. using new or class as identifiers). This is one reason you see
a lot of casts in "C" code that aren't needed -- someone put them in
so they could compile as C++ too.

I suspect a lot of casts in C code are there because the author didn't
know they were unnecessary.

I might be tempted to use new or class as an identifier deliberately.
If nothing else, it would serve as a flag to indicate that the code
has never been tested as C++, and if you feel the need to compile it
as C++ for some reason it's going to take a bit of work. And of
course *any* C code I write using malloc() will almost certainly not
be valid C++ ("almost" because I might happent to assign the result to
a void*).

 

[lawrence.jones]

But now that you mention it,
the text of C89 looks to be about the same
as the footnotes of C99.

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

-Larry Jones

Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. -- Calvin

 

[Keith Thompson]

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

Perhaps the C99 standard uses larger print because we were all 10
years older in 1999 than in 1989. }

 

[Chris Hills]

Perhaps the C99 standard uses larger print because we were all 10
years older in 1999 than in 1989. }

C09 will be in 16 point with and audio book version also available

This also explains why I have gone from a 14inch CRT screen to a 19 inch
LCD screen (effectively the same as a 21inch CRT) and only seem to have
the same amount of information on it

Never mind, I recall the programming magazines of 20 years ago
predicting that "in 20 years time" we would be speaking at the computer
and it would take spoken descriptions and turn them in to working (bug
free) programs.....

 

[Stephen Sprunk]

I suspect a lot of casts in C code are there because the author didn't
know they were unnecessary.

Perhaps I'm giving some folks more credit than they deserve, but I think
it's at worst an even split. I personally never bothered to learn C's rules
for what pointers can be assigned to what other pointers, so I just write
everything without casts and then go back and insert them where the compiler
complains. And when I submit warning-free code, I often see patches with
new casts added by other folks that only seem to make sense if they were
compiling my code as C++.

I might be tempted to use new or class as an identifier deliberately.
If nothing else, it would serve as a flag to indicate that the code
has never been tested as C++, and if you feel the need to compile it
as C++ for some reason it's going to take a bit of work. And of
course *any* C code I write using malloc() will almost certainly not
be valid C++ ("almost" because I might happent to assign the result to
a void*).

Other than the need for more casts, I fail to see why code using malloc()
would be less viable under C++. malloc() et al work just fine in C++ as
long as you don't try to mix in use of new/delete or try to malloc() a class
with {con,de}structors.

S

 

[Keith Thompson]

Other than the need for more casts, I fail to see why code using
malloc() would be less viable under C++. malloc() et al work just
fine in C++ as long as you don't try to mix in use of new/delete or
try to malloc() a class with {con,de}structors.

Any code *I* write that uses malloc() will not cast the result; it
will assign it directly to the target pointer object, taking advantage
of C's implicit conversion of void* to a pointer-to-object type. It
will therefore not compile as C++.

It is, of course, possible to use malloc() in C++ -- but I don't.

 

[ena8t8si]

(e-mail address removed) writes: [...]
and 2) Non-determinable integer scalar sizes, that are not
enforced to 2s complement.

I.e., the standard can be implemented on architectures that don't use
2's complement.

Right; and there was a time where this might have made sense. It was
certainly long before 1999.

*I* as a programmer can will never ever be in a position to test the
validity of code on a non-2s complement machine. I can't realistically
buy such a machine. I can't gain access to one, and I don't personally
know of anyone who has access to such a machine. And 99.999% of all
programmers are in the same position. Cryptographers have decided they
don't know how to deal with those 0.001% and so they just push on ahead
assuming 2s complement so they can do useful things like cryptography.

There's nothing stopping you from writing pure C code that assumes a
2's-complement representation. Just add something like this:

#include <limits.h>
#if INT_MIN == -INT_MAX
#error "This code only works on two's-complement systems."
#endif

in one of your application's header files. (I can imagine the test
not working properly in some bizarre circumstances, but it seems
unlikely.)

As you say, INT_MIN == -INT_MAX can hold even on
a two's complement implementation.

 

[ena8t8si]

Yep -- C99 is 12 point body with 10 point footnotes, C89 was 10 point body
with (I think) 9 point footnotes. If I ever produce another official
copy of the standard, I'm inclined to go back to the smaller type.

If you're taking votes, my vote is to keep the C99 fonts.
A 10 point font is too small for any extended reading
(at least for anyone with eyes past a certain age).

The formatting and layout choices in C99 were quite good.

 

[Al Balmer]

If you're taking votes, my vote is to keep the C99 fonts.
A 10 point font is too small for any extended reading
(at least for anyone with eyes past a certain age).

The formatting and layout choices in C99 were quite good.

Your contributions are welcome, but it may not be obvious, since
you're posting from Google Groups, that the messages you're replying
to are old - only a week for this one, but a month for the other I
just read.

No big deal - just a heads up.

 

[ena8t8si]

Your contributions are welcome, but it may not be obvious, since
you're posting from Google Groups, that the messages you're replying
to are old - only a week for this one, but a month for the other I
just read.

THEY ARE? Darn it, that means I'm going to
have to take the time machine into the shop
again.