Advanced C

[Ingo Menger]

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'?

Yes. (Omit)

It's infrequently used, after
all.

And rightly so. Most of the time, it is used by people that did not yet
grasp the concept of zero. For example, you find the "do while" in the
else branch of an if, that tests if there are no elements in a list, or
even worse, the "nothing to do" condition is not anticipated at all.

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

I wouldn't omit it, but just mention it and why we don't use it.

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

I would not mention it at all. Is longjmp() part of the language C? Is
longjmp() available everywhere?

`long double'? `<stdarg.h>'?
`continue'?

Sure.
What's the difficulty with long double?
A course has to introduce numeric data types, which fall into 2
categories: integral types and floating point types. Once those
concepts are understood, it's just a minute to state that in C we have
3 instances of floating point datatypes: float, double and long double,
the difference between them to elaborate left as homework.
(Alternatively, it's also possible to leave out floating point
entirely, as beginners are not supposed to do number crunching anyway.)

 

[Gordon Burditt]

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.

I'll agree, since this warning also covers having the neophyte
writing his own functions that need but do not include the
buffer length as a parameter.

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.

There are plenty of things that a neophyte programmer will
run into that are best not mentioned in a short beginning
course on C: fork(), vfprintf(), assembly-language code, C++
constructs, goto, sockets, opening windows, SPAM filtering,
and virus-writing.

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.

No. It's not that much different from while and I think the contrast
makes it easier to understand both.

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

"will eventually run into it" is a poor criteria for including
something in a *beginning* course. Especially when using it is
also viewed as a poor programming practice.

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

I'd omit it.

`long double'?

Omit, and I might consider including only brief mention of 'float'
also.

`<stdarg.h>'?
Omit.

`continue'?

I think that's useful enough to include.

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.

Brief mention of everything leaves very little time to do anything
in detail, like actually compiling and running a "hello, world"
program, or nested for loops.

Gordon L. Burditt

 

[Ben Pfaff]

I would not mention it at all. Is longjmp() part of the language C? Is
longjmp() available everywhere?

Perhaps part of your difficulty in choosing C language elements
for your course is that you do not know what is part of C.
longjmp() is part of standard C since the earliest published
standard.

 

[Jirka Klaue]

Ingo Menger:

Is longjmp() part of the language C?
Yes.

Is longjmp() available everywhere?

No, just in C.

Jirka

 

[Ingo Menger]

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

Not really. Well, maybe with a pompous class hierarchy, where the base
class has just the field that tells which variant is being used.

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

It hasn't to do with the language. Algebraic datatypes provide another
way of thinking about the problem at hand and may lead to efficient and
less error prone programs (this is at least true if the compiler can
check that you handeled all cases, as is the case in Haskell).

 

[John Smith]

There are plenty of things that a neophyte programmer will
run into that are best not mentioned in a short beginning
course on C: fork()

fork()?? Can't find it in Harbison & Steele. Sounds interesting.
Where can I get more info?

JS

, vfprintf(), assembly-language code, C++

 

[Marc Boyer]

Not really. Well, maybe with a pompous class hierarchy, where the base
class has just the field that tells which variant is being used.

This kind of thing: either the compiler adds code to dynamicaly
get the real type (instanceof in Java, typeid in C++), or an
function getType implemented in each child.

It hasn't to do with the language. Algebraic datatypes provide another
way of thinking about the problem at hand and may lead to efficient and
less error prone programs (this is at least true if the compiler can
check that you handeled all cases, as is the case in Haskell).

Yes, but we are on clc: each langage has its own programming
paradigms. Is product data type usefull in C for beginners ?

Marc Boyer

 

[Ingo Menger]

Perhaps part of your difficulty in choosing C language elements
for your course is that you do not know what is part of C.

I do not have such difficulties.

longjmp() is part of standard C since the earliest published
standard.

Frankly, I didn't know that. I remember that back in the eighties, I
ported a utility from the UNIX V7 sources to a UNIX simulation running
under some early version of MVS on an IBM mainframe and had some
trouble with longjmp() then. I had sworn that longjmp() was a UNIX
speciality. I would not use it anyway, outside fancy signal handling
code, that is.

 

