Author |
Message |
James Keas #1 / 6
|
 Advice on Teaching C
I am teaching a course with C this fall. My C reference is the K&R Second edition. I am a C++ programmer by trade and am not current on the ISO C99 standard nor the complete differences between them. I am aware of some which I consider useful to allow in my class. I plan on compling students' assignments with: gcc -std=c99 -Wall -pedantic Any opinions on this? Anyone have an opinion about using the K&R book and basically teaching C89 but allowing C99 code? Is there anyting in C99 which would cause valid C89 code to fail with the above options? Surely not. A reference to the differences between C89 and C99 would be useful if anyone has one. Thanks James Keast -- ---------------------------------------------------------------------------
Part-time instructor Faculty of Computer Science Dalhousie University
|
Fri, 04 Feb 2005 05:21:24 GMT |
|
 |
Simon Bibe #2 / 6
|
 Advice on Teaching C
Quote:
> I am teaching a course with C this fall. My C reference is > the K&R Second edition. > I am a C++ programmer by trade and am not current on the ISO > C99 standard nor the complete differences between them. I am > aware of some which I consider useful to allow in my class. > I plan on compling students' assignments with: > gcc -std=c99 -Wall -pedantic > Any opinions on this?
I recommend you add one of the optimisation options (eg. -O2) to enable the checking for unused variables. Also be aware that even with the -std=c99 switch, not all C99 features are actually supported correctly by GCC. Quote: > Anyone have an opinion about using the K&R book and basically > teaching C89 but allowing C99 code?
The subject on C programming that I took last year at Uni basically taught C89, then in the last lecture they mentioned the existence of a new standard but didn't teach any of it. Quote: > Is there anyting in C99 which would cause valid C89 code to fail with > the above options? Surely not.
Yes, a number of things were changed in C99 which made some valid C89 code invalid. One big one is the removal of the implicit int in declarations. So, you must now write: int main() or preferably int main(void) but you can no longer leave out the "int". More minor things include the introduction of // comments which in pathological cases can cause a different program behaviour: if (1 //**/ 2 ) { puts("C99"); } else { puts("C89"); } Quote: > A reference to the differences between C89 and C99 would be useful if > anyone has one.
This is a list of major changes in the C99 standard (copied from ISO 9899:1999 Foreword, paragraph 5). restricted character set support via digraphs and <iso646.h> (originally specified in AMD1) wide character library support in <wchar.h> and <wctype.h> (originally specified in AMD1) more precise aliasing rules via effective type restricted pointers variable-length arrays flexible array members static and type qualifiers in parameter array declarators complex (and imaginary) support in <complex.h> type-generic math macros in <tgmath.h> the long long int type and library functions increased minimum translation limits additional floating-point characteristics in <float.h> remove implicit int reliable integer division universal character names (\u and \U) extended identifiers hexadecimal floating-point constants and %a and %A printf/scanf conversion specifiers compound literals designated initializers // comments extended integer types and library functions in <inttypes.h> and <stdint.h> remove implicit function declaration preprocessor arithmetic done in intmax_t/uintmax_t mixed declarations and code new block scopes for selection and iteration statements integer constant type rules integer promotion rules macros with a variable number of arguments the vscanf family of functions in <stdio.h> and <wchar.h> additional math library functions in <math.h> floating-point environment access in <fenv.h> IEC 60559 (also known as IEC 559 or IEEE arithmetic) support trailing comma allowed in enum declaration %lf conversion specifier allowed in printf inline functions the snprintf family of functions in <stdio.h> boolean type in <stdbool.h> idempotent type qualifiers empty macro arguments new struct type compatibility rules (tag compatibility) additional predefined macro names _Pragma preprocessing operator standard pragmas __func__ predefined identifier VA_COPY macro additional strftime conversion specifiers LIA compatibility annex deprecate ungetc at the beginning of a binary file remove deprecation of aliased array parameters conversion of array to pointer not limited to lvalues relaxed constraints on aggregate and union initialization relaxed restrictions on portable header names return without expression not permitted in function that returns a value (and vice versa) -- Simon.
|
Fri, 04 Feb 2005 07:36:37 GMT |
|
 |
