Many of us flounder from time to time when making an analogy.
Many of us flounder from time to time when making an analogy.
Good cod, this isn't the plaice to make mistakes.
Holy mackerel!Originally Posted by Hobbit
I don't see how :/
Oh, like what happens when you try to access element 5 in an array with only three elements.
I know what a processor is; I don't know how you came to think I didn't :/
What can I do?
This is a programming site, not an English site.
I have neither the time, inclination, nor skill to hold your hand and walk you through the sentences.
Try google-translating it into your native language (though that will probably make it worse).
Tesp the quote basically says the times you need to worry about saving every byte you can are few and far between. You shouldn't worry about it especially whilst learning C++. By the time you need to do it, if that ever occurs, you will know how to comfortably.
Are you familiar with the structure of a processor? And how processors fetch data from memory? The read/modify/write cycle?
If not you should certainly increase your knowledge in this area, especially as C++ allows you to inline assembly language in your code which can sometimes be helpful especially if you ever come to write game engines.
Undefined behaviour is simply that. It is something the rules of the language allow syntactically but isn't defined by the C++ standard so anything could happen, all bets are off. You should keep your code so that behaviour is defined, so that you know exactly what it will do.
Understood about the processors and behavior definedment, HobbitI'm not familiar with how processors work (not much beyond them being computers' brains, anyway), but I'll look into them.
Well, you don't need to know how a processor works in detail unless you're doing some significant super duper low-level optimizations. More often than not (in my opinion), it's most worthwhile to understand that fetching RAM can be slow compared to a processor's native clock speed and what things like cache coherency are.
Node.js took the world by storm because the web isn't compute-heavy because more often than not, you're bottlenecked by the speed of your HDD. This means that in all reality, one compute thread really can handle most of the load.
Granted, I don't think most people who do Node understand this detail because the marketing surrounding it was brilliant but this is the logical explanation for why Node is "good" and is what also makes it "bad" in certain contexts.
A beginner isn't trying to write game engines, are they now? This stuff is absolutely not necessary to know for beginners. This is an advanced topic that dives into computer architecture, an entirely different area of knowledge. Avoid focusing on this area until you have a good understanding of the language and are thinking of moving into areas where optimization is absolutely necessary. This stuff isn't easy.
Nobody is suggesting learning to program in assembly language, just the general principles of how a processor works, and how memory is read and written. It's fundamental knowledge for any programmer of a reasonably low level general purpose language such as C or C++.
No, it's not
It depends on your field.
Last edited by Elysia; 12-21-2016 at 01:17 PM.
Well, it depends.No, it's not.
Things that I've found are useful are knowing that every time you malloc, you're asking the kernel for a region of memory. This can become problematic in multithreaded code where you have many malloc calls. This place helped me write genuinely faster multithreaded code exactly because I learned about how to manage my own memory and take that burden off of the kernel.
It's also important to know why cache coherency can yield faster code, here the reason being that a RAM fetch is typically on the order of hundreds of CPU cycles for a GHz processors so your CPU will idle or maybe something else will be scheduled and then you have this other mess with other threads running and waiting for yours to be scheduled once again.
It's more about writing code that's friendlier towards your OS than your hardware, imo. But it is somewhat necessary to understand the basics like this.
I don't deny that understanding hardware makes you able to write faster programs. But my point is, unless it's necessary to do so, you don't need to optimize for the hardware. Doing so creates more complicated code that's harder to read, debug and understand.
So if you're just writing scripts or having fun or if your program is so fast performance doesn't matter, knowing these things is just a waste of time. C++ is a general purpose language. It can run in many contexts, so some contexts don't require this type of knowledge, and some do.
The basics you ought to understand are stuff like what a register is, what the stack pointer is, how stack memory works and why it's different to the heap. You absolutely must understand the RMW cycle before getting into multithreaded code especially now that there's atomic classes and thread classes. You can get by not understanding how to program for specific processors, but you should have a general knowledge of how processors work.
I completely fail to understand why one ought to understand this one. Good for optimization, but most people don't need to do these advanced optimizations.
Same here.what the stack pointer is
It is true that as a C++ dev, you need to know the difference between the stack and heap, but beyond that, you don't need to know more.how stack memory works and why it's different to the heap
Multi-threading with data sharing is an advanced topic, so that requires you to specialize in the area, so to speak. But it's not a topic everyone needs to know.You absolutely must understand the RMW cycle before getting into multithreaded code especially now that there's atomic classes and thread classes
Not necessary....but you should have a general knowledge of how processors work.
And just as a disclaimer: I am claiming this is not necessary basics for every C++ programmer. People who work in specific fields or do advanced stuff like game engines or threading needs to know more than just the basics. Those people need to know this stuff, but they are not every C++ dev.
