Advanced C

[pemo]

What would expect to be covered?

Say you'd already attended a course, that had covered stuff like structs,
pointers, bitwise and logical operators, multi-demensional arrays [and the
like], *but* hadn't covered other stuff like recursion, unions, bit-fields
[and the like].

What topics would /should be covered on a course that takes students
further?

 

[Emmanuel Delahaye]

pemo a écrit :

What would expect to be covered?

Say you'd already attended a course, that had covered stuff like structs,
pointers, bitwise and logical operators, multi-demensional arrays [and the
like], *but* hadn't covered other stuff like recursion, unions, bit-fields
[and the like].

What topics would /should be covered on a course that takes students
further?

This book has been written by some of the regulars of this forum. It
desserves its weight !

http://users.powernet.co.uk/eton/unleashed/

 

[osmium]

What would expect to be covered?

Say you'd already attended a course, that had covered stuff like structs,
pointers, bitwise and logical operators, multi-demensional arrays [and
the like], *but* hadn't covered other stuff like recursion, unions,
bit-fields [and the like].

What topics would /should be covered on a course that takes students
further?

This book has been written by some of the regulars of this forum. It
desserves its weight !

http://users.powernet.co.uk/eton/unleashed/

I don't have that book but I've looked at it and it seems a pretty good
choice to me, too. Here is a link to the table of contents.

http://www.amazon.com/gp/reader/067...7412145?_encoding=UTF8&p=S008&j=0#reader-page

-- Osmium

 

[Eric Sosman]

What would expect to be covered?

Say you'd already attended a course, that had covered stuff like structs,
pointers, bitwise and logical operators, multi-demensional arrays [and the
like], *but* hadn't covered other stuff like recursion, unions, bit-fields
[and the like].

What topics would /should be covered on a course that takes students
further?