Ian Wood #3 / 6
|
 Advice on Teaching C
Quote: > I am teaching a course with C this fall. My C reference is the > K&R Second edition.
Definately a good start, IMO! Quote: > I am a C++ programmer by trade and am not current on the ISO C99 > standard nor the complete differences between them.
For 'teaching purposes' there are very few differences. A lot of what has changed which I'm aware of are the kind of things that experienced C programmers will find handy, but not useful for beginners. Quote: > I am aware of > some which I consider useful to allow in my class. I plan on > compling students' assignments with: > gcc -std=c99 -Wall -pedantic > Any opinions on this?
You might want to be careful about the support that gcc has for c99. Last time I heard almost all the language features were supported but there was significant work done to provide the standard library. For the kinds of programs you're likely to cover, they'll work just as well as C89 programs. Quote: > Anyone have an opinion about using the K&R book and basically teaching > C89 but allowing C99 code? > Is there anyting in C99 which would cause valid C89 code to fail with > the above options? Surely not.
Implicit int is the only immediate killer I know of. In C89, functions without specified return types were 'assumed' to return int. In C99 this has been disallowed. So this: main(void) { return 0; Quote: }
isn't valid C99 code, but is valid C89 code. There are also some keywords like restrict which might cause some problems. Quote: > A reference to the differences between C89 and C99 would be useful if > anyone has one.
The last chapter of C Unleashed has a pretty good rundown. I don't know of any lurking around online but there's sure to be one somewhere! o new types - bool (stdbool.h), many new integer types (stdint.h), complex types (complex.h), long long... o variable length arrays o a whole load of new library features including type generic math (tgmath.h), support for wide characters, changes to things like printf to support the new types, some new functions like vfscanf... o expanded limits (things like the largest allocatable block of memory extended from 32768 chars to 65536 chars, or something) o changes to the character set support for national characters and wide characters o variable length 'argument lists' in function-like macros o declarations can now be mixed with code (ala C++, but the behaviour is likely to be a little different) o compound literals (so you can do things like initialise a while structure variable) o restricted pointers o 'inline' o a new meaning for the word static o implicit 'int' no longer allowed o C++/BCPL? style // comments and probably a few other things which I've skipped over. Many of these things won't effect your students, though some will. Ian Woods
|
Fri, 04 Feb 2005 07:53:52 GMT |
|
 |
Thomas Stegen CES200 #4 / 6
|
 Advice on Teaching C
Quote: > I am teaching a course with C this fall. My C reference is the > K&R Second edition.
FYI: I am a student. Think of that as you will. Quote: > I am a C++ programmer by trade and am not current on the ISO C99 > standard nor the complete differences between them.
Two remarks which you may or may not know: - Do not cast the return value of realloc, malloc, calloc or any void * when assigning. (as opposed to C++) - sizeof 'a' == sizeof(int) (as opposed to C++) This one has more implications than you can shake a stick at when it comes to C vs C++. (Maybe not that many :) Quote: > I am aware of > some which I consider useful to allow in my class. I plan on > compling students' assignments with: > gcc -std=c99 -Wall -pedantic > Any opinions on this?
I always use gcc -ansi -pedantic -W -Wall for the first compiles and never give up untill they shut up. The more the merrier. I drop them when I know they will not trigger (Like on the second compile) Quote: > Anyone have an opinion about using the K&R book and basically teaching > C89 but allowing C99 code?
The most important aspects are the same so that should not be a problem. C99 only code should perhaps be made explicit in case some students have a different compiler at home, which does not support long long for example. Quote: > Is there anyting in C99 which would cause valid C89 code to fail with > the above options? Surely not.
Not except for the new keywords like inline and restrict. Gcc is not a conforming c99 compiler even with the -std=c99 switch. Not the last time I checked anyways. Quote: > A reference to the differences between C89 and C99 would be useful if > anyone has one.
Exploring from here might yield something. http://www.lysator.liu.se/c/ Also, I found this amazing site the other day, they have everything you can possibly ask for (and probably a lot more). www.google.com ;) -- Thomas. Approaching singularity.
|
Fri, 04 Feb 2005 07:43:07 GMT |
|
 |
