Current mood:

restless

How It Works vs How to Work With It

There was, by my modest standards, a huge response to my last post. I noticed two things about the comments here and on reddit:

1. My guess about what gcc does when you declare a return type but don't return anything was wrong.
2. Some readers thought I was saying that UH doesn't teach undergraduates anything about C or pointers or assembly.

Number one wasn't much of a surprise, but number two had me scratching my head. I decided to do another post explaining the difference between what I meant and what came across to some readers.

The short version is in the title: There's a difference between knowing how something works and knowing how you should work with it.

Undergraduate C at UH

UH does teach undergrads about C, though I don't claim to have learned everything they were teaching. When I said I had used C but not heavily, I was mostly referring to UH.

There's an undergraduate class that covers assembly, C, and C++. It's about a third of a semester each, but it tries to build each topic on the previous one. For example, using assembly to help explain C pointers.

The focus is on low-level concepts. What's a pointer, and how does it work? How are references different? How do all the bit-twiddling operators work? Casting pointers? That sort of thing. I can't remember if it was half the final or all of it, but we had to trace a wad of obfuscated C++ and write out the output¹.

In fact, the class was probably designed by someone who's appalled at the thought of programmers not knowing how low-level code works.

So what else do you need?

OK, I basically know how a pointer works. On that undergrad final I showed that I can sit down and trace out the path of the bullet as it enters my foot. But how do I avoid shooting myself there in the first place?

One of the professors has a technique of always allocating global, fixed-sized arrays and using indexes into them instead of pointers. He knows how pointers work. In fact he's an expert on compilers, x86 machine code, and DOS object files². He just looked at C pointers and said, "Not worth it." He made an informed decision about how to work with the language.

I made a different decision (and maybe you should take his advice instead of mine). I still use pointers in C because I felt that going so far out of the way to avoid them was cutting against the grain of the language and making it hard, for me at least, to build things on top of it.

Instead, I found other ways to cut down my foot-shooting. I didn't need them when I was writing tiny programs to learn how C works. I did need them to work with C and create a not-so-tiny program that actually did something significant.

Controversy

I should have been clearer about that. There's a debate over whether you should know how C works even if you aren't going to use C, and I accidentally got too close to it.³

Knowing how to work with C is less controversial. I think pretty much everyone would agree that you need it if you're using C for something serious and otherwise you don't⁴. Of course, working with C will involve applying general concepts like encapsulation, but I doubt that's what people are referring to when they get disgusted that not everyone "knows C."