[Skarmander]

fork()?? Can't find it in Harbison & Steele. Sounds interesting. Where
can I get more info?

http://www.opengroup.org/onlinepubs/009695399/functions/fork.html

Not part of C, of course. Still something a neophyte programmer might
very well run into, and indeed best not mentioned in a course on C.

S.

 

[Ingo Menger]

Yes, but we are on clc: each langage has its own programming
paradigms. Is product data type usefull in C for beginners ?

Wait.
Every language makes it easy to follow certain paradigms. Yet, if the
language is powerful enough, it should be possible to choose the
paradigm best suited for that particular piece of work. Otherwise, the
language is just plain useless or not a general purpose programming
language. But C is a general programming language, so a C course should
not only tell that there is "do while" and "printf()", but also how to
write object oriented programs in C, IMHO.
And of course, the product data type (tuple, record, struct or how it
may be called) is so fundamental that you can't possibly leave it out.

 

[Marc Boyer]

s/product/sum (sorry).

Wait.
Every language makes it easy to follow certain paradigms. Yet, if the
language is powerful enough, it should be possible to choose the
paradigm best suited for that particular piece of work. Otherwise, the
language is just plain useless or not a general purpose programming
language.

I do not agree: to me, a 'general purpose programming langage'
is devoted to all kind of applications, not for all kind of
programming paradigm.

Functionnal programming is often a bad idea in C since
there is no garbage collector.

But C is a general programming language, so a C course should
not only tell that there is "do while" and "printf()", but also how to
write object oriented programs in C, IMHO.

Object oriented programming in C in not to me a beginner task,
and then, as nothing to do in a beginner course.

And of course, the product data type (tuple, record, struct or how it
may be called) is so fundamental that you can't possibly leave it out.

I agree.

Marc Boyer

 

[Skarmander]

Marc Boyer schrieb:




Wait.
Every language makes it easy to follow certain paradigms. Yet, if the
language is powerful enough, it should be possible to choose the
paradigm best suited for that particular piece of work. Otherwise, the
language is just plain useless or not a general purpose programming
language. But C is a general programming language, so a C course should
not only tell that there is "do while" and "printf()", but also how to
write object oriented programs in C, IMHO.

And a course on carpenting introducing the hammer should explain how it
can be used to drive screws into a wall? Wouldn't it make more sense to
wait for the screwdriver?

Just because C is a general programming language does not mean it should
be made to fit any approach to programming you can think of. If that's
your idea of a "general programming language", I'd say the concept
itself is useless, not the languages that don't pass its muster.

What next? Higher-order functional programming in C? It is a general
language, after all, so you can certainly do it. You wouldn't want to,
though, and teaching it looks like a stubborn exercise in ought-to-be to me.

S.

 

[Ingo Menger]

Ingo Menger wrote:

And a course on carpenting introducing the hammer should explain how it
can be used to drive screws into a wall? Wouldn't it make more sense to
wait for the screwdriver?

This is not so easy.
A course in a programming language is always a course in programming
techniques, concepts, etc.
What sense would it make to have somebody who made a living of, say,
20 years of PASCAL programming, go to a C course? Just to explain the
syntax and some library functions? He can and will easily learn that by
reading the fine manuals, playing around a bit, looking at code others
have written and consulting newsgroups like this. It's not that C in
itself is such a complicated thing.
Likewise, for beginners in programming, it's not appropriate to tell
that there is int and long and the former must not have more bits than
the latter, but the latter may have more bits than the former. That is
too much of pointless details. Instead, you want to teach them how to
solve programming problems using this or that language, and if the
example language used is C, then it is a "C beginners course".

Just because C is a general programming language does not mean it should
be made to fit any approach to programming you can think of.

I didn't say it should. I said, it's important that I could make fit
it, if the approach in question is the right one.

What next? Higher-order functional programming in C?

Why not? But then, there is a nice preprocessor called ghc, if you want
to

It is a general
language, after all, so you can certainly do it. You wouldn't want to,
though, and teaching it looks like a stubborn exercise in ought-to-be to me.