(Does a multi-demensional array suffer from both
schizophrenia and Alzheimer's?)

There's a qualitative difference among the examples
you mention: unions and bit-fields are C language constructs,
while recursion is a general programming technique. Decide
what you're looking for: a course in advanced C, or a course
in programming topics some of which are expressed in C. Are
you trying to learn the tool or its application?

It's hard for me to imagine a responsibly-taught course
that omitted unions and bit-fields. Even a very short course
of half a dozen lectures should at least mention them, even
if it didn't spend time on them. But the follow-on course
to "Baby Steps in C" wouldn't be characterized as "advanced,"
would it?

Just knowing a tool doesn't make you proficient in its
use. You may know that one part of the hammer is for driving
nails and another for pulling them back out again, but without
practice you'll find that one part of the hammer is for mashing
your thumb and the other for gouging out your eye. A course
in advanced hammerology won't help; what you need is experience
in using the tool. Look for a course that isn't "about" C,
but that assumes you know C and encourages you to apply it.

 

[pemo]

What would expect to be covered?

Say you'd already attended a course, that had covered stuff like structs,
pointers, bitwise and logical operators, multi-demensional arrays [and
the like], *but* hadn't covered other stuff like recursion, unions,
bit-fields [and the like].

What topics would /should be covered on a course that takes students
further?

(Does a multi-demensional array suffer from both
schizophrenia and Alzheimer's?)

Must invest in spelling checker!

There's a qualitative difference among the examples
you mention: unions and bit-fields are C language constructs,
while recursion is a general programming technique. Decide
what you're looking for: a course in advanced C, or a course
in programming topics some of which are expressed in C. Are
you trying to learn the tool or its application?

It's not so much as what I'm looking for, as I have to put this course
together.

Of course, I realise that recursion is a general programming technique
(having used Haskell for many years, I find looping any other way a bit
weird), and I included it here purely as it's something that *some* people
have a great deal of trouble getting to grips with - as some do unions and
things like bit-fields.

It's hard for me to imagine a responsibly-taught course
that omitted unions and bit-fields. Even a very short course
of half a dozen lectures should at least mention them, even
if it didn't spend time on them. But the follow-on course
to "Baby Steps in C" wouldn't be characterized as "advanced,"
would it?

That's interesting, as I've just taught two C courses (for a total of seven
weeks (7 * 3 hour sessions)) [4 weeks on an intro, 3 on a 'further' course],
and I haven't introduced unions or bit-fields yet. However, I'm now
putting together two three hour sessions on some more topics - and thus the
question as to what to include on this.

Off the top of my head, here are some other things that are on my general
candidate list [knowing the audience (mostly Oxford grad students)] - some
to do with general programming things, others to do more with C ...

function pointers and signal() etc.

defensive programming techniques.

mixing in assembler with C.

writing modular code, using your own header files effectively.

data-structures - like linked-lists, trees and graphs.

keywords like _Bool, restrict, register, ...

more on manipulating strings (strtok(), etc).

interacting with the operating system.

debugging using gdb etc.

source control.

lint.

using thrid party libraries [for stats].

btw, I'd be happy to provide *some* folks with a pdf of the courses I've
already put-together/taught - in return for their opinion on their
quality/correctness. If you're interested, please email me - peet[padding]m
at cslab.com. But, you have to be kind!

 

[Daniel Fischer]

pemo!

Of course, I realise that recursion is a general programming technique
(having used Haskell for many years, I find looping any other way a bit
weird)

Some C compilers are capable of optimizing tail recursion. Teach your
students how to write loops in C, using recursion that will be optimized
away to loops.

function pointers and signal() etc.

Function pointers and they don't even know about union yet? Ew.

mixing in assembler with C.

Utterly useless. Your students only need this if they already know
assembly and if they do, chances are they're capable of looking up
asm(). Besides, every C compiler they're going to use in their life will
do it differently.

writing modular code, using your own header files effectively.

Now that's probably something everybody should know about.

data-structures - like linked-lists, trees and graphs.

Are you certain they understand pointers? If they do, linked lists are
a great way to make them forget, though (sigh... I would know, having
taught C++ courses myself.)

more on manipulating strings (strtok(), etc).

Be sure to teach them how to use strtok safely, though. It has a number of
pitfalls.

debugging using gdb etc.

If they don't know about debugging yet, showing them what gdb can do is
definitely a good idea!

source control.

Different course. Source control applies to many languages.


Daniel

 

[pemo]

pemo!


Some C compilers are capable of optimizing tail recursion. Teach your
students how to write loops in C, using recursion that will be optimized
away to loops.


Function pointers and they don't even know about union yet? Ew.

...

Yeas, the omission thus far of unions has bothered me a bit, and next term
I'll probably introduce them earlier - although it'll probably mean having
to farm something out to the adv. course.

However, I've [these days] rarely encountered unions in live code, or in
finding I'm using a library that requires them etc. So, are unions
something that ppl. find they deal with as commonly as, say, structs?

 

[Daniel Fischer]

pemo!

However, I've [these days] rarely encountered unions in live code, or in
finding I'm using a library that requires them etc. So, are unions
something that ppl. find they deal with as commonly as, say, structs?

I guess not, but they're a concept much easier to grasp than function
pointers


Daniel

 

[Michael Mair]

What would expect to be covered?

Say you'd already attended a course, that had covered stuff like structs,
pointers, bitwise and logical operators, multi-demensional arrays [and the
like], *but* hadn't covered other stuff like recursion, unions, bit-fields
[and the like].

What topics would /should be covered on a course that takes students
further?

Depends on what the students should be able to do after the
course. Here is a (roughly translated) table of contents for a
course I taught last year; <snip> indicates left-out parts.
Note that the topics are not necessarily mentioned the first time
when they appear in the ToC:

,----
0 Intro

I The Language
1 Program structure and functions
1.1 Hello, world
1.2 Comments, possible sources of errors
2 Control flow
<snip>
3 Preprocessor and Compiler
3.1 Preprocessor
3.1.1 Macros
3.1.2 #include
.....<snip>
3.2 Compiler
3.3 Modularisation
4 Data types
<snip>
5 Operators
6 Function
6.1 Basic stuff
6.2 main
6.3 inline functions
6.4 variable argument lists
6.5 Arrays in the parameter list
6.6 Recursion
6.7 Modules and Libraries

II Kür
7 File I/O
<snip>
8 Tools
8.1 gcc
8.2 make
8.3 lint/splint
8.4 ar
8.5 cvs
8.6 gdb and ddd
8.7 electric fence
8.8 prof/gprof
8.9 Editor
8.10 Overview
9 Optimisation
<snip>

Appendices
A Intro: Using the shell
<snip>
B Joining together Matlab and C
C Formatted I/O
<snip>
D Standard library functions
Glossary
Literature
`----

I had 12*1.5h courses plus 11*2h attended exercises (this does
not mean that they did not spend another 3h per week on the
exercises, though;-).
About 2/3 of this time focused on C89 and C99 and the other third
went into tools and optimisation (basic<->algorithmic).
If I had to teach the course again, I would stress modularisation
even more (I mentioned it essentially thrice but people did not
take to structuring their solutions without some force :-( ).


Cheers
Michael

 

[Malcolm]

It's not so much as what I'm looking for, as I have to put this course
together.

Of course, I realise that recursion is a general programming technique
(having used Haskell for many years, I find looping any other way a bit
weird), and I included it here purely as it's something that *some* people
have a great deal of trouble getting to grips with - as some do unions and
things like bit-fields.

If the students need a course to learn C then they will also be newbies to
programming. So it makes sense to teach basic algorithms at the same time as
the language, and not worry too much about the difference. (Just as school
history is both about a specific period and about the difference between
primary and secondary evidence).

It's hard for me to imagine a responsibly-taught course
that omitted unions and bit-fields. Even a very short course
of half a dozen lectures should at least mention them, even
if it didn't spend time on them. But the follow-on course
to "Baby Steps in C" wouldn't be characterized as "advanced,"
would it?

That's interesting, as I've just taught two C courses (for a total of
seven weeks (7 * 3 hour sessions)) [4 weeks on an intro, 3 on a 'further'
course], and I haven't introduced unions or bit-fields yet. However, I'm
now putting together two three hour sessions on some more topics - and
thus the question as to what to include on this.

You should try to introduce the whole of the language as early as possible,
and encourage students to explore the quirks themselves. If you removed
unions and bitfields from C you would still have a perfectly serviceable
language, and in fact they are relatively rarely used. However students must
know about them, so that they can read arbitrary C.

Off the top of my head, here are some other things that are on my general
candidate list [knowing the audience (mostly Oxford grad students)] - some
to do with general programming things, others to do more with C ...

I did a graduate course in programming at Oxford (Snobol). I was actually an
undergrad at the time.

function pointers and signal() etc.

fair enough. signal() isn't portable.

defensive programming techniques.

The problem with this is that defensive programming easily turns into
masking errors.

mixing in assembler with C.

fair enough. Do the students know an assembly lanugage, though?

writing modular code, using your own header files effectively.

Very valuable. priority for a second course. Again, hard to teach.

data-structures - like linked-lists, trees and graphs.

Keep it to the simplest structures. Otherwise you go too far down the
general programming route.

keywords like _Bool, restrict, register, ...

make sure you teach the difference between ANSI and non-ANSI C. I think most
of these just need a brief mention, except perhaps restrict, but then you
are going from C to the pointer alias problem and general language design
issues.

more on manipulating strings (strtok(), etc).

Don't teach these. Set them as exercises (implement strlen(), strtok(), then
get more ambitious, like a reduced sprintf(), a wildcard globber, natural
language parser).

interacting with the operating system.

No. Too platform specific (except for loading and saving files, of course).

debugging using gdb etc.

Up to you. personally I hate debuggers, but that is partly because I write
code for lots of differnet targets, and so learning the debugger means
starting over each time.

source control.

Too far away from C. Also, you need a really big project before the benfits
become obvious

lint.

Hate it. Most compilers are so good with warnings now that there is no real
need.

using thrid party libraries [for stats].
Absolutely essential.

btw, I'd be happy to provide *some* folks with a pdf of the courses I've
already put-together/taught - in return for their opinion on their
quality/correctness. If you're interested, please email me -
peet[padding]m at cslab.com. But, you have to be kind!

Good luck.

 

[Malcolm]

However, I've [these days] rarely encountered unions in live code, or in
finding I'm using a library that requires them etc. So, are unions
something that ppl. find they deal with as commonly as, say, structs?

Almost never.
The main use of a union is to define a data "packet" for some type of
messaging system. However normally you want such messages passed over a
wire, so they need to be serialised, and unions are not a portable way of
doing that. So instead you specify the messge format byte byte byte, and
then unpack.

 

[Eric Sosman]

[...]

Off the top of my head, here are some other things that are on my general
candidate list [knowing the audience (mostly Oxford grad students)] - some
to do with general programming things, others to do more with C ...

function pointers and signal() etc.

defensive programming techniques.

mixing in assembler with C.

writing modular code, using your own header files effectively.

data-structures - like linked-lists, trees and graphs.

keywords like _Bool, restrict, register, ...

more on manipulating strings (strtok(), etc).

interacting with the operating system.

debugging using gdb etc.

source control.

lint.

using thrid party libraries [for stats].

Of these, the only unequivocally "about C" items are
the first and sixth, with a possible nod to the seventh.
The other nine or nine and a half are not about C at all
(no, not even the third). That's not to say it couldn't
be a useful course, but "Advanced C" isn't the title I'd
give it.

 

[Marc Boyer]

It's hard for me to imagine a responsibly-taught course
that omitted unions and bit-fields. Even a very short course
of half a dozen lectures should at least mention them, even
if it didn't spend time on them.

Why ?
What is the benefit of union, except memory saving and
some advanced POO-like programming technics ?
And with bit-fields, what is the use except on some
raw I/O, where endianess, sign encoding, bit padding and
memory alignements are also needed ?

Marc Boyer

 

[Ingo Menger]

Why ?
What is the benefit of union, except memory saving and
some advanced POO-like programming technics ?

They are almost indespensable for implementing sum data types (as
opposed to product data types which are often implemented using
structs).
For example:

enum literalkind { Float, Int, Char };
struct literal {
enum literalkind kind;
union {
float u_flt;
int u_int;
char u_chr;
} l_val;
};

 

[Marc Boyer]

They are almost indespensable for implementing sum data types (as
opposed to product data types which are often implemented using
structs).
For example:

enum literalkind { Float, Int, Char };
struct literal {
enum literalkind kind;
union {
float u_flt;
int u_int;
char u_chr;
} l_val;
};

Yes, but how often are 'sum data types' usefull ?
I am in the context of 'a very short course'.
My opinion (can be discussed) is that, in real life,
when unions are needed, then so many others also are that
this is no more for beginners.

Marc Boyer

 

[Eric Sosman]

Why ?
What is the benefit of union, except memory saving and
some advanced POO-like programming technics ?
And with bit-fields, what is the use except on some
raw I/O, where endianess, sign encoding, bit padding and
memory alignements are also needed ?

IMHO, a responsibly-taught C course would cover gets().
I do not advocate using gets(), but if the neophyte programmer
has never been taught to recognize it and warned against it,
he has not been prepared against a serious peril.

Similarly with unions: Their legitimate uses are few,
but their hackish uses are frequent. The programmer will
certainly encounter unions, and will have been ill-prepared
if the course never mentioned them.

Let me turn the question around: If you were preparing
a course on C, what features would you omit altogether?
Would you omit `do...while'? It's infrequently used, after
all. How about `goto'? It's even rarer, yet your students
will eventually run into it. `longjmp'? I hope you'd at
least mention that it exists, perhaps with a caution that
it's tricky to use well. `long double'? `<stdarg.h>'?
`continue'?

I'm not saying that an introductory course should cover
all such matters in great detail. More attention should be
paid to mundane matters, like how `switch' works or why it's
a bad idea to return a pointer to an `auto' variable. But
even an introductory course ought to erect a few signposts
to describe the unexplored territory, so the graduate will not
be utterly lost when he parachutes into it.

 

[Marc Boyer]

IMHO, a responsibly-taught C course would cover gets().
I do not advocate using gets(), but if the neophyte programmer
has never been taught to recognize it and warned against it,
he has not been prepared against a serious peril.

Why presenting gets() if fgets() is presented ?
man gets

Similarly with unions: Their legitimate uses are few,
but their hackish uses are frequent. The programmer will
certainly encounter unions, and will have been ill-prepared
if the course never mentioned them.

Yes, but in a limited teaching time, must we spend time
to describe hacks or good practices ?

Let me turn the question around: If you were preparing
a course on C, what features would you omit altogether?

I am teaching C.

Would you omit `do...while'? It's infrequently used, after
all.

Yes, but this is a 0-overhead since the notion have been
presented with Pascal.

How about `goto'? It's even rarer, yet your students
will eventually run into it.

Not presented.

`longjmp'? I hope you'd at
least mention that it exists, perhaps with a caution that
it's tricky to use well.

Neither.

`long double'?

Yes, also a 0 overhead notion (float, double, long-double).

`<stdarg.h>'?, `continue'?

No

I'm not saying that an introductory course should cover
all such matters in great detail. More attention should be
paid to mundane matters, like how `switch' works or why it's
a bad idea to return a pointer to an `auto' variable. But
even an introductory course ought to erect a few signposts
to describe the unexplored territory, so the graduate will not
be utterly lost when he parachutes into it.

My choice is (but can be discussed) is that there is a
lot of C documentation (and some is given), and I prefer to
takes time on usefull and hard notions, and rely on the
adaptation capacity of the students for the others.
With any C documentation with an index, you can understand
what 'continue' does. With sizeof, malloc and others,
this is not the case.

Marc Boyer

 

[pemo]

IMHO, a responsibly-taught C course would cover gets().
I do not advocate using gets(), but if the neophyte programmer
has never been taught to recognize it and warned against it,
he has not been prepared against a serious peril.

Similarly with unions: Their legitimate uses are few,
but their hackish uses are frequent. The programmer will
certainly encounter unions, and will have been ill-prepared
if the course never mentioned them.

Let me turn the question around: If you were preparing
a course on C, what features would you omit altogether?
Would you omit `do...while'? It's infrequently used, after
all. How about `goto'? It's even rarer, yet your students
will eventually run into it. `longjmp'? I hope you'd at
least mention that it exists, perhaps with a caution that
it's tricky to use well. `long double'? `<stdarg.h>'?
`continue'?

I'm not saying that an introductory course should cover
all such matters in great detail. More attention should be
paid to mundane matters, like how `switch' works or why it's
a bad idea to return a pointer to an `auto' variable. But
even an introductory course ought to erect a few signposts
to describe the unexplored territory, so the graduate will not
be utterly lost when he parachutes into it.

Good points from everyone - thanks for the input/effort so far.

FYI, I have included gets(), buffer-overruns, fgets(), do ... while and
goto! However, I'm sure that I ought to have included some things that I've
recently realised are missing, e.g., I haven't mentioned enums yet, or
returning the address of a frame variable (or unions, bit-fields ...)!

However, it's hard to get *everything in* that perhaps ought to be - esp.
true if you yourself don't frequently use some features. E.g., I rarely use
enums/unions or *goto* etc BTW, the goto appeared [as an aside] when we
were looking at loops.

The difficulty in the development of this course has been slightly
compounded by the fact that I originally 'inherited' it. I've spent two
terms re-doing many parts of it (as well as doing my own research stuff),
but it's very far from perfect. Even further hampered by the fact that my
serious usage of C predates the latest stuff, esp. c99 - c.l.c has been
invaluable here!

Lastly, if every student took both courses, they'd have 21 hours of
tutorials and practicals - it's rather hard [frightening] to think that
they'll be let loose on department code after such a short time: so, it's
even more important to only include useful stuff (maybe goto should go!!)

 

[Ingo Menger]

Yes, but how often are 'sum data types' usefull ?

Hmmm...
I'd say, before I learned the concept through Haskell (where they are
known as algebraic data types), I didn't use them at all. Nowadays I
find myself cursing the dumb and stupid language I have to work with,
and that doesn't have them, such as for example java.

It's quite comparable to class types and object oriented programming.
How often were objects useful in the seventies and eighties? But today,
everything ought to be an object.

My opinion (can be discussed) is that, in real life,
when unions are needed, then so many others also are that
this is no more for beginners.

Sure, but the topic is "Advanced C".
And certainly, unions deserve much more attention than, for example
bitfields. Whereas the former is an concept that supports advanced
(altough rarely known) programming paradigms, the latter is just
another way of storing a bunch of unsigned numbers using less space.

 

[Marc Boyer]

Hmmm...
I'd say, before I learned the concept through Haskell (where they are
known as algebraic data types), I didn't use them at all. Nowadays I
find myself cursing the dumb and stupid language I have to work with,
and that doesn't have them, such as for example java.

OK, but can't you do the same with dynamic polymorphism ?

And, since we are on clc, which use in C ?

Sure, but the topic is "Advanced C".

I could have changed the subject, but I was answering
a post on 'Even a very short course [...] should at least
mention them'.

And certainly, unions deserve much more attention than, for example
bitfields. Whereas the former is an concept that supports advanced
(altough rarely known) programming paradigms, the latter is just
another way of storing a bunch of unsigned numbers using less space.

Yes

Marc Boyer