Urgent C Questions

[CBFalconer]

For once we agree completely! BTW Ditto for his C++ books

Migawd. Two millenia within 8 years!

 

[Al Balmer]

According to its author it was when he started.

The Preface to the first edition of "The C++ Programming Language"
says "except for minor differences." The second edition notes that
language changes have been made "to increase C compatibility." It was
never a superset.

 

[Al Balmer]

Final Note: Why is the compiler called QuickC ? I think perhaps because it
allows you to quickly type any C program
without proper headers and declaration and yet produce some answer.

QuickC was one of the earliest "all in one" programming platforms,
similar to Borland's Turbo C. It provided an IDE, "instant"
compilation and error reporting, execution, and debugging. It was
"quick" compared to the old edit, repeat(compile), link, test cycle.

 

[jameskuyper]

Richard Heathfield wrote:
....

...ish. Whenever I call malloc, for example, I am writing a C program that
is not a legal C++ program. I could make it a C++ program, but only by
damaging the C code. As written, it is not C++. And quite a few of my
programs call malloc.

You're right, the preferred way to handle calls to malloc() in C code
doesn't work in C++. However, I wouldn't prcall the changes required
to allow it to compiile in both languages "damage". The result is
legal C as well as legal C++. It's just less than ideal for C. That
just balances things: almost any use of malloc() is less than ideal
for C++.

 

[Keith Thompson]

The Preface to the first edition of "The C++ Programming Language"
says "except for minor differences." The second edition notes that
language changes have been made "to increase C compatibility." It was
never a superset.

