A rant about C with a question at the end. :P

Question

C is okay. It's just really hard to understand.
So this is my rant about it. It starts out by listing where I've been in terms of programming and then lists my difficulties with C itself.
I discovered C many years ago. I'm not too sure how. All I know is that for many years I've wanted to know what this C thing was all about, but had no way or knowledge of how to. I didn't really know anybody before I got the 'net last year, so asking someone else was out of the question. Plus, I wouldnt've known what question(s) to ask.
As I became more proficient with the whole technology thing, I began to go to the local libraries nearby and use their free internet access to look stuff up. But I didn't get the idea to do any research about C, most likely because I didn't have the mental capacity to plan well and my access was once or twice weekly at best. Plus, the only computer I had at home was 66MHz and ran DOS, and I only knew BASIC around that time which I was comfortable and content with, so wasn't looking for a new language. I think I knew about assembly language but didn't pursue it if I did.
A couple of computer upgrades later, I finally got the 'net at home and began to see the convenience of being able to spontaneously look something up when I wanted to as good, rather than weird. Ideas gradually began to pop into my head that I'd run off and look up, and one day C became one of them. So I did some research on C and finally began to learn what it was: an incomprehensible mess of manually managed memory and low-level trickery. Since I knew a fair bit about assembly language now I decided C was worse than asm (and I had no chance of learning asm back then), and left it at that.
Being the BASIC coder I was (pun intended), I found the syntax and concepts over my head by several miles. But the fascination never died, and kept poking at me again and again. And I just had to keep forgetting about it.
I moved on from QuickBASIC, which I'd been using for just about everything, to FreeBASIC, which was in such a beta state when I tried it, I disliked it enough to move on and discovered PHP.
PHP has been called the BASIC of the 21st century, and I can understand why. There are typically at least 10 ways to do something whether in principle or method, multiple functions do the same or an equivalent task, and overall it just doesn't look like a good language. But beyond all that, PHP made sense to me. As I went along many of the things I expected to perform in a given way performed in said way, which was a huge confidence boost. The model it followed might have been convoluted, but something inside my head "clicked" when I saw PHP, so I liked it, since I could understand it easily.
But recently, I found myself hitting too many walls. I wanted to get into graphical software development, and none of the graphical extensions PHP had available would work for me. PHP-GTK did work but prevented PHP from outputting anything as an Apache module, without throwing a single error anywhere. PHP-QT wouldn't compile on my system. PHP-TK did compile, but both segfaulted when any tk_* function was called and also exhibited the Apache module issue.
So I decided then and there that I needed to switch languages.
The problem was, my current machine happens to be so slow that a GIMP operation that executes in 6 seconds on the lowest generation AMD CPU from 4-5 years ago will execute in 38 seconds on mine. I have no idea why; the machine is, after all, 2.66GHz.
Although PHP is pretty snappy on my system, I don't know how other languages would fare and don't really want to risk the experiment; I want to switch to a language I know will be as fast as, or faster than, PHP. So I decided that a compiled language would have to be it, since I regarded PHP as the fastest language I knew. I was probably wrong, but whatever.
So I set my mind to understanding C. I'd asked around online before, and someone took pity on me and explained the basics of C and I did my best to understand them. This was great for a couple of days, but didn't last all that long unfortunately. So I asked around again, dreading their responses, and with good reason too: most of the tutorials I read often left me boggled and flew over my head at one point or another, which didn't help.
But I got some dreaded tutorial links, and did my best to read them. It took me a couple of weeks to finally convince my brain to understand the point of a language that utilizes variables that doesn't contain any data, but instead references to other variables. I eventually grasped the why, but am still having quite a hard time understanding the how.
So then, after that initial hurdle, I moved onto other topics. Or rather tried to. I quickly discovered that C interconnects some of its issues so deeply that it's hard to learn one thing at a time, move on and learn the next thing - how I best learn. I don't create paths very well by reading information; I create those paths by staying away from information and letting it slowly process in my mind. But to actually remember it in the first place, it needs to make sense, and C doesn't make sense because things are so interconnected and... we come full circle.
To be honest, after about a fortnight of trying to understand pointers, I still don't understand them. I've read what is probably the best the web has to offer about pointers. Has it helped? Not really.
Either the documentation:
- is too terse and I have to slow down, risking losing interest in what I'm reading
- skips over vital points or assumes I know Pascal or some other language
- is hard to understand or is poorly written
- puts segments in the wrong order, so I don't understand everything something might depend on before I reach that something
...and in general I either give up on reading the documentation, give up on C or just cry. I've done the 3rd a few times, the 2nd quite a few times and the 1st pretty much as many times as I've read documentation.
So what are my issues with C?
Let me address the two I can think of right now:
Pointers aren't addressed "simply"; if I declare a pointer to int named x I have to use *x to access what x points to, rather than use *x to get x's location, like one does with non-pointer variables where & is used to get an address. It'd be nice if we used &x to get x's value if x wasn't a pointer and *x to get x's value if x was a pointer, rather than use this convoluted scheme.
Also, I've heard that it's a common misconception that C handles arrays natively. Elsewhere, I've heard that strings are merely arrays of char. I can understand the 2nd, but what do I do with the 1st?
I do understand that if I say printf("%d\n", x[1]) I'm effectively saying x++; printf("%d\n", x), but I don't understand how this fully works. For example, let us consider the following code:
char *filename = "<insert file here>";
int i;
struct stat filebuffer;
int status;
FILE *handle;
handle = fopen(filename, "r");
status = stat(filename, &filebuffer);
char *buffer = malloc(filebuffer.st_size);
for (i = 0; i < filebuffer.st_size; i++) buffer[i] = fgetc(handle);
printf("%s\n", buffer);
You'll of course notice the array notation. Do I understand why if I replace said notation with something to the effect of...
buffer++
buffer = fgetc(handle);
...the program segfaults? No. Likewise, I don't understand why the...
buffer++
*buffer = fgetc(handle);
...in the loop does work, printf("%s"...); causes segfaults and printf("%d"...); does not.
Another thing I found is that declaring a char *, filling it with data, and then using memcpy on said char *, the program works fine, but if I declare for example char x[1] = "hi"; the compiler will shout at me for not allocating enough arrays. Only while writing this did I realize that the 2nd element is for the null byte.
Suffice to say that C confuses me. To bits. Although I have written a 500 line program in it (579 to be exact). All said program does is display a message on the screen via Xlib, but I managed to figure out how to make a word wrapping engine using strsep and how to use XDrawPoint XDrawLine to not only create a nice UI but also let me define various UI "styles" which can be loaded at startup.
Said program uses a very big helping of "if it doesn't work stab it until it does", so not only do I not understand how a lot of it works, it probably wouldn't compile under anything except gcc. Which is from a theory perspective quite a problem, IMHO. Almost every 2nd variable is typecast to this or that type.
So put simply, every tutorial or introduction to C hasn't made a lot of sense to me. Maybe I learn slowly; I'm hoping it's that, because I can't see anything besides assembly language which would be faster than C. I plan to learn asm after I've mastered the very basics of C, but I may end up having to learn the other way around if I expect to get anywhere.
Like I said in the title, I have one actual question in this post. So here it is:
Are there any fun, easy reading tutorials out there that don't visually look like they came out of 1992 and read like http://poignantguide.net/ or http://learnyouahaskell.com/?
-dav7