You wouldn't want to only if you're too ignorant or lazy to learn and
apply new concepts, that may be more useful than you imagened. Bit
fiddling and number crunching is not all the world.

 

[Skarmander]

char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x1f6},*p=
b,x,i=24;for(;p+=!*p;*p/=4)switch(x=*p&3)case 0:{return 0;for(p--;i--;i--)case
2:{i++;if(1)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}

This code invokes undefined behavior by accessing b[7]. Here's a
possible fix:

char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
,i=24;for(p=b;p+=!*p;*p/=4)switch(*p&3)case 0:{return 0;for(p--;i--;i--)case 2
:{i++;if(1)break;else default:continue;if(0)case 1utchar(a[i&017]);break;}}}

S.

 

[Ingo Menger]

Ingo Menger <[email protected]> a écrit :

Functionnal programming is often a bad idea in C since
there is no garbage collector.

Sorry, but this is just plain nonsense. Consider: Functional
programming in C is often a bad idea since there are no lists.

Object oriented programming in C in not to me a beginner task,
and then, as nothing to do in a beginner course.

Depends on what a "beginner" is.
Maybe your statement is true for young people that until recently spent
their time burning cars in suburbs of Paris and elsewhere in France.
But in this cases, you might want to start with the alphabet and delay
the C beginners course a bit.

 

[Skarmander]

[..] for beginners in programming, it's not appropriate to tell
that there is int and long and the former must not have more bits than
the latter, but the latter may have more bits than the former. That is
too much of pointless details. Instead, you want to teach them how to
solve programming problems using this or that language, and if the
example language used is C, then it is a "C beginners course".

<snip>
Ah, I see. You are thinking of a course in programming using C. That's another
thing altogether.

Why not? But then, there is a nice preprocessor called ghc, if you want
to

Exactly. Teaching students functional programming using C is mildly absurd.

You wouldn't want to only if you're too ignorant or lazy to learn and
apply new concepts, that may be more useful than you imagened. Bit
fiddling and number crunching is not all the world.

Wait a minute, what are you saying here? That you *would* want to do
higher-order functional programming in C, and that everyone who uses a
functional programming language instead is "too ignorant and lazy to learn and
apply new concepts"?

As Dijkstra said, "the 'problems of the real world' are those you are left with
when you refuse to apply their effective solutions". Doing higher-order
functional programming in C is useful for those who actually want to implement
functional language compilers, but that's a long way from a course in
programming, beginners or not.

S.

 

[Ingo Menger]

Ingo Menger wrote:

Wait a minute, what are you saying here? That you *would* want to do
higher-order functional programming in C, and that everyone who uses a
functional programming language instead is "too ignorant and lazy to learn and
apply new concepts"?

You like to misunderstand deliberatly? I agree that hofp may not be the
thing to start with.
But sum types are easy. Even PASCAL had them already (called variant
records). I mention PASCAL because it was designed as an educational
language. So, every feature and concept in C that resembles some feture
or concept in PSACAL should be in the course, at least.

 

[Gordon Burditt]

There are plenty of things that a neophyte programmer will

fork()?? Can't find it in Harbison & Steele. Sounds interesting.
Where can I get more info?

How about in the POSIX spec? I didn't say fork() was part of
standard C, and it isn't. A beginning programmer will run into all
sorts of POSIX-isms, DOS-isms, UNIX-isms, and Windows-specific code.

, vfprintf(), assembly-language code, C++

And I hope you don't think that more than 2 of these are part
of standard C, either.

Gordon L. Burditt

 

[Imre Palik]

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

I thought the same way, until I had to to do some calculations with 24
bit signed integers. I wouldn't do that without bit fields ...

ImRe

 

[Michael Mair]

I thought the same way, until I had to to do some calculations with 24
bit signed integers. I wouldn't do that without bit fields ...

Hmmm, that will not work portably, though: The guarantees for
the usefulness of signed integer bit-fields are not very strong.
Apart from that, "unexpected" integer promotions may make life
difficult.

Cheers
Michael