E. Gibbo #5 / 6
|
 Advice on Teaching C
Quote: >I am teaching a course with C this fall. My C reference is the >K&R Second edition. >I am a C++ programmer by trade and am not current on the ISO C99 >standard nor the complete differences between them. I am aware of >some which I consider useful to allow in my class. I plan on >compling students' assignments with: >gcc -std=c99 -Wall -pedantic >Any opinions on this?
gcc -ansi -pedantic-errors -W -Wall -Werror -O2 -g --Ben --
|
Sat, 05 Feb 2005 01:54:12 GMT |
|
 |
David Thompso #6 / 6
|
 Advice on Teaching C
Quote: > I am teaching a course with C this fall. My C reference is the > K&R Second edition. > I am a C++ programmer by trade and am not current on the ISO C99 > standard nor the complete differences between them. I am aware of > some which I consider useful to allow in my class. I plan on > compling students' assignments with: > gcc -std=c99 -Wall -pedantic > Any opinions on this?
I assume you mean C89 (or C95, including NA1) to C99. C to C++ is a much larger difference; the differences in the part of C++ that is "nearly C" are covered in the C++ standard, and in Stroustrup. Add -ansi to prevent the "violative" GNU extensions from being accepted silently. (Note that the "permitted" extension forms, like __attribute__ instead of attribute, are still accepted, although in my personal opinion any student who gets this right probably deserves to get away with it.) Even with recent gcc (and glibc) C99 support is not quite complete -- there's a status page at gcc.gnu.org IIRC -- but the deficiencies are mostly pretty minor and I think unlikely to be an issue for student programs, even if some students get a better-conforming C99. Note that -Wall doesn't actually enable all warnings (see the info file). You may want to add -W, although I don't recall offhand that any of the checks/warnings it adds are relevant to standard conformance, though sometimes useful in their own right. Quote: > Anyone have an opinion about using the K&R book and basically teaching > C89 but allowing C99 code?
Sounds good to me. You might want to point out, when you talk about or when students use C99-only features, that for probably the next few years they will sometimes cause portability problems, which should be considered in deciding whether to use them in any particular program. Quote: > Is there anyting in C99 which would cause valid C89 code to fail with > the above options? Surely not.
Two new keywords outside reserved namespace 'inline' and 'restrict'. Several dozen new library functions and macros, which are reserved as identifiers and macros only if you #include the relevant headers, which are mostly but not entirely new ones; and officially reserved with external linkage always, but in practice most implementations allow a user function to usurp the name of a library function as long as the library function isn't used, and if you mean to use gcc with glibc (e.g. on Linux) I believe glibc does so in all cases. Deletion of implicit int in declarations, and implicit function declarations, both of which were bad style anyway and thus you shouldn't allow. (And were illegal in C++ from the beginning, FWIW. Although K&R1 syntax function declarations and definitions were never legal in C++, but are still legal though 'obsolescent' in C99.) No longer guaranteeing that certain implementation-defined types, particularly size_t, cannot be wider than, and thus can safely be printed or otherwise handled as, unsigned long. Also (possibly) increase the type for evaluating preprocessor (#if) expressions, and change the default type of large (> signed long) constants. I doubt these will matter for student programs. Quote: > A reference to the differences between C89 and C99 would be useful if > anyone has one.
Pages xi-xiii of C99 contain a list, and you (or your institution) should probably have a copy to settle questions if necessary; if they don't, you can get an individual-use softcopy for USD18 by credit card from webstore.ansi.org (select category= or link for INCITS, or search for 9899, and be sure to get the free TC1=Technical Corrigendum as well) or www.incits.org -> Standards Store. Or you can post here at need and lots of folks will be standing by to pounce on any mistake you or your students make. (I can't decide whether that deserves a smiley or not. You choose.) -- - David.Thompson 1 now at worldnet.att.net
|
Mon, 07 Feb 2005 09:39:50 GMT |
|
|
|