A Low Level Curriculum for C and C++(altdevblogaday.com)
altdevblogaday.com
A Low Level Curriculum for C and C++
http://www.altdevblogaday.com/2011/11/09/a-low-level-curriculum-for-c-and-c/
6 comments
There's a series of lectures on core C++ and the STL which you can download for free from channel9.msdn.com from a guy called Stephan T. Lavavej who works on the STL at Microsoft. I only wish my University lectures were half as good as these. They're jammed full of useful information. They're still being updated, the latest came out earlier this month.
These look great, they can also be streamed from http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavave...
If you're really interested in your subject you don't need people telling you what to learn and not to learn. I mean most of University for me was a juggling act between doing the prescribed courses and learning things I thought was important because well, it was important, even though it wasn't part of the course.
Like going through Knuth's and Steven's books, or learning assembler, or how to use a debugger, or writing a 3d engine, or implementing some data compression algorithms, etc.
None of these were prescribed but it's kind of intuitive that you should at least know how to do these things if you're studying computer science, I would think?
Like going through Knuth's and Steven's books, or learning assembler, or how to use a debugger, or writing a 3d engine, or implementing some data compression algorithms, etc.
None of these were prescribed but it's kind of intuitive that you should at least know how to do these things if you're studying computer science, I would think?
>> If you're really interested in your subject you don't need people telling you what to learn and not to learn.
You at least need someone to expose you to what is available to learn. It's possible that without guidance a lot of people would never even think of going to the lower levels, they can be nearly invisible to someone working on (for instance) web apps with high level server frameworks and lots JS.
When it comes down to it, you need to know what you don't know, and some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101.
Particularly in a country where pre-university computer education is inadequate or absent. Most UK CompSci folks have mathematical and science backgrounds but no formal education in computer science or programming.
You at least need someone to expose you to what is available to learn. It's possible that without guidance a lot of people would never even think of going to the lower levels, they can be nearly invisible to someone working on (for instance) web apps with high level server frameworks and lots JS.
When it comes down to it, you need to know what you don't know, and some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101.
Particularly in a country where pre-university computer education is inadequate or absent. Most UK CompSci folks have mathematical and science backgrounds but no formal education in computer science or programming.
This is very true, and I can attest to it from personal experience.
I grew up in Redmond Washington, in the heart of Microsoft - land, surrounded by programming and programmers. I learned a lot of the mental meta-skills that go hand in hand with programming, but I didn't ever learn to program, even though I thought it interesting and I wanted to understand it.
It was a challenge to even know what I wanted to know, and there wasn't anyone around to answer my "but how, and why?" questions to begin learning. It took till I was in college for me to start learning to program, because I had excellent professors who would answer my questions for literally hours. As well, I finally had problems that needed solving (if for no other reason than I needed to turn them in).
I grew up in Redmond Washington, in the heart of Microsoft - land, surrounded by programming and programmers. I learned a lot of the mental meta-skills that go hand in hand with programming, but I didn't ever learn to program, even though I thought it interesting and I wanted to understand it.
It was a challenge to even know what I wanted to know, and there wasn't anyone around to answer my "but how, and why?" questions to begin learning. It took till I was in college for me to start learning to program, because I had excellent professors who would answer my questions for literally hours. As well, I finally had problems that needed solving (if for no other reason than I needed to turn them in).
> some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101.
This is forever a balance between the universal constants of the low-level world, and stuff which seems to be a constant but it actually a flavor-of-the-month and will be obsolete by the time you're in a position to apply it.
For example, someone taking an architecture course (learn assembly language from the transistor up!) will likely learn on the MIPS, because it's a simple design which fits a simple five-stage pipeline model very cleanly and it has a simple, easy-to-teach machine code ISA as well. Plus, of course, Hennessy and Patterson teach MIPS, so you get to use their well-written book if you do, too.
However, spending your time learning how to schedule opcodes to take advantage of a branch delay slot, which is an intrinsic part of the MIPS worldview, is a mistake. No architecture in modern use has them: ARM, PowerPC, and even the venerable Alpha found a way to avoid the concept, and, of course, the x86 has never had them. Branch delay slots are a flavor of the month from decades ago; they're downright archaic today.
(DSPs seem to have them. Will they have them a couple generations from now? Are you actually going to learn enough about the other unique features of DSPs to make learning about branch delay slots worthwhile?)
OTOH, teaching the theoretical side is a lot closer to being future-proof: Even if certain algorithms get finessed by differences in future hardware design, learning to think rigorously is always a useful pursuit.
This is forever a balance between the universal constants of the low-level world, and stuff which seems to be a constant but it actually a flavor-of-the-month and will be obsolete by the time you're in a position to apply it.
For example, someone taking an architecture course (learn assembly language from the transistor up!) will likely learn on the MIPS, because it's a simple design which fits a simple five-stage pipeline model very cleanly and it has a simple, easy-to-teach machine code ISA as well. Plus, of course, Hennessy and Patterson teach MIPS, so you get to use their well-written book if you do, too.
However, spending your time learning how to schedule opcodes to take advantage of a branch delay slot, which is an intrinsic part of the MIPS worldview, is a mistake. No architecture in modern use has them: ARM, PowerPC, and even the venerable Alpha found a way to avoid the concept, and, of course, the x86 has never had them. Branch delay slots are a flavor of the month from decades ago; they're downright archaic today.
(DSPs seem to have them. Will they have them a couple generations from now? Are you actually going to learn enough about the other unique features of DSPs to make learning about branch delay slots worthwhile?)
OTOH, teaching the theoretical side is a lot closer to being future-proof: Even if certain algorithms get finessed by differences in future hardware design, learning to think rigorously is always a useful pursuit.
"If you're really interested in your subject you don't need people telling you what to learn and not to learn."
Only if you don't mind spending 5 year on what could have been done in 1 if only someone had told you what to focus on, where to start looking and every now and then points out some connections that you missed yourself. Of course it's possible to learn the same thing somebody learns in university on your own. Whether you can learn it as efficiently - that's another question.
Only if you don't mind spending 5 year on what could have been done in 1 if only someone had told you what to focus on, where to start looking and every now and then points out some connections that you missed yourself. Of course it's possible to learn the same thing somebody learns in university on your own. Whether you can learn it as efficiently - that's another question.
I think that the combination of directed coursework and self-study is what a formal education is really about. There is no way a set curriculum can teach you everything that you may need in a dynamic world; you have to learn the curriculum, but you also have to learn what you personally are interested, and you have to learn how to teach yourself.
This way you get a solid, wide base but also some specialization/expertise in whatever niche(s) you like, and gives you the tools to advance yourself.
It has always frustrated me teaching, when students are unwilling to get out beyond what I or any other teacher tells them. Designing a syllabus makes it very apparent what a minuscule slice of any subject has to be distilled into a dozen lectures or exercises.
This way you get a solid, wide base but also some specialization/expertise in whatever niche(s) you like, and gives you the tools to advance yourself.
It has always frustrated me teaching, when students are unwilling to get out beyond what I or any other teacher tells them. Designing a syllabus makes it very apparent what a minuscule slice of any subject has to be distilled into a dozen lectures or exercises.
> If you're really interested in your subject you don't need people telling you what to learn and not to learn.
And if anyone argues against you, you can just say that they're just not as passionate as you are. Brilliant.
And if anyone argues against you, you can just say that they're just not as passionate as you are. Brilliant.
I'd put learning the basics of data normalization ahead of any of your concrete examples. But maybe that's just because I partially fell into/chose that - and would otherwise have followed a rather excellent computer science degree that has no compulsory data normalization stuff... And in general I'd recommend a basic course of statistics for any science degree (as impostant as some basic philosophy, really).
Finally I'll just accept that if you're only doing 4-5 years of computer science, no one will be qualified to select which few parts to study without guidance.
[edit: spelling]
Finally I'll just accept that if you're only doing 4-5 years of computer science, no one will be qualified to select which few parts to study without guidance.
[edit: spelling]
[deleted]
It's not well linked from this first page, but this is the introduction to an excellent 12 part series: http://www.altdevblogaday.com/author/alex-darby/
Part 1: A Low Level Curriculum for C and C++ http://www.altdevblogaday.com/2011/11/09/a-low-level-curricu...
Part 2: Low Level Data Types http://www.altdevblogaday.com/2011/11/24/c-c-low-level-curri...
Part 3: The Stack http://www.altdevblogaday.com/2011/12/14/c-c-low-level-curri...
Part 4: More Stack http://www.altdevblogaday.com/2011/12/24/c-c-low-level-curri...
Part 5: Even More Stack http://www.altdevblogaday.com/2012/02/07/c-c-low-level-curri...
Part 6: Conditionals http://www.altdevblogaday.com/2012/03/07/c-c-low-level-curri...
Part 7: More Conditionals http://www.altdevblogaday.com/2012/04/10/cc-low-level-curric...
Part 8: Looking at Optimized Assembly http://www.altdevblogaday.com/2012/05/07/cc-low-level-curric...
Part 9: Loops http://www.altdevblogaday.com/2012/09/04/cc-low-level-curric...
Part 10: User defined types http://www.altdevblogaday.com/2013/01/05/cc-low-level-curric...
Part 11: Inheritance http://www.altdevblogaday.com/2013/05/03/cc-low-level-curric...
Part 12: Multiple Inheritance http://www.altdevblogaday.com/2013/05/22/cc-low-level-curric...
Part 1: A Low Level Curriculum for C and C++ http://www.altdevblogaday.com/2011/11/09/a-low-level-curricu...
Part 2: Low Level Data Types http://www.altdevblogaday.com/2011/11/24/c-c-low-level-curri...
Part 3: The Stack http://www.altdevblogaday.com/2011/12/14/c-c-low-level-curri...
Part 4: More Stack http://www.altdevblogaday.com/2011/12/24/c-c-low-level-curri...
Part 5: Even More Stack http://www.altdevblogaday.com/2012/02/07/c-c-low-level-curri...
Part 6: Conditionals http://www.altdevblogaday.com/2012/03/07/c-c-low-level-curri...
Part 7: More Conditionals http://www.altdevblogaday.com/2012/04/10/cc-low-level-curric...
Part 8: Looking at Optimized Assembly http://www.altdevblogaday.com/2012/05/07/cc-low-level-curric...
Part 9: Loops http://www.altdevblogaday.com/2012/09/04/cc-low-level-curric...
Part 10: User defined types http://www.altdevblogaday.com/2013/01/05/cc-low-level-curric...
Part 11: Inheritance http://www.altdevblogaday.com/2013/05/03/cc-low-level-curric...
Part 12: Multiple Inheritance http://www.altdevblogaday.com/2013/05/22/cc-low-level-curric...
Does anyone know similar blog entries, articles or tutorial?
Nicolás Brailovsky did a great exploration in to the internals of one modern implementation of structured C++ exception handling:
http://monoinfinito.wordpress.com/series/exception-handling-...
He went so far as to reimplement his own handlers, which is totally awesome.
For other important things, like the memory layout of the inheritance graph (generally optimal for single, non-virtual inheritance), virtual table layouts, the structure of member pointers and RTTI, the Itanium C++ ABI (followed by GCC and Clang on open OS's but not MS) is a good place to glean some insight:
http://refspecs.linuxbase.org/cxxabi-1.83.html
For instance, you may be surprised to learn that member pointers aren't even pointers in this implementation, but a pair of offsets (one for the object, one for the vtable) used to find the function to call.
http://monoinfinito.wordpress.com/series/exception-handling-...
He went so far as to reimplement his own handlers, which is totally awesome.
For other important things, like the memory layout of the inheritance graph (generally optimal for single, non-virtual inheritance), virtual table layouts, the structure of member pointers and RTTI, the Itanium C++ ABI (followed by GCC and Clang on open OS's but not MS) is a good place to glean some insight:
http://refspecs.linuxbase.org/cxxabi-1.83.html
For instance, you may be surprised to learn that member pointers aren't even pointers in this implementation, but a pair of offsets (one for the object, one for the vtable) used to find the function to call.
I have written on some low level stuff on C and C++
C++ object model described with c code: http://www.avabodh.com/cxxin/cxx.html
How c code is translated to assembly: http://www.avabodh.com/cin/cin.html
C++ object model described with c code: http://www.avabodh.com/cxxin/cxx.html
How c code is translated to assembly: http://www.avabodh.com/cin/cin.html
[deleted]
The author uses Visual Studio. Hm, he doesn't use gcc ?
Doesn't matter.. Even if he would, most low level stuff would be almost equal (like the assembly generated) or at least very similar. Yes both are different compilers and do some things different (vtables/stack layout for instance if I remember correctly), but in the end if you know how the assembly generated from one works you'll have no problem understanding the other one. Besides, the screenshots from VS's mixed source/asm debugging do look nice and are really clear and helpfu for beginners.
> Besides, the screenshots from VS's mixed source/asm debugging do look nice and are really clear and helpfu for beginners.
gdb can print the same sort of thing using disas/m. Here's an example: http://i.imgur.com/toKq8pd.png
gdb can print the same sort of thing using disas/m. Here's an example: http://i.imgur.com/toKq8pd.png
He's a game developer. MSVC++ compiler and Visual Studio are (almost) a gaming industry standard.
I was interested in this until it became obvious it was going to be very games programming centric. That's too niche to be useful to me.
It's not specific to game programming. The points the author makes are valid for C++ used in any domain. The author just keeps saying that it's for game programming though the knowledge of reading the diassembly is quite useful for most developers who program with C or C++.
And for everyone like you, who does not fit into that niche, there is likely a person like me, who needs deeper information in that niche :) This looks like it will be very useful for people who are in that niche, even if it starts out simple. I'm (and I'm sure many others are) glad this was put on the front page and am looking forward to the other posts, hoping to broaden my knowledge of game development/C++.
Don't be so negative about things that seem like they aren't useful to you. Sometimes things like this are useful to many others.
Don't be so negative about things that seem like they aren't useful to you. Sometimes things like this are useful to many others.
My issue is that the title of the article suggests it's much more general in scope than it actually is.
"And for everyone like you,... there is likely a person like me" - That would mean the article is applicable to 50% of C++ developers, which is not a niche. I'd say your estimation is way off.
"And for everyone like you,... there is likely a person like me" - That would mean the article is applicable to 50% of C++ developers, which is not a niche. I'd say your estimation is way off.
These articles aren't games-specific at all. They're pretty general. What made you think they wore games-specific?
These blogs are not in any way game programming specific. They are just about the low level mechanical underpinnings of C/C++, using win32 examples because that's what most people have access to.
Fabulous articles, thanks for writing them, and thanks for stopping by. Do you have any more articles posted anywhere? I found a couple extremely bleak starts at blogs (hope that was a temporary condition), but nothing else technical. If so, please post. If not, please get to writing them!
The assembly sample he is showing has nothing to do with games but in fact is as generic as it can get and is, at least if you have never seen assembly before, a pretty good way of explaining what it is and how it works.