That makes more sense. For early C++ to have been a true superset of
C, it would have had to have no additional keywords; I doubt that a C
program using "class" as an ordinary identifier was ever a valid C++
program. (I'll grant that such things are "minor differences".)

Speaking of which, it's very common to cite
sizeof('a')
as a construct that's valid in both C and C++, but with different
meanings. Another such construct is
sizeof(1 < 2)
(Relational operators yield int in C, bool in C++.) I suppose it's
less common to apply sizeof to the result of a relational operator.

 

[Charles Richmond]

If that is the H Schildt (sp?) book, you are lucky. You have now
been advised that it is useless and stuffed full of errors, because
the author doesn't understand C. See if you can get some practical
use of it as a replacement for a log in the fireplace.

Not bad as a door stop either...

 

[Walter Roberson]

That makes more sense. For early C++ to have been a true superset of
C, it would have had to have no additional keywords; I doubt that a C
program using "class" as an ordinary identifier was ever a valid C++
program. (I'll grant that such things are "minor differences".)

Bjarne Stroustrup, "The Design and Evolution of C++". Chapter 2,
"C with Classes". 2.2 Feature Overview

Since a preprocessor was used for the implementation of C with
Classes, only new features (that is, features not present in C)
had to be described and the full power of C was available to users.
Both aspects were appreciated at the time. Having C as a subset
dramatically reduced the support and documentation work needed.


So although you are right that "class" was used as a keyword
right from the beginning of what would become C++, the designer
himself has referred to C as being a "subset" of C with Classes.

 

[Randy Howard]

Richard Heathfield wrote:
...

You're right, the preferred way to handle calls to malloc() in C code
doesn't work in C++. However, I wouldn't prcall the changes required
to allow it to compiile in both languages "damage". The result is
legal C as well as legal C++. It's just less than ideal for C. That
just balances things: almost any use of malloc() is less than ideal
for C++.

How about an answer straight from Stroustrup's FAQ instead. He answers
the question, and if anyone is qualified to do so, he probably fits the
bill:

http://www.research.att.com/~bs/bs_faq.html#C-is-subset

That section of his FAQ, and the several after it call out quite a few
reasons that perhaps don't agree with the notion that C is a subset of
C++ in any meaningful way to programmers.



If that isn't sufficient, this might prove helpful as well:

http://david.tribble.com/text/cdiffs.htm

It enumerates a painfully long list of differences between ISO C and
ISO C++.

 

[Randy Howard]

Not bad as a door stop either...

I keep a copy of one of his books around with a yellow postit note
sticking out from each page with an obvious technical error on it. It
looks like a device designed to hold postit notes more than a book. I
use it whenever someone asks me if they should buy a book by Schildt.

"Here, check this representative example of his books. There is a test
on every page marked with a postit note. See if you can find the
error(s) on each."

Usually it works, and prevents me from going back and unteaching
something with them later on.

 

[Randy Howard]

QuickC was one of the earliest "all in one" programming platforms,
similar to Borland's Turbo C. It provided an IDE, "instant"
compilation and error reporting, execution, and debugging. It was
"quick" compared to the old edit, repeat(compile), link, test cycle.

I didn't realize anyone still ran it until it came up in this thread.
I bought a copy of it ages ago, I can't find the disks anymore. I
don't recall using it for more than a very brief time.

 

[Keith Thompson]

ie. it makes no sense.

But be careful. At least one major compiler (gcc) permits
sizeof(void) by default, as an extension. You won't even get a
warning about it unless you use the "-pedantic" option. More
generally, your compiler won't necessarily warn you about non-standard
constructs unless you specifically ask it to operate in conforming
mode.

[...]

and isn't "type" a C++ reserved word?

Nope. "typedef", "typeid", and "typename" are C++ keywords; "type"
isn't.

[...]

no, it isn't a macro.

In a vague way, it almost is, in the sense that it's a construct
that's transformed at compilation time into some other construct,
rather than being evaluated during execution. But C has a very
specific meaning for the word "macro", and sizeof doesn't qualify.

[...]

 

[John Bode]

Jack Klein schrieb:









I didn't write this code, but what is wrong about it?
In 'C: the complete reference' all prgs start like that.

And they're all wrong. Schildt is infamous for getting basic concepts
wrong and teaching bad habits. He's living proof that you don't need
to know what you're talking about to be considered an "expert".

The problem is that the language standard requires main() to return
int, not void. Typing main() to return void invokes undefined
behavior, which means the compiler is under no obligation to generate
correct or meaningful code. One compiler allegedly launched Rogue
when it encountered undefined behavior. In practical terms, the
calling conventions for a void function may differ significantly from
those for an int function, meaning the machine code generated will be
different. Depending on the platform, a program using void main() may
crash on exit; it may not even load at all. For most common
platforms, it may appear that there are no problems with void main(),
but appearances are not guarantees.

If you're using "C: The Complete Reference" as your primary resource,
throw it in the trash and get something better, like Kernighan &
Ritchie's "The C Programming Language".

Is x++ not the same as x=x+1?

It is, but "x = x++;" is not. Use just "x++;".

"x = x++" invokes undefined behavior, because x is being modified more
than once between sequence points.

QuickC didn't complain.

Then you need to turn up the warning level on QuickC.

lcc-win32 prints lots of warnings.
Warning test.c: 3  old-style function definition for 'main'
Warning test.c: 3  missing prototype for 'main'
Warning test.c: 3  'void main()' is a non-ANSI definition
Warning test.c: 6  missing prototype for printf
Warning test.c: 6  Missing prototype for 'printf'
0 errors, 5 warnings

What do they mean?

The first three warnings have to do with how you declared main().
Going in reverse order:

Warning test.c: 3 'void main()' is a non-ANSI definition

The language standard mandates two definitions for main():

int main(void)
int main(int argc, char **argv) /* or char *argv[] */

Note that in both cases, main() returns int. This is mandated by the
language standard, and typing main() to return anything else results
in undefined behavior. Note that an individual implementation *may*
support other definitions for main() (and in a freestanding
implementation, all bets are off), but more often than not, the two
definitions above are it.

Warning test.c: 3 missing prototype for 'main'

The 1989/1990 revision of the language (known around here as C89 or
C90) added the concept of prototypes to function declarations and
definitions. Pre-C89, function declarations only specified the
function name and return type, and function definitions specified the
number of parameters, but not their types:

/* old-style function declaration */
double foo();

/* old-style function definition */
double foo(a, b, c)
double a;
int b;
char *c;
{
/* code for foo */
}

With prototypes (or more precisely, prototype syntax), you specify the
number *and types* of the parameters in both the declaration and
definition:

/* function declaration with prototype syntax */
double foo(double a, int b, char *c);

/* function definition with prototype syntax */
double foo(double a, int b, char *c)
{
/* code for foo */
}

For functions that take no parameters, the keyword void is used as the
parameter list:

/* bar takes no arguments */
int bar(void);

This enhancement allowed compilers to do a better job of detecting
mismatches between function calls definitions and function definitions
(wrong number or types of parameters). It also handled issues with
type promotions, but that's a subject for another day.

Warning test.c: 3 old-style function definition for 'main'

I think this is just a repeat of not using prototype syntax, but Jacob
would have to confirm that.

Why are there 2 warnings on line 6?
Some of them go away with #include <stdio.h>.

stdio.h contains the declaration (in prototype syntax) for printf():

int printf(const char *fmt, ...);

If the C compiler sees a function call before it sees a prototype for
that function (either a declaration or a definition), it assumes that
the function returns int and takes an unspecified number of
parameters, *as though* it had been declared

int f();

The two warnings look redundant to me (again, Jacob would have to
clarify what's going on there), but they basically refer to the fact
that you have called a function without first providing a declaration
or a definition for it.

But where is the prototype for main()?

There's no separate declaration for main(); the prototype is in the
definition:

int main(void)
{
/* code for main */
}

Again, the term "prototype" refers to including the types of each
parameter in the parameter list for both function declarations and
definitions.

With MS QuickC and GCC it prints 6.
With lcc-win32 it prints 5.
But gcc says 'operation on x may be undefined'.
I'll have to investigate why.

You've been told the answer: x = x++; invokes undefined behavior. The
expression attempts to modify x more than once between sequence points
(that is, points in the execution of the code where all side effects
have been evaluated). Both the '=' and '++' operators have side
affects (in the expression above, modifying x). Since the behavior is
undefined, the compiler is free to do whatever it wants; there is no
correct result (or, canonically speaking, *any* result is considered
correct).

Note that a statement like "i = j++;" is well-defined, because you're
not attempting to modify the same object more than once.

I can't!
It is required for an advanced class.


I don't think that's gonna work.
He is a cousin of the principal.

Then defend yourself and get *good* C references (in addition to
Kernighan and Ritchie, there's also "C: A Reference Manual" by
Harbison & Steele, currently 5th ed.). No reference is perfect, but
those two are among the best.

 

[Mark McIntyre]

According to its author it was when he started.

I belive that Bjarne once said it was designed to be a superset. it
never actually was, at least not once it moved beyond a hobbyist project
and was published.

Things move C++ was based on C89 since then noth C and C++ have moved
in different directions.

In the beginning C++ was a superset of C otherwise they could not have
used the C++ compiler for initial testing and then a C compiler for
final testing,

I'm afraid that logic isn't logical. I can compile some C programmes
with a Pascal compiler - does that make C a superset of pascal?

 

[Ernie Wright]

The name "QuickC" was the continuation of a brand established by the
very popular QuickBASIC, which made BASIC "quick" because it was a
compiler rather than an interpreter. The original DOS QuickC used an
IDE nearly identical to QuickBASIC's, and it was quick (lightweight and
streamlined) compared to the full-blown Microsoft C.

QuickC made the transition to Windows, but survived for only one
version there. It was supplanted by the Visual IDE.

I didn't realize anyone still ran it until it came up in this thread.

I still use the QuickC for Windows 1.0 IDE as my primary editor in
Windows. The text editor in Gnome (gedit) is very similar.

- Ernie http://home.comcast.net/~erniew

 

[James Kuyper]

Randy Howard wrote:
....

How about an answer straight from Stroustrup's FAQ instead. He answers
the question, and if anyone is qualified to do so, he probably fits the
bill:

http://www.research.att.com/~bs/bs_faq.html#C-is-subset

That section of his FAQ, and the several after it call out quite a few
reasons that perhaps don't agree with the notion that C is a subset of
C++ in any meaningful way to programmers.

I interpret that section in almost exactly the opposite fashion. He ends
the section by saying "Except for a few examples such as the ones shown
above ... C++ is a superset of C.".

If that isn't sufficient, this might prove helpful as well:

http://david.tribble.com/text/cdiffs.htm

It enumerates a painfully long list of differences between ISO C and
ISO C++.

Despite the length of that list, it's no serious constraint on a C
programmer to write code that performs identically whether its compiled
in C90 or in C++98. That's because most of the listed differences matter
only in obscure circumstances, or are easily avoided.

Writing code that uses features that were new in C99 is trickier. C99
added some features that improved C++ compatibility (// comments,
digraphs, <iso646.h>, and mixing statements with declarations), but
added many other new differences. That's because the C++98 standard was
completed a year before the C99 standard. Future versions of the C++
standard will incorporate many of the features that were added to C in 1999.

 

[Randy Howard]

Randy Howard wrote:
...

I interpret that section in almost exactly the opposite fashion. He ends
the section by saying "Except for a few examples such as the ones shown
above ... C++ is a superset of C.".

I'd say he tried to put as favorable spin on it as possible, in light
of the C and C++ standards running off in divergent directions.

Despite the length of that list, it's no serious constraint on a C
programmer to write code that performs identically whether its compiled
in C90 or in C++98.

If you know both standards very well, it's possible to avoid many of
the pitfalls yes, by spending way more time and effort than it is worth
to write in some jigsaw shaped space where the two intersect cleanly,
and avoiding all the naming conflicts with differences in reserved
words and such.

I'm having difficult imagining very many good reasons to do that. If
you're that fluent in both, then you probably know what projects are
served best by C or C++ and not try to straddle them both.

Writing code that uses features that were new in C99 is trickier. C99
added some features that improved C++ compatibility (// comments,
digraphs, <iso646.h>, and mixing statements with declarations), but
added many other new differences. That's because the C++98 standard was
completed a year before the C99 standard. Future versions of the C++
standard will incorporate many of the features that were added to C in 1999.

We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.

And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway.

 

[CBFalconer]

.... snip ...

Writing code that uses features that were new in C99 is trickier.
C99 added some features that improved C++ compatibility (//
comments, digraphs, <iso646.h>, and mixing statements with
declarations), but added many other new differences. That's
because the C++98 standard was completed a year before the C99
standard. Future versions of the C++ standard will incorporate
many of the features that were added to C in 1999.

FYI <iso646.h> was added to C90 in 1995.

 

[Richard Bos]

We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.

And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway.

And if gets() has been replaced by gets_s(), you'll know they've been
0wnz0red, and by whom.

Richard

 

[Kaz Kylheku]

1. in the prg bellow what vars are stored on stack, heap, data segment?

I don't think I would want to work where you are applying, but it
sounds like you'd be a good fit.

    int i;

    void main()
    {
        int j;
        int *k = (void *)malloc(1);
    }

(I think j and k are on stack, but where is i?)

Where is i?

Unemployed, undercapitalized and desperate.

pps: Is very urgent!

Landlord says your rent is late.
He might have to litigate.
Don' worry. Be happy!

 

[Chris Hills]

We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.

There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top of
it.

What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."

ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here who
want only ISO C as described in all versions of ISO/ANSI C and K&R but
not as used in reality.

Where will the pedants here go if items are dropped from ISO C? By the
current definition of what C is from most of them it will include C99
and therefore things that are no longer legal...

And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway.

I expect It will probably get left in so as not to break a lot of
existing code.