Does anybody learn C any more?

[brucehoult]

I guess you had to be there to actually like the scheme.  Of course, once DEC machines came along with more registers and more addressing schemes, you might want to throw rocks at the 1130.  But it all worked and I still use my FPGA implementation to this day.

When I got to university in 1981 the 1st year students learned Pascal or BASIC (for the business students) on a PDP 11/34 with 256 KB of RAM, two 5 MB disk packs (one for OS and software, one for home directories for several hundred students), 22 VT100 and VT52 and Visual100 terminals, and two LA120 (dot matrix) "line printers". As I recall you were allowed to use 64 KB or so of disk while you were logged on but had to reduce it to maybe 8 KB to log off. Good thing disk blocks were small. Everyone ran the same shared copies of a tiny custom CLI shell and line editor and could use something like 8 KB each for heap/stack/globals. The Pascal compiler (NBS, then later OMSI) ran one copy at a time in a batch queue, but got a whole 64 KB to romp around in. That thing was tiny but tuned to within an inch of its life and actually ran quite acceptably with compile times of just a few seconds for our tiny student programs.

There was an IBM 1130 in the corner, gathering dust.

2nd year and later students got to use the PDP 11/70 (and later a couple of VAX 11/780s) which actually had several MB of core.

And the Fortran compiler had 27 phases (passes) and the entire source and resulting executable had to fit in memory.  Intermediate files weren't used because the compiler had to work from paper tape on some of the smaller machines.

I think they told us 28, but anyway something ridiculous for what it did. The Pascal compilers we were using on the PDP-11 were single pass (or 1.5, including patching offsets for linking)

[rstofer]

I think they told us 28, but anyway something ridiculous for what it did. The Pascal compilers we were using on the PDP-11 were single pass (or 1.5, including patching offsets for linking)

Completely off topic but...

I have a couple of PiDP11/70 consoles running 2.11BSD.  These are emulations using a Raspberry Pi and simh as the simulator.  They have 4MB of RAM and run considerably faster than the real hardware.

