«

Eric Sosman schrieb:

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

> 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

"Ingo Menger" <> writes:

> Eric Sosman schrieb:
>> `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?

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.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,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;}}}

Ingo Menger:

> Is longjmp() part of the language C?

Yes.

> Is longjmp() available everywhere?

No, just in C.

Jirka

Marc Boyer schrieb:

> Ingo Menger <> wrote:
> > Marc Boyer schrieb:
> >> Ingo Menger <> wrote:
> >> > Marc Boyer schrieb:
> >> >> Eric Sosman <> wrote:
> >> >> > 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 ?
> >> >
> >> > They are almost indespensable for implementing sum data types (as
> >> > opposed to product data types which are often implemented using
> >> > structs).
> >> 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.
>
> 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).

Gordon Burditt wrote:

> 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++
> constructs, goto, sockets, opening windows, SPAM filtering,
> and virus-writing.

Ingo Menger <> wrote:
> Marc Boyer schrieb:
>> Ingo Menger <> wrote:
>> > Marc Boyer schrieb:
>> >> Ingo Menger <> wrote:
>> >> > Marc Boyer schrieb:
>> >> >> Eric Sosman <> wrote:
>> >> >> > 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 ?
>> >> >
>> >> > They are almost indespensable for implementing sum data types (as
>> >> > opposed to product data types which are often implemented using
>> >> > structs).
>> >> 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.
>>
>> 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.

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.

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

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

Marc Boyer

Ben Pfaff schrieb:

> "Ingo Menger" <> writes:
>
> > Eric Sosman schrieb:
> >> `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?
>
> 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.

John Smith wrote:
> Gordon Burditt wrote:
>
>> 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?
>
http://www.opengroup.org/onlinepubs/...ions/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.

Marc Boyer schrieb:

> Ingo Menger <> wrote:

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