C Programming Questions

[hectic]

Hello Bart (and maybe Nik and Arbee!)

Do you remember I am learning C in my spare time? Well, I've just reminded you. Progress is steady, albeit slow (a problem with learning as a hobby!). I am still up against the problem of finding a nice warm and welcoming environment to bounce questions and problems around, however, I decided to take the plunge and potentially ask some stupid questions here.

Basically, I'm working my way through my textbooks which I acquired and I have gone through the first few chapters a few times to ensure I get my head around the concepts.

I do wonder however, how useful some of the information is. What I am getting at, is whether I am spending too much time on some concepts and to what extent my time would be better spent on other areas?

I wrote the following piece of code to explain the difference between prefix and postfix notation. I spent bloody ages on this chapter, but I am wondering to what extent this would be used in - for example - emulation and in C more generally? You may remember than emulation is my 'hook' so I tend to try and apply my learning to the concept. Some things I can see the relevance of, others less so. Also, although I understand the logic, there must be a better way of re-declaring the values, rather than simple repetition? Couldn't I just declare them at the beginning and refer the code back to the beginning in a loop with some form of if/or statement based on != to the original values? If so, what would be the most efficient way of writing the code?

Anyway, here is the code (sorry if it's a bit shabby!)

main()
{
int x = 2, y = 3, result; // initialise and declare the variables

/*Show values before and after expression*/
printf("\nSTARTING VALUES: x = %d; y = %d\n", x, y);
result = ++x + y;
printf("PREFIX: The result of ++x + y = %d\n", result);
printf("After calculation x = %d and y = %d\n", x, y);

x = 2, y = 3; /*Restore values*/
printf("\nSTARTING VALUES: x = %d; y = %d\n", x, y);
result = x++ +y;
printf("POSTFIX: The result of x++ +y = %d\n", result);
printf("After calculation, x = %d and y = %d\n", x, y);

}

Any help or encouragement is very much appreciated. I am still really enjoying it, but there's so much to learn and although I honestly don't want to cut corners, I do want to ensure I am learning the appropriate things effectively, so if I could bend your ear about real-world (doesn't have to be emulation-centric) examples of where pre and post notations are needed, then so much the better.

Thanks

[Bart]

If I understand correctly, you have two questions:

1. Is there a point to learning the difference between x++ and ++x?
2. Is there a better way to reset the values of x and y after each experiment?

Re: #1, keep in mind that language textbooks are typically focused on the very fundamentals, not on higher level logic and program design concepts. You're learning vocabulary and grammar so you can write novels and poems later on. It is indeed important. But it's okay to move on once you've think you've got the basic idea. If you're really stuck and nobody seems to be making it clearer, you may as well move on to the next subject. It might click in the future when you revisit it.

Re: #2, kind of. This is a trivial example and I think it's fine.

If you wanted to perform a bunch of tests involving the same numbers and you want to try these tests out with different sets of numbers, the easy solution is to avoid modifying x and y directly and instead copy them to some other set of working variables each time. That way, x and y function as parameters of your experiment and you only have to modify them in one single place. You can even declare them as constants with the 'const' keyword to make sure you never accidentally try to re-set them:

Code: Select all

const int x = 2, y = 3;

a = x;
b = y;
// do some stuff and print the results

a = x;
b = y;
// do different stuff and print the results

a = x;
b = y;
// and now for something completely different


[hectic]

Thanks Bart. You're right of course. I guess the point I was most concerned with was that - and forgive me for abusing the analogy you used - I was spending too much time learning to write poetry and not the skills I'd need to write novels, if that makes sense?

I am on 'functions and arrays' at the moment (chapter seven). I've finally understood, following the frankly absurd explanation, the role of void in a program and where it's needed.

Would you recommend K&R as a learning tool? As soon as I have finished this book, I'll be hungry for something a bit more 'seminal' and academic.

[Bart]

I didn't learn from K&R but generations of programmers have. My path was circuitous: I started with a "Teach Yourself C++ in 21 Days" book and, after feeling that I wasn't really "getting it" and peppering the author with questions by email, I took up assembly language for a couple of years in high school. This was back in the Windows 95 days, when assembly and DOS programs were still somewhat relevant. Assembly language is what made everything finally click for me and taught me how computers really work. With it, I was able to start doing interesting things like basic graphics, which I had previously only been able to do with QuickBASIC. That's the main frustration you're going to run into learning C: you'll be learning a lot of syntax and grammar but even by the end of the book, you won't really understand how to actually do stuff with it. This in turn will make retaining some of these concepts difficult because you won't be putting them into practice.

After my detour through assembly land, I picked up "A Book on C", and all of a sudden it all made perfect sense. It's a fantastic book but probably worthless to absolute beginners. My recommendation to you is to keep doing what you're doing. Everyone's path is different. Because of the proliferation of different layered technologies and interfaces these days, it can be quite daunting to learn how to actually do things. C is too low level to do anything interesting on its own in this sort of environment (at least at first) and the other stuff is too restrictive and depends on a myriad of mysterious, underlying APIs. If you insist on continuing with C (and if you're interested in emulation, that's a good route to take), dabbling with SDL once you feel comfortable with functions, arrays, and pointers, might be worthwhile. At least then you can start interacting with the underlying OS and hardware the way real emulators and games do. Being able to create a window (or full screen app) to draw things to will be infinitely more relevant and exciting than writing pointless programs that print things to the terminal

[hectic]

That's the main frustration you're going to run into learning C: you'll be learning a lot of syntax and grammar but even by the end of the book, you won't really understand how to actually do stuff with it. This in turn will make retaining some of these concepts difficult because you won't be putting them into practice.

I was thinking that the other day and had a discussion about the very same issue with my - long suffering, but thankfully patient - partner. Can I have next week's lottery numbers while you're here?

My recommendation to you is to keep doing what you're doing. Everyone's path is different. Because of the proliferation of different layered technologies and interfaces these days, it can be quite daunting to learn how to actually do things. C is too low level to do anything interesting on its own in this sort of environment (at least at first) and the other stuff is too restrictive and depends on a myriad of mysterious, underlying APIs. If you insist on continuing with C (and if you're interested in emulation, that's a good route to take), dabbling with SDL once you feel comfortable with functions, arrays, and pointers, might be worthwhile. At least then you can start interacting with the underlying OS and hardware the way real emulators and games do. Being able to create a window (or full screen app) to draw things to will be infinitely more relevant and exciting than writing pointless programs that print things to the terminal

Noted re SDL. Thanks for taking the time to explain these things and for your help and encouragement. You are certainly right on one thing though; decision-tree programs and glorified calculators are bloody boring, but I know that these are teaching me syntax and grammar (and the programs are - by and large - irrelevant). I just need to keep focussed on the point as to why I am learning these things, rather than the functions of the programs themselves.

[Bart]

That's the main frustration you're going to run into learning C: you'll be learning a lot of syntax and grammar but even by the end of the book, you won't really understand how to actually do stuff with it. This in turn will make retaining some of these concepts difficult because you won't be putting them into practice.

I was thinking that the other day and had a discussion about the very same issue with my - long suffering, but thankfully patient - partner. Can I have next week's lottery numbers while you're here?

I didn't mean that to discourage you or anything. It was just to reassure you that it's perfectly normal to feel confused, with even more questions than when you began learning, after you get all the way through your first programming book

Noted re SDL. Thanks for taking the time to explain these things and for your help and encouragement. You are certainly right on one thing though; decision-tree programs and glorified calculators are bloody boring, but I know that these are teaching me syntax and grammar (and the programs are - by and large - irrelevant). I just need to keep focussed on the point as to why I am learning these things, rather than the functions of the programs themselves.

Right. After you get through the first book, you can probably start looking at applications of C and C++, namely game programming. I don't know what's out there these days but I'm sure there are accessible game programming books or tutorials out there.

Earlier this year, I was working on a web site that was supposed to teach people how to write games in Ruby (not normally a language used for game programming) via a Java applet. The project ended up being shelved due to a lack of time but I've often thought of resurrecting it. I would probably go with JavaScript this time around. I'd be very curious to hear your thoughts as you continue along your journey learning how to program. Namely, what sorts of things confuse you and how you ended up figuring them out. It would be interesting to know whether more interactive visualizations or exercises would be helpful or detrimental.

[hectic]

Yeah, I'd be very interested in giving you some feedback and assistance from a 'student' point of view. you have my email address (back from when you wanted Codewarrior - which I still have by the way). However, if you have deleted it, you can just just drop me a PM on here. I'll give you any assistance I can.

I've found one really good general emulation-centric programming text. It's here if you're interested: http://personals.ac.upc.edu/vmoya/docs/emuprog.pdf and it seems really helpful and pitched at an intermediate level (though that's merely my ill-informed opinion, of course).

I've been reading it on and off for ages. Some of it is more advanced than where I am, but the more I learn with syntax and grammar, the more I can understand what it is saying and how things fit together. I've also been reading source-code for chip8 and NES emulators. Surprisingly, I understand quite a bit of it, but I would really struggle to write it from scratch. I could tell you what a fair bit of the code was doing, but in the vast majority of cases, I couldn't tell you why it was doing it, or in some cases, needed.

So, in conclusion, thanks for the support - it's much appreciated and I'm sorry for seeking reassurance! I'm sure as I go on, I will have more specific questions. I will no doubt keep this forum folder busy with my thoughts and meanderings. When you have a bit more time (I appreciate time is not a luxury you have at the moment), then don't hesitate to contact me about resurrecting your project. I'd be delighted to lend a hand in any way I can.

[Bart]

Victor's document is good. The principles of emulation could be described in an even simpler, less comprehensive guide, however. If you can understand the source code to other emulators, you might as well begin trying to write something of your own. A good place to start is writing a CPU debugger for some architecture that interests you. If your ultimate objective is NES, you would pick the 6502. Actually, regardless of what your ultimate objective is, I would recommend starting with a simple 8-bit CPU. The 6502 is about as simple as they come.

The first thing you'll need to do is write some 6502 programs of your own to test, meaning you'll need to get a hold of a 6502 assembler and learn how to use it. In conjunction with a hex editor, it should be possible for you to do some experimentation and begin to understand how the assembler is producing binary files. Then, the next step would be to load those files up in a C program and see if you can write a disassembler: a routine that will attempt to detect the opcode at a given opcode in the memory buffer you've filled up with 6502 program data and print out the corresponding, human readable assembly-language statement. The core of this will likely be a big switch() statement, or some sort of table look-up. There are a few ways to do it.

I do still have your email but feel free to write me first if you have any thoughts about the learning process and what you'd like to see that could improve it.

[hectic]

Victor's document is good. The principles of emulation could be described in an even simpler, less comprehensive guide, however. If you can understand the source code to other emulators, you might as well begin trying to write something of your own. A good place to start is writing a CPU debugger for some architecture that interests you. If your ultimate objective is NES, you would pick the 6502. Actually, regardless of what your ultimate objective is, I would recommend starting with a simple 8-bit CPU. The 6502 is about as simple as they come.

The first thing you'll need to do is write some 6502 programs of your own to test, meaning you'll need to get a hold of a 6502 assembler and learn how to use it. In conjunction with a hex editor, it should be possible for you to do some experimentation and begin to understand how the assembler is producing binary files. Then, the next step would be to load those files up in a C program and see if you can write a disassembler: a routine that will attempt to detect the opcode at a given opcode in the memory buffer you've filled up with 6502 program data and print out the corresponding, human readable assembly-language statement. The core of this will likely be a big switch() statement, or some sort of table look-up. There are a few ways to do it.

I do still have your email but feel free to write me first if you have any thoughts about the learning process and what you'd like to see that could improve it.

Woah, woah, woah (sweet child o' mine). I think writing disassemblers is a few too many steps for me at the moment. I can read some source code (recognising uint8/16 and knowing what some functions are doing), but I don't think I have the confidence to write my own source. It's like learning German for me. I could get about in Germany (and not be the classic Brit abroad of speaking English LOUDLY and s l o w l y). I can recognise words and therefore take an educated guess as to what the sentence is saying, but not form complex sentences of my own.

I will compose thoughts for you and drop you a mail sometime this weekend (is your. edu address ok?) I have some initial ideas for effective learning methods, but how those could be extrapolated into something viable, I don't know. It revolves around an IDE for beginners, with user-friendly examples templates and exercises. I will drop you the details soon.

[Bart]

It's not an overnight project. Start with what you know and then determine what you don't know. With a disassembler, you would have to be comfortable reading in files (in binary) mode and manipulating them in terms of bytes. There's a logical starting point for you: figure out how to load files and then print hex dumps of them. Maybe you're not there yet but after learning about file I/O and arrays, you should be set. The book alone won't provide all the necessary answers but it'll be a starting point for seeking additional material online, such as concise documentation describing the fopen() and fread() functions.

An important skill to develop is breaking the problem down into its fundamental components. Yes, a disassembler is a daunting task initially, but think about the basic grunt work that the disassembler has to do, and start there. If the problem is still too big, think about how it can be subdivided further until you find a chunk that you think you should know how to do, based on what material you've covered in your textbook so far, but still feel incapable of doing. Then, slowly set out to learn more about how to fill in those missing pieces to accomplish your reduced task. I'm not sure how far you've gotten so far but I think reading in a file in binary mode and then printing out the bytes in some human readable form (integers initially, and then pairs of hex digits) should be a task that you can at least start working towards soon.

My .edu address is fine.