I never used DEC machines but I bought these two specifically for Pascal, C and Fortran 77 programming.  Even though I wind up using vi as the editor (and I'll eventually make peace with that) it is just plain fun to write F77 code.

https://obsolescence.wixsite.com/obsolescence/pidp-11

Both of them also run a web server.  When I get time I'll try to create a decent home page.

So, my grandson is starting a Differential Equations class.  The first project, of course, is the repeated solution of an exponential growth problem.  How fun is that for an old Fortran programmer?  I eat that stuff for breakfast!

MATLAB is cool, Fortran under BSD on a PDP11/70 is cooler!

[legacy]

MATLAB is cool, Fortran under BSD on a PDP11/70 is cooler!

"enable-languages=c,c++,fortran" has always been the default set for gcc-{v4.1.2 ... v8.2.0} on everything regarding Gentoo/Linux 

[coppice]

MATLAB is cool, Fortran under BSD on a PDP11/70 is cooler!

Somehow Fortran isn't quite Fortran unless its on punched cards. 

[SiliconWizard]

MATLAB is cool, Fortran under BSD on a PDP11/70 is cooler!

"enable-languages=c,c++,fortran" has always been the default set for gcc-{v4.1.2 ... v8.2.0} on everything regarding Gentoo/Linux 

And on quite a few other distributions as well. Funnily enough, ADA support often comes as a separate package. Probably comes from the fact that Fortran is still used in academic circles a lot, whereas ADA is comparatively used little. (*sigh*)

My own config when I hand-build GCC is more like: "enable-languages=c,c++,ada" or even sometimes just: "enable-languages=c,ada" 

[rstofer]

MATLAB is cool, Fortran under BSD on a PDP11/70 is cooler!

Somehow Fortran isn't quite Fortran unless its on punched cards. 

In all upper case and limited to the 64 char set.  There was a time...  Control Data 6400 had a 60 bit word and could hold 10 chars in a word.  In the early years what it lacked was the 'compare move' unit and running COBOL applications was a drag because it was difficult to extract strings or even manipulate strings.  It was fast on an IBM 360 but truly grim on the 6400.  OTOH, if you want high speed calculation with good precision, the 6400 was the way to go.  A lot of the space program was done on the 6400 (and higher capability machines like the 7600).

Those were great days in computing.  Today it's all about cell phone apps and twits and snaps.  Sounds like a breakfast cereal.

[westfw]

Even though I wind up using vi as the editor

Can you still find "elle" ("Elle Looks Like Emacs")?  It'll run on an 11/70 (did it, back in the day!)

[SiliconWizard]

Damn... http://towo.net/mined/

[Jookia]

I originally learned C to make video games, but it ended up being useful still when doing low level Linux development.

[techman-001]

Damn... http://towo.net/mined/

Mined does look pretty darn capable on this FreeBSD workstation. It's in Ports.

[NorthGuy]

If you want to produce a compiled code, C is quite enough. It is certainly far from perfect, but

- it is very flexible - you can do almost everything which could've done with assembler

- it is very simple - the description of common syntax is only few pages. If you don't use heap, you typically get by even a subset of the syntax - you could've learned it just by looking at the example code (I guess many people actually do this). Sometimes the syntax subset actually used in the project is so small that it doesn't even provide any advantages over assembler except portability.

- it is very widespread. Practically any platform supports C.

Therefore, when it comes to producing compiled code, I don't think there's a need for anything else except C. I don't consider any advantages of other languages to be sufficient to justify the associated bloat.

There always will be attempts to create something new (such as C#) which may even become very popular (sales force has strong influence on a weak mind), but I don't think they're going to be better than C.

[NorthGuy]

Or the syntax of declarations, it's horrible. Just recently I thought I was very smart because I knew how to declare a function returning int[2], but it didn't work. "Expected something something", very helpful, thank you. I spent a minute trying different combinations of parentheses even though I was quite sure I got it right the first time. Finally gave up, went to the Internet, turns out that fixed size arrays are the only type which cannot actually be returned from a function

Usually you would just pass a buffer to be filled by the function, but you can return an fixed array if you encapsulate it into a struct:

Code: [Select]

typedef struct {
  int array[2];
} int2;

int2 func() {
  return (int2){1,2};
}

void main(){
  printf("it is %d\r\n",func().array[1]);
}
In this case, C compiler will create a buffer in the stack and then pass the pointer to it to the function. This is exactly the same as if you created and passed the buffer to the function manually:

Code: [Select]

void func(int* array) {
  array[0] = 1;
  array[1] = 2;
}

void main(){
  int array[2];
  func(array);
  printf("it is %d\r\n",array[1]);
}

[legacy]

It is very widespread. Practically any platform supports C.

C does compile for i51, but i51 does not fully support C.
e.g. functions on i51 are not handled as functions due to the limitations imposed by the hw.

[Berni]

It is very widespread. Practically any platform supports C.

C does compile for i51, but i51 does not fully support C.
e.g. functions on i51 are not handled as functions due to the limitations imposed by the hw.

There are C compilers for the 8051 available commercially from Keil or some open source ones like SSDC.

There are even worse architectures for running C code, one of the very popular ones being the PIC16F family. There you get the same tiny addressable memory range that makes banking a must, but on top of it you get even less registers to work with, a weird hardware stack that's not part of RAM and not even a multiply instruction. Yet there are lots of C compilers out there for it. Even its manufacturer Microchip claimed that the PIC16 family is not for use with high level compilers and thus only offered a official compiler for assembler. But as third parties got C compilers working on it, so later on even Microchip gave in and started offering a offical C compiler for that family (They just bought out a company that already made an 8bit C compiler for it and rebranded it). I feel sorry for the people who had to develop this compiler as it must have been hell.

EDIT: Oh and of crouse you have to write your C code for these chips with the chip in mind. There are all sorts of issues if you try to straight out compiler a large complex C program made for a proper computer. There are some really bad architecture annoyances that even a good C compilers will struggle to work around.

[coppice]

It is very widespread. Practically any platform supports C.

C does compile for i51, but i51 does not fully support C.
e.g. functions on i51 are not handled as functions due to the limitations imposed by the hw.

There are C compilers for the 8051 available commercially from Keil or some open source ones like SSDC.

SSDC has limitations, but Kiel and IAR have 8051 compilers that will correctly compile pretty much anything written in C. Some features of C produce huge code, and/or very slow code, but it works. 8051 cored devices get used in many applications where a complex protocol has to be thrown into the software mix. Typically protocol libraries are written in full fat C, and they usually compile and run just fine with Kiel or IAR. As long as the bloated clunky binary code will fit in the available memory, and you don't need much speed, you are usually good to go.

[rstofer]

The only C compiler I have used with the PIC16F family is CC5X

http://www.bknd.com/cc5x/

At the time SDCC didn't support mid-range PICs (10 years ago?) and GNU would never support them.

It's disheartening to look at the assembly code and see the amount of paging and banking going on.  A huge percentage of the emitted code is involved with overcoming the architecture.

[coppice]

The only C compiler I have used with the PIC16F family is CC5X

http://www.bknd.com/cc5x/

At the time SDCC didn't support mid-range PICs (10 years ago?) and GNU would never support them.

It's disheartening to look at the assembly code and see the amount of paging and banking going on.  A huge percentage of the emitted code is involved with overcoming the architecture.

The best C compiler for PIC and the 8051 was the HiTech compiler. It was built specifically with crude architectures in mind, and served them well. MicroChip bought Hi-Tech, closed down the 8051 version, and made the PIC version the basis of their current compiler offering for PIC.

[Berni]

I also mainly used the HiTech C compiler for the PIC16F family and it worked pretty well for me. I never really looked into the assembler it generated, but knowing how annoying the architecture is id imagine its a mess.

Technically you can make a C compiler for anything that is a touring complete machine and has enough memory for the job. It might not be pretty when you are missing things we consider essential in modern CPUs, but it will work.. usually slowly.

[SiliconWizard]

turns out that fixed size arrays are the only type which cannot actually be returned from a function

I'm sorry to say this, but this is very basic C here. As said above, a possible workaround is to put the array inside a struct and return that.

One very simple way of at least "trying" what you wanted to do, instead of having to look for the appropriate syntax, would have to have defined an array type and use this as the return type. Like so:

Code: [Select]

typedef int MyArray_t[N];
(...)
MyArray_t SomeFunction(...) ...
Of course, then you get an appropriate error instead of a cryptic syntax error: "error: 'SomeFunction' declared as function returning an array".

That is something I recommend for instance to use function pointer types. Easier to deal with with a typedef.

And that said, returning an "array"  (or any struct that is big enough for that matter), is pretty inefficient due to how C handles return values, so that's probably the main reason why the authors thought it was silly.

The associated C rule that makes it consistent is that you can't assign an array to an array. The corresponding error will be: "error: assignment to expression with array type".

So returning an array from a function wouldn't really make sense. Arrays are a special beast in C, designed merely for convenience of simple allocation. The "value" of an array in C is not an "array" of items, it's just a pointer to it. The only exception to this is that sizeof() returns the correct size. Yes it seems a bit inconsistent, but again it's very basic C.

Now why did the authors of C think returning a struct was interesting, and not an array: well as much as they decided, again, that structs could be used as values. That was probably meant to be used with relatively small structs as a convenience to avoid passing many parameters to functions instead of one, or likewise returning several scalar values from functions instead of just one. Arrays have been thought of as a convenience from the start, structures have always been a "proper" data structure.

And there is one of my biggest gripes, no offense meant to anyone, just something that I've seen often enough to think it's not just a random fact: C is very often seen as so "simple" that many people actually do not care learning the language properly. An astounding number of C programmers actually *don't* know the language. They just appear to know enough to write code. And this is one of the biggest problems with C: not the language itself (even though there are things to be said here), but the way it's taught (or even self-taught most often)... It's simple enough that many don't learn it right, yet flexible enough that you may think you don't *need* to learn it all, and then you can shoot yourself in the foot with it. Some languages are even simpler than C, such as Pascal or even more so, Oberon, but then they are so rigid that people have no choice but learn them right. So even though those languages are too rigid for my taste, I definitely think Wirth was right about the learning factor.

And so to finally answer the OP's question: "does anybody learn C anymore?" Well, the right question, to me, would look more like: how many have actually learned C properly, and why would you think things had gotten any better? Most C courses are a complete disaster.

And obviously, the part of the question dealing with "is C still useful today", the answer is a gigantic YES.

[legacy]

So returning an array from a function wouldn't really make sense.

Yup. Precisely.

[legacy]

but Kiel and IAR have 8051 compilers that will correctly compile pretty much anything written in C.

It's not the compiler, it's the CPU that is limited, so "smart compilers" need to use a couple of tricks to *try* to workaround limitations, but if you don't take care about that, you will have surprises at run-time.

In "regular" C, automatic variables are usually allocated on the stack, but one of the hardware limitations in 8051 is that it doesn't have any stack worth speaking of, so another approach is needed.

Smart compilers do use an "overlaying" approach, which is basically a static analysis of the calls-tree, and this solves the problem for a program under the strict hypotheses that:

• it doesn't use recursion
• it doesn't have reentrant calls
• it doesn't call the same function from both main loop and from an interrupt (this is usually catastropic
• it doesn't use function pointers
• the compiler is guaranted to always know which function a function pointer points to at any one point in the code

So, basically you have to avoid all the cases where the compiler can't know which function a function pointer points to at any one point in the code because in these cases the compiler can't compute perfect call trees to see which scopes are alive in relation to other variable scopes.

Besides, the quality of that call tree is very important, so a compiler MUST be really smart since the call-tree controls how well the compiler+linker can manage to reuse memory between different function calls.

[SiliconWizard]

Smart compilers do use an "overlaying" approach, which is basically a static analysis of the calls-tree, and this solves the problem for a program under the strict hypotheses that:
(...)

I remember using SDCC quite a while ago with Cypress FX1/2 targets. Yep there were several limitations like this.

[legacy]

I made this board between 1995 and 1997. But I have always programmed it Basic11, and assembly thaks to the Basic-routines that you can call as you wish (sort of BIOS, if you remember how we programmed with DOS).

The intel micronctroller book suggested a hardware trick to read/write/fetch from the same ram. This was a good idea because the 8051 has two separated spaces, one for the code, one for the data. I didn't have any C good compiler, and SmallC51 was too limited for my programming style. I learned C on 68000 around 2001, before the university, and I played with a commercial C compiler released for DOS for cheap.

Then, years later, I started the university, and I bought a couple of other compilers: Turbo Pascal and Turbo C, both released by Borland for the DOS platform, both requested by my university for laboratories.

And it was fine, and a good experience. Just of one thing I do regret: to have spent two years in my university at following my teachers' code-style, which was found pretty crap when I started working in avionics. So I had to learn the C again, from scratch.

[bsfeechannel]

And that said, returning an "array"  (or any struct that is big enough for that matter), is pretty inefficient due to how C handles return values, so that's probably the main reason why the authors thought it was silly.

This is clearly stated in K&RC 2nd. ed. right in the introduction (page 2):

C provides no operations to deal directly with composite objects such as
character strings, sets, lists, or arrays. There are no operations that manipulate
an entire array or string, although structures may be copied as a unit.

And so to finally answer the OP's question: "does anybody learn C anymore?" Well, the right question, to me, would look more like: how many have actually learned C properly, and why would you think things had gotten any better? Most C courses are a complete disaster.

And obviously, the part of the question dealing with "is C still useful today", the answer is a gigantic YES.

+1000 

[brucehoult]

Now why did the authors of C think returning a struct was interesting, and not an array: well as much as they decided, again, that structs could be used as values. That was probably meant to be used with relatively small structs as a convenience to avoid passing many parameters to functions instead of one, or likewise returning several scalar values from functions instead of just one. Arrays have been thought of as a convenience from the start, structures have always been a "proper" data structure.

I seem to recall that K&R C only allowed passing or returning a struct by value if it was the size of an int (i.e. register) or smaller. e.g. on a 32 bit machine you could have two shorts, or a short and two chars or something like that.

I think it was probably only with the introduction of ANSI C that you could (portably) pass or return larger structs. But you usually shouldn't -- if you want to return a struct it's almost always better for the caller to allocate a local variable for the result and then pass a pointer to it as an extra argument. Many other languages in fact do this for you automatically.