Good points. It's kind of a difficult tradeoff, though -- I want to be comprehensible, but on the other hand, if there's really just one point I want to make, providing background explanations for every concept risks obscuring that point in a sea of information.

Do you see a good middle ground? (In this specific case, I think a quick definition of typesafety was probably in order, ditto why void*'s emphatically aren't typesafe -- but explaining casting, beyond "it's a way of telling the compiler to treat one type as if it were really another type", strikes me as more information than is really needed.)

"Type" is, um, pretty much exactly what it sounds like: what type of data are you dealing with?

Type information lets the compiler know how much storage to reserve for a variable. Just how much gets reserved is architecture-dependent (and I believe also compiler-dependent), but the C standard gives you a few (vague) guarantees, such as "long int will always be at least as long as int, which is always at least as long as short int". (Yes, they can legally all be the same length, and on some architectures, such as PIC microcontrollers, they are.) char is typically one byte (corresponding to the ASCII characters); on 32-bit platforms, int is typically 4 bytes.

Now then. When you define a struct type, that tells the compiler, "Hey, every time the programmer declares a variable of this struct type, reserve enough space for all the components that make up the struct." And, indeed, if all you do is declare a variable of that type and make assignments to and call functions on the members of that struct directly, you are pretty much okay. However, when you introduce pointers, things get hairier.

A pointer is a sort of meta-variable: its value, instead of being the variable in question, is actually the memory location of whatever variable you're talking about. So if you have an int* p, the value of p is the address of the first byte of however much storage needed to be allocated for an int. You can access the actual value of that memory location by dereferencing the pointer (the dereference operator is also *, which confuses the hell out of many beginning C programmers. At least it did me.)

All memory addresses are given as integers. This means, then, that all pointers are the same size (and are typically the same size as int, though I suppose that could be implementation-dependent too, even though I can't imagine why anyone would.) So, if you have a pointer to a struct of one type, you can lie and tell the compiler to treat it as a pointer to a struct of another type. The compiler doesn't know any better, and will blithely let you dereference data members in the struct-of-another-type, even if they were never initialised in the first place. (In which case you will get a segmentation fault at runtime, as you are trying to "dereference a NULL pointer".)

To make a long story short (too late!), a pointer doesn't really know what kind of data it points to, even though in the syntax it pretends to. In other, more type-strict languages, you don't get pointers; you get references, which do know what they're pointing to. Paradoxically, this leads to lazily typed languages like Python, which will blithely let you do things like creating a list of arbitrarily typed references and then throw errors at runtime when you try to do things like use arithmetic operators on classes which don't have those operators defined.

Crap. I wasn't planning on making this that detailed.

You've obviously never programmed on an Alpha, and possibly not on any other 64 bit arch either :)

That is correct :) Well, mostly correct. One of my dev boxes on campus is a dual-Opteron, but I haven't yet done anything intending to take advantage of its architecture, so I haven't sat down and really learned much about it yet.

Thanks for the heads-up.

Funny thing is, in this case it's actually remarkably clean and pretty code -- well-documented, not at all hard to follow despite the fact that there's ~10MB of it. It's just clean and pretty code that, from time to time, does things which are utterly baffling due to the fact that they're obviously premeditated. :P

Quite. :) Of course, now you've got me wishing I were working on something more general-purpose in a programming sense. I don't really find myself developing the sort of clever little algorithmic hacks that other people could use in other situations, unfortunately. The Current Project, for instance, involves taking some very hard sums and integrating them into a database backend in such a way that the end-user never realises just how much math is going into (hopefully) making his life easier, and most of the challenges I'm running into are quirks of the backend in question. Fascinating to Postgres hackers, I'm sure, but really, how many of us are there?

But putting the challenges into words helps me codify the problems and their solutions, so I end up inflicting them on you lot. Now if only I could do so in a way that didn't bore people stupid :)

Oh well. In another week this project is done, and then I can think about something else.

Ditto.

I'm glad to hear that. :) I feel like I've really drifted away from you writerly types in the last couple of years, and I miss having the time and focus to keep up with what y'all are doing. I look at what people like slithytove and Charlie et al have accomplished in the last five years and it just impresses the hell out of me. The OWW folk are a terrific group of people, and I'd hate to lose you guys out of what amounts to absentminded-professorism.

Second that! :)

Seconded.

I have talked to you for more than five minutes, though I think it was only that one time over at mycroftxxx's.

And the comments are welcome anyway. :)