Advanced C

[Ben Pfaff]

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

Bit-fields have the same type as another C language type, such as
signed int or unsigned int. I don't see how they would help with
24-bit signed arithmetic, at least without involving undefined
behavior.

 

[Eric Sosman]

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

See the documentation for knife() and spoon(). For
international localized implementations, see chopsticks().
For early pre-Standard prehistoric systems, use "man finger",
or even "ape finger" if you're willing to risk the opprobrium
of the Intelligently Designed.

;-)

 

[Eric Sosman]

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

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

Right-ho, two categories: integral and floating
point. And complex. And -- I'll come in again. There
are three categories of numeric types in C: integral,
floating-point, and complex. "What about _Bool?" Wait,
I'll come in again. Amongst the various categories of
numeric types in C are such diverse elements as ...
Aw, the heck with it. Fetch ... the comfy `char'!

Getting back to the original topic, I now feel I was
hasty to imply that an incomplete course was irresponsible.
It all comes back to the course objectives, that is, to the
promise made to the student: "Pay attention, do your work
diligently, and you will equip yourself to do _____." There
are many ways to fill in _____, and I unconsciously presupposed
one of them: "competent (albeit inexperienced) C programming."
Other course objectives can be perfectly valid, and cheat
nobody if properly advertised.

Still, a course title like "Advanced C" raises hackles.
If the original course was a thorough introduction to C, I
don't see what's left for the "advanced" course: the focus
will be elsewhere (algorithms, data structures, software
engineering, numerical methods, ...) even if the programming
tasks are carried out in C. And if the original course was
intentionally (and overtly) incomplete, the follow-up ought
not to flaunt an adjective like "advanced." "Remedial" might
be a better match, but its pejorative implications probably
obviate its employment. Harrumpgh.

 

[Marc Boyer]

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

There are no lists but you can easely write code in C to
get lists. Garbage collector is another problem.

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.

I am not fluent enought in English to make a answer without flamming.

Marc Boyer

 

[rainbve]

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

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>

What are the subjects in 8.4 and 8.7?

 

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

This thread has diverged and strayed a little - and, while there's nothing
wrong with that, I thought I'd try and bring it back on course a little.



So far it seems that including unions, enums, modular programming and
bitfields sounds good, and putting in anything that's not *directly* to do
with the language is not recommended [although modular programming isn't
restricted to C of course]?



Additionally, it also seems then that I should also cover the remaining
keywords:



register, _Bool, _Complex, _Imaginary, extern, restrict, static [all uses],
inline, volatile,



And possibly:



Varargs

Recursion

Function pointers



Although these are again not restricted to C, students are bound to come up
against code that uses them.



Would anyone care to sugest any 'practicals' on any of these at all?

 

[Ingo Menger]

There are no lists but you can easely write code in C to
get lists. Garbage collector is another problem.

Sure, but
a) it can be done.
b) better yet, it has been done already. There are fairly good garbage
collectors out there.

I am not fluent enought in English to make a answer without flamming.

Sorry for embarassing you. I just wondered what kind of "beginners" you
have in mind. Do they really need to learn just C, or are they
non-programmers at all? This is a fundamental question, because, as I
already wrote elsewhere, you don't want to waste time to tell a PASCAL
programmer with 20 years of experience what a while loop is. You just
tell him, that BEGIN is written { and END } in C and that the while
condition is always enclosed in (). With nonprogrammers, it's
different. They ought to learn first why such a construct is useful in
the first place.

 

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

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

Right-ho, two categories: integral and floating
point. And complex. And -- I'll come in again. There
are three categories of numeric types in C: integral,
floating-point, and complex.

Then, perhaps, you want to leave out whole categories. But when
introduced once, it doesn't hurt to mention the instances, for example,
float, double and long double. I can't see why one wanted to keep the
existence of "long double" a secret once floating point is introduced.

 

[Marc Boyer]

Sure, but
a) it can be done.

To my knowledge, it can't inside the C langage.

b) better yet, it has been done already. There are fairly good garbage
collectors out there.

But this is no more C, but a C-like langage.

Sorry for embarassing you. I just wondered what kind of "beginners" you
have in mind.

I was thinking about real beginners, ie students in their first
year of programming.

This is a fundamental question, because, as I
already wrote elsewhere, you don't want to waste time to tell a PASCAL
programmer with 20 years of experience what a while loop is. You just
tell him, that BEGIN is written { and END } in C and that the while
condition is always enclosed in ().

Of course.

With nonprogrammers, it's
different. They ought to learn first why such a construct is useful in
the first place.

Yes.

Marc Boyer

 

[Ingo Menger]

To my knowledge, it can't inside the C langage.

You mean, you can write operating systems in C, but no garbage
collectors?

But this is no more C, but a C-like langage.

C'est ne pas vrai.

 

[Marc Boyer]

You mean, you can write operating systems in C, but no garbage
collectors?

Of course you can. In fact, you can write in C a Java compiler and
JVM, a lisp interpretor and so on.
But a Java/Lisp program is not a C program.

Marc Boyer

 

[Ingo Menger]

Le 29-11-2005, Ingo Menger <[email protected]> a écrit :

Of course you can. In fact, you can write in C a Java compiler and
JVM, a lisp interpretor and so on.
But a Java/Lisp program is not a C program.

Certainly true, but that's not what I mean. You might want to look at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
for instance. It's a garbage collector for C and C++.

 

[Marc Boyer]

Certainly true, but that's not what I mean. You might want to look at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
for instance. It's a garbage collector for C and C++.

Yes, but is a C program a program that runs on platforms
with a C compiler or with a C compiler and a GC support ?

Marc Boyer

 

[Imre Palik]

Hmmm, that will not work portably, though: The guarantees for
the usefulness of signed integer bit-fields are not very strong.

Do you think it is not enough?

8 A bit-field shall have a type that is a qualified or unqualified
version of _Bool, signed int, or unsigned int. A bit-field is
interpreted as a signed or unsigned integer type consisting of the
specified number of bits.93) If the value 0 or 1 is stored into a
nonzerowidth bit-field of type _Bool, the value of the bit-field
shall compare equal to the value stored.

Apart from that, "unexpected" integer promotions may make life
difficult.

Could you explain this?

Thx

ImRe

 

[Ingo Menger]

Yes, but is a C program a program that runs on platforms
with a C compiler or with a C compiler and a GC support ?

The GC is a library (written in C) that is linked to your C/C++
program and replaces the standard library malloc/free functions. Under
certain circumstances it is even possible to re-link an already
compiled program so that it'll use the malloc/realloc/free routines
supplied by the GC library.

 

[Ben Pfaff]

Certainly true, but that's not what I mean. You might want to look at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
for instance. It's a garbage collector for C and C++.

But not all C programs will work properly with this garbage
collector. For example, a C program is allowed to write a
pointer to a disk file and later read it back. In the meantime,
the Boehm GC may, incorrectly, garbage collect the block that the
pointer references.

 

[Ingo Menger]

But not all C programs will work properly with this garbage
collector.

Sure. I know that. I read articles before I point to them. I never said
that a particular GC was good or even advisable for all C programs.
Anyway, this subtopic was initiated by the remark, that programming
functional style in C was not advisable, because "there is no GC". And
in this context, it should be clear that functional programming style
does not mean writing pointer data to disk. So, we have the following
facts:
a) there is at least one GC in and for C
b) It's well suited for programs in functional style, actually, it is
utilized by C code emitted from compilers for functional languages

I draw the conclusion that

c) Therefore, the lack of a GC may not be the reason not to prgram more
functional in C.

 

[Flash Gordon]

The GC is a library (written in C) that is linked to your C/C++
program and replaces the standard library malloc/free functions. Under
certain circumstances it is even possible to re-link an already
compiled program so that it'll use the malloc/realloc/free routines
supplied by the GC library.

I'm pretty sure that the files with an extension of .s are *not* C or
C++, and since there is no portable way to scan the stack, the code
talking about scanning the stack for pointers must be non-portable (i.e.
not standard C), and this is evidenced by the existence of hacks in the
code for systems which are sloppy with their stack frames.

So no, a garbage collector cannot be written in standard C except as
part of writing a complete virtual machine where you (the author)
obviously have complete control over the memory handling of the virtual
machine (e.g. if you are writing a JVM).

 

[Ingo Menger]

I'm pretty sure that the files with an extension of .s are *not* C or
C++, and since there is no portable way to scan the stack, the code
talking about scanning the stack for pointers must be non-portable (i.e.
not standard C), and this is evidenced by the existence of hacks in the
code for systems which are sloppy with their stack frames.

It is also announced on the very first introductionary web page, that
it is not portable, and cannot possibly be.
So what?

So no, a garbage collector cannot be written in standard C

So what? Most likely, the part of the OS that implements the virtual
memory is also not written in "standard C". Nevertheless, when we speak
of UNIX, we use to say that it's written in C, likewise, some of us are
proud to point out that C is a language best suited for writing
operating systems. By your standards, both statements are plain false.
Neither is UNIX written in C, let alone standard C, nor is standard C
any better suited for writing OSses as, say COBOL. Did you want to say
that?

 

[Flash Gordon]

It is also announced on the very first introductionary web page, that
it is not portable, and cannot possibly be.
So what?

You said written in C, it isn't it written in C + other things.

So what? Most likely, the part of the OS that implements the virtual
memory is also not written in "standard C". Nevertheless, when we speak
of UNIX, we use to say that it's written in C, likewise, some of us are

You might, I would say it is mostly written in C since I recognise that
it is not written in C in its entirety.

proud to point out that C is a language best suited for writing
operating systems. By your standards, both statements are plain false.
Neither is UNIX written in C, let alone standard C, nor is standard C
any better suited for writing OSses as, say COBOL. Did you want to say
that?

I've not done Cobol, so I can't comment on that, but I do know of a
number of systems written mostly in an extended Pascal (embedded
systems, including as much of an OS as the systems in question had). The
products were successful (being sold to *new* customers 15 years after
the first one off the production line) so the choice can't have been
that bad. Of course, it was not standard Pascal, since you can't write
ISRs in standard Pascal, but the same applies to C.

If think vous think this sentence ist written en English you are wrong,
it is written in a mix of English, Spanish and German, and not all
English speakers would understand all the words in it.

C is a good language for writing a lot of the OS, but not for all of it.
Some requires assembler, some can be done with extensions to C, but
neither assembler not those extensions are actually part of C. If you
think they are, then point them out in a normative section of the standard.