Answer 1

dav7 wrote:Pointers aren't addressed "simply"; if I declare a pointer to int named x I have to use *x to access what x points to, rather than use *x to get x's location, like one does with non-pointer variables where & is used to get an address. It'd be nice if we used &x to get x's value if x wasn't a pointer and *x to get x's value if x was a pointer, rather than use this convoluted scheme.
Pointer syntax is extremely unfortunate. The best part:
char *a; // It's a pointer.
*a; // It's a character. Good move, guys.
Also, I've heard that it's a common misconception that C handles arrays natively. Elsewhere, I've heard that strings are merely arrays of char. I can understand the 2nd, but what do I do with the 1st?
Insofar as C has arrays, C strings are character arrays. C arrays are just a promise that the system won't mess within a certain set of memory addresses. Array syntax is a concise way to calculate and dereference a specific location in memory, relative to an address that you hope is the beginning of some memory you reserved. array[n] = *(array + n), right? Personally, I would have left out the subscript notation entirely. Regardless, any time you choose to use brackets, you can mentally substitute in an explicit addition and dereference there. You're saying, "Give me the number stored at the memory address I have just calculated, which I know by my science holds something I put there intentionally, and not garbage at all."
One more clarification with regard to pointer arithmetic is necessary: when you add 2 to an int*, the resulting address is actually 2*sizeof(int) bytes after your base address. Same for a double*: 2*sizeof(double).
I do understand that if I say printf("%d\n", x[1]) I'm effectively saying x++; printf("%d\n", x), but I don't understand how this fully works.
It's not the same! First of all, in example #2, you're passing a pointer to an int. In example #1, you're passing an integer, since [] dereferences pointers for you. Any time you use those brackets, it's as if you had typed an asterisk yourself. Second, in example #1 you're not messing with x. In example #2 you're incrementing x by four bytes (the likely size of one integer). Doesn't make a difference in this short example, but if x ever gets used again it will be very significant.
Another thing I found is that declaring a char *, filling it with data, and then using memcpy on said char *, the program works fine, but if I declare for example char x[1] = "hi"; the compiler will shout at me for not allocating enough arrays. Only while writing this did I realize that the 2nd element is for the null byte.
Looks like a counting problem. Arrays are indexed from 0, but sizes are specified from 1 on up. Your "char x[1]" has only index [0]. To hold a two-character string, you'll need at least size three (char x[3]), so that x[0]='h', x[1]='i', x[2]='\0', the null terminator.
Suffice to say that C confuses me. To bits.
Any time you get confused by pointers or arrays (which are the same thing), take a step back and think about what's happening in terms of memory addresses. Draw it out on paper if you think you're making a mistake. In some languages you can ignore low-level details like that and write perfectly fine programs, even though you won't be able to optimize them without knowing how your code maps onto the machine. But in C, everything that looks like a high-level feature is just shorthand for setting a few bytes to different numbers, and the abstraction is so leaky that you can't get by without understanding it. Types are just a way for the compiler to catch dumb mistakes (some people believe this is helpful) and to automate some math, like the pointer arithmetic above. In a running program there are no types, so when you're trying to figure out what a program is actually doing, you need to consider what the types are shorthand for.
If you're having trouble "thinking like a programmer", by which I mean sanity-checking your use of syntax and stepping through a program so you know what it does, you might want to get up to speed in a different language, or by working through a book on algorithms.
Last edited by pauldonnelly (2008-11-03 22:54:12)