Hello guys,
first of all: a huge Thank You to Casey for doing this. I missed the C64/Amiga coding train when I was young, and then fell into the scripting wagon in 1995. These days as one might expect (and for the past 15+ years) I've been a web developer for a living. You have no idea how much I hoped in the past that this gift of knowledge could be given by someone that walked exactly the path you did back then.
I'd like to introduce myself, and ask a few questions!
To this day, I implemented my own engines (purely for the need of knowing and for fun) in JavaScript, C# and Java, in that order over the years, because I had to go from the language I was most familiar with, and free my brain from having to figure out HOW to implement a feature in good code, while learning what was needed to solve a specific problem (say path-finding in a grid with A*).
Every change of language was driven by the availability and quality of knowledge on the topics at hand (man, java programmers are into gaming! that language has the most amazing collection of good quality writing/tutorials/examples on how to accomplish almost anything when it comes to game engines).
My quest was one towards the freedom to turn my ideas into my own implementations, without compromising on performances and features. Every push forward always had me look at C with envy, when my ray caster implemented in C# or Java would under perform compared to say the one implemented in native code inside libraries like Box2D (same implementation, single threaded in all languages and external libs).
Before I started with your sessions I had a general idea of how things worked, but absolutely ZERO clue on how to wield the power of C/C++. I might be a strange case:
I studied CPU Design in school, back in the 90ies, when we sprinkled ASM inside Turbo Pascal sources, so I am familiar with endianness, memory layout and machine code instructions (although I never programmed x86, back then we used to code on Z80 processors slapped on breadboards :D).
In other words, while I have zero issues with the concepts of pointers, bit-wise operations and memory read/write/allocation/deallocation, I have absolutely NO KNOWLEDGE whatsoever of what it means to write a program in C/C++.
And here comes my question:
We are writing code in a cpp file, and you mentioned that you only ever use function overloading and "few other features" from C++, while the rest is standard C. To me that distinction is a very blurry line, not knowing what other differences are there between the two languages.
Can anyone point to a good (as in "complete") reading material on the topic, so that I can at least have a clue of which parts of the two languages we are using while we write the code?
So far in my mind I can only make distinctions when I see the following:
void *pointers -> C++
function overloading -> C++
classes -> C++
everything else, as far as I'm concerned, could be either!
I thank you in advance for any answer you might push my way, and all I want to say again is Thank You for this, to Casey and to the whole community that has built around Handmade Hero. It feels absolutely great to be here!
Cheers!
Luca
P.S. Casey, watching you use MSDN makes it look so easy! I could hardly ever find what I needed in there, and it was in no small part the reason why I never got into C/C++. You proved that if you know what to look for, that documentation is well made. Which again reinforces the pure awesomeness of this project!
first of all: a huge Thank You to Casey for doing this. I missed the C64/Amiga coding train when I was young, and then fell into the scripting wagon in 1995. These days as one might expect (and for the past 15+ years) I've been a web developer for a living. You have no idea how much I hoped in the past that this gift of knowledge could be given by someone that walked exactly the path you did back then.
I'd like to introduce myself, and ask a few questions!
To this day, I implemented my own engines (purely for the need of knowing and for fun) in JavaScript, C# and Java, in that order over the years, because I had to go from the language I was most familiar with, and free my brain from having to figure out HOW to implement a feature in good code, while learning what was needed to solve a specific problem (say path-finding in a grid with A*).
Every change of language was driven by the availability and quality of knowledge on the topics at hand (man, java programmers are into gaming! that language has the most amazing collection of good quality writing/tutorials/examples on how to accomplish almost anything when it comes to game engines).
My quest was one towards the freedom to turn my ideas into my own implementations, without compromising on performances and features. Every push forward always had me look at C with envy, when my ray caster implemented in C# or Java would under perform compared to say the one implemented in native code inside libraries like Box2D (same implementation, single threaded in all languages and external libs).
Before I started with your sessions I had a general idea of how things worked, but absolutely ZERO clue on how to wield the power of C/C++. I might be a strange case:
I studied CPU Design in school, back in the 90ies, when we sprinkled ASM inside Turbo Pascal sources, so I am familiar with endianness, memory layout and machine code instructions (although I never programmed x86, back then we used to code on Z80 processors slapped on breadboards :D).
In other words, while I have zero issues with the concepts of pointers, bit-wise operations and memory read/write/allocation/deallocation, I have absolutely NO KNOWLEDGE whatsoever of what it means to write a program in C/C++.
And here comes my question:
We are writing code in a cpp file, and you mentioned that you only ever use function overloading and "few other features" from C++, while the rest is standard C. To me that distinction is a very blurry line, not knowing what other differences are there between the two languages.
Can anyone point to a good (as in "complete") reading material on the topic, so that I can at least have a clue of which parts of the two languages we are using while we write the code?
So far in my mind I can only make distinctions when I see the following:
void *pointers -> C++
function overloading -> C++
classes -> C++
everything else, as far as I'm concerned, could be either!
I thank you in advance for any answer you might push my way, and all I want to say again is Thank You for this, to Casey and to the whole community that has built around Handmade Hero. It feels absolutely great to be here!
Cheers!
Luca
P.S. Casey, watching you use MSDN makes it look so easy! I could hardly ever find what I needed in there, and it was in no small part the reason why I never got into C/C++. You proved that if you know what to look for, that documentation is well made. Which again reinforces the pure awesomeness of this project!
So far in my mind I can only make distinctions when I see the following:
void *pointers -> C++
function overloading -> C++
classes -> C++
void* is not a C++ feature. It exists in C. The other C++ feature Casey uses (which we just saw when implementing vectors) is operator overloading. And there is at least one other somewhat subtle C++ feature he uses which is struct declarations.
In C++, you can type
1 2 | struct vec { int x; int y; };
vec v;
|
but in C, you would have to precede the variable declaration with struct:
1 | struct vec v; |
unless you declare it like this:
1 | typedef struct _vec { int x; int y; } vec;
|
Some other differences are discussed here.
In addition to classes, other big C++ features include templates, namespaces, and reference types (which are actually just pointers under the hood).
Thanks Flyingsand!
I don't know why the fact that void * was C++ only stuck in my mind, I swear I though Casey said so during the early episodes, it must have been something regarding casting instead. Must have misunderstood, so thanks for clarifying that!
Aside from what has been said so far by Casey and the reason why he doesn't use most of the C++ features, is there a realm in which one might not be able to compile unless the sources are strictly using C only features? (Thinking embedded systems), I guess that depends on the compiler eh? I'll cross that bridge if I ever get to it.
Anyhow, I suppose I will consider the subset I'm learning now as a good starting point for low level programming, eventually cherry picking from the rest as I need/grow with it.
Ultimately, the resource you linked is exactly what I was looking for! Thank you :)
I don't know why the fact that void * was C++ only stuck in my mind, I swear I though Casey said so during the early episodes, it must have been something regarding casting instead. Must have misunderstood, so thanks for clarifying that!
Aside from what has been said so far by Casey and the reason why he doesn't use most of the C++ features, is there a realm in which one might not be able to compile unless the sources are strictly using C only features? (Thinking embedded systems), I guess that depends on the compiler eh? I'll cross that bridge if I ever get to it.
Anyhow, I suppose I will consider the subset I'm learning now as a good starting point for low level programming, eventually cherry picking from the rest as I need/grow with it.
Ultimately, the resource you linked is exactly what I was looking for! Thank you :)
A typical "modern" C++ program would be object oriented, avoid raw pointers (any pointers we use here, they would instead go for smart pointers or other "pointer containers") and memory management. This would make the code look very different. Of course to make things even easier for a newcomer, not everyone agrees with how C++ should be used. The language is just too big. I'd recommend learning C (http://c.learncodethehardway.org/book/introduction.html is a good modern source I've been told) and then learn some C++. C is a small language so you can quickly pick it up. This makes it easy to spot the C++. After this I'd recommend going through some C++ material to see how it's used differently and if you like that or not. Seriously, C is fast to learn. Learn C.
Just a note: I'm not that familiar with C++, I tend to write very C:ish C++ code which is often considered ugly by the C++ folk.
Just a note: I'm not that familiar with C++, I tend to write very C:ish C++ code which is often considered ugly by the C++ folk.
burn
Thanks Flyingsand!
I don't know why the fact that void * was C++ only stuck in my mind, I swear I though Casey said so during the early episodes, it must have been something regarding casting instead. Must have misunderstood, so thanks for clarifying that!.
In regards to casting, there is a difference between C and C++. In C, it's perfectly legal to do this:
1 | int* x = malloc(sizeof(int)); |
but in C++ you need to explicitly cast it like so:
1 | int* x = (int *)malloc(sizeof(int)); |
So you can't implicitly cast from void* in C++ like you can in C.
Aside from what has been said so far by Casey and the reason why he doesn't use most of the C++ features, is there a realm in which one might not be able to compile unless the sources are strictly using C only features? (Thinking embedded systems), I guess that depends on the compiler eh? I'll cross that bridge if I ever get to it.
Yeah, that would depend on the compiler. Even if you have a C++ compiler, it may not support all the language features. e.g. MSVC is notoriously slow in adopting new C++ features (C++11 and C++14).
Then there's also the case where you may be porting the code to other platforms like OS X. In order to interface with Cocoa in OS X you need to use at least some Objective-C or Swift. Objective-C can handle C++ (through Objective-C++) but Swift can't as far as I know. Somebody has ported Handmade Hero using Swift and any HMH code that is used directly in the Swift layer has to be C-compliant. If you look at handmade_platform.h, Casey did change all the struct declarations in that file to be C and wrapped it all in an extern "C" block.
Edited by Flyingsand
on
Flyingsand
In order to interface with Cocoa in OS X you need to use at least some Objective-C or Swift.
Actually this is not true. You can write application fully in C interacting with Cocoa/UIKit API (or anything else with ObjectiveC) by using ObjectiveC runtime library. Of course it is huge pain to do so, but its possible. For example - here is code for simple iOS and OSX applications that opens window and draws rectangle fully written in C: https://stackoverflow.com/questio.../how-to-write-ios-app-purely-in-c
mmozeikoFlyingsand
In order to interface with Cocoa in OS X you need to use at least some Objective-C or Swift.
Actually this is not true. You can write application fully in C interacting with Cocoa/UIKit API (or anything else with ObjectiveC) by using ObjectiveC runtime library. Of course it is huge pain to do so, but its possible. For example - here is code for simple iOS and OSX applications that opens window and draws rectangle fully written in C: https://stackoverflow.com/questio.../how-to-write-ios-app-purely-in-c
Well, yes, that's technically true. But like you said, a PITA. ;)
So for all practical purposes, you would use at least a little bit of Obj-C or Swift.
Thanks guys, all useful info! Sounds like I will have plenty of decades to keep piling up knowledge in this realm :)
@ schme
I know what you mean first hand. I've worked in the gaming industry (AAA) as technical designer for a few years (hated thoroughly every moment of working in a 100+ people team, never again for me), and even the most professional coders there couldn't agree among themselves on the best way to use the language. As you say: there are too many ways to write it, and here I trust Casey's 30 years of experience to teach me what he found to be the most rational/down-to-earth approach to write code that won't drive a mind insane.
Also, I can't count the times I've read this front to back, it just doesn't stick unless I go through a full project implementation with the language, and then some! Which is exactly what I haven't done till now, because of the lack of accessible material on the topic.
Which, again, is exactly what I thank Casey for sharing! I bought the source to support him, but I don't even open it, I write every line myself, as he goes. In fact, I got my first access violation error on the back buffer way before he got his in the stream. Debugging it cemented certain concepts in my head in a way that just reading or simply watching him do it can't do.
So far his approach to both dev environment and code seems pretty tidy to me, and I have absolutely no objections, in fact, it's leaner and cleaner than what I've seen in professionally structured projects.
So I'll end up forming my C/C++ skills around Casey's model, and I feel pretty confident it will give me exactly what I need. One day perhaps I will develop my own opinions on the various aspects involved, and pick my own.
@ schme
I know what you mean first hand. I've worked in the gaming industry (AAA) as technical designer for a few years (hated thoroughly every moment of working in a 100+ people team, never again for me), and even the most professional coders there couldn't agree among themselves on the best way to use the language. As you say: there are too many ways to write it, and here I trust Casey's 30 years of experience to teach me what he found to be the most rational/down-to-earth approach to write code that won't drive a mind insane.
Also, I can't count the times I've read this front to back, it just doesn't stick unless I go through a full project implementation with the language, and then some! Which is exactly what I haven't done till now, because of the lack of accessible material on the topic.
Which, again, is exactly what I thank Casey for sharing! I bought the source to support him, but I don't even open it, I write every line myself, as he goes. In fact, I got my first access violation error on the back buffer way before he got his in the stream. Debugging it cemented certain concepts in my head in a way that just reading or simply watching him do it can't do.
So far his approach to both dev environment and code seems pretty tidy to me, and I have absolutely no objections, in fact, it's leaner and cleaner than what I've seen in professionally structured projects.
So I'll end up forming my C/C++ skills around Casey's model, and I feel pretty confident it will give me exactly what I need. One day perhaps I will develop my own opinions on the various aspects involved, and pick my own.
Edited by Luca Vignaroli
on
I totally agree with what you said about K&R and it often gets unmentioned (maybe we're the only people with this problem!). Before moving to C I had used Python, so after finishing the book my initial reaction was "well what the doo am I going to do with just this?". I'm glad to hear even people with real-life experience are finding the same delight in the same aspects as I have. Takes a lot of the worry off from it being just me not having any real experience outside of my own stuff.