- Forum
- General C++ Programming
- Why C++ is supposed to be good at low-le
Why C++ is supposed to be good at low-level operations?
The question above was asked in one of my past papers I have been looking through and I have had difficulty coming up with what I think is a sufficient answer. I know that C++ has low-level features like the memory-management, pointers, exception handling and bit manipulation. But I was wondering if I am missing something as I feel that just listing these low level examples and giving a context of how they are done in C++ is not what the actual question is asking me? The "Why C++ is supposed to be good at" is what I am referring to.
Much appreciated if someone is able to shed some light for me.
Much appreciated if someone is able to shed some light for me.
it can also have inline assembler, which not all languages support.
It has direct access to the whole machine, allowing the programmer to NOT be forced to use sluggish, bloated objects if speed is required. Vectors are great, but arrays use a bit less space and are sometimes notably faster, for example. It has the amazing union, which lets you get directly to the bytes or even bits of *anything*. It has C's string functions and direct manipulations, which again are smaller and faster than string class in some circumstances.
The thing is, these "faster" and "smaller" things rarely matter. If you are running Linux and C++ on your wristwatch with 1/2 a KB of ram and a 1 hz cpu, maybe it matters. I used to work in embedded and time I stopped the embedded PCs were as powerful as a whole room full of computers were in the late 70s. The savings went from seconds to miliseconds to nanoseconds and now are sub nanosecond in many cases, making the clunky low level code something to avoid unless you really have weak hardware or a special need that requires it. And those special cases often end up being a tiny bit of code, a tight inner loop somewhere, or one or two key functions, and everything else can be modern and high level code.
And that is the beauty of C++ . It fairly seamlessly integrates the low level specialty routines into the higher level code, all in one language. This is a big deal, and moreso back in the day when mixing compiler objects was not always the most efficient final result so cross language projects had issues to work out. That problem has faded away also, for the most part.
Pointers are the door to everything. Languages without them simply cannot do some things. Pointers let you directly talk to hardware / drivers, without additional layers.
C++ also has an excellent go-to statement that tends to optimize very nicely.
I wish I had a buck for every project that starts out in design by someone saying "lets write the performance critical stuff in C or C++ and everything else in some other inefficient/bloated/crippled/messed up language".
Sometimes it worth mentioning the negatives as well. Low level code is often tied to a single hardware family, and non portable. And plenty of code suffers this, even when not low level -- when you get into hardware drivers, graphics/sound, or GUI code, c++ can be troublesome to keep portable if that even matters to the project.
It has direct access to the whole machine, allowing the programmer to NOT be forced to use sluggish, bloated objects if speed is required. Vectors are great, but arrays use a bit less space and are sometimes notably faster, for example. It has the amazing union, which lets you get directly to the bytes or even bits of *anything*. It has C's string functions and direct manipulations, which again are smaller and faster than string class in some circumstances.
The thing is, these "faster" and "smaller" things rarely matter. If you are running Linux and C++ on your wristwatch with 1/2 a KB of ram and a 1 hz cpu, maybe it matters. I used to work in embedded and time I stopped the embedded PCs were as powerful as a whole room full of computers were in the late 70s. The savings went from seconds to miliseconds to nanoseconds and now are sub nanosecond in many cases, making the clunky low level code something to avoid unless you really have weak hardware or a special need that requires it. And those special cases often end up being a tiny bit of code, a tight inner loop somewhere, or one or two key functions, and everything else can be modern and high level code.
And that is the beauty of C++ . It fairly seamlessly integrates the low level specialty routines into the higher level code, all in one language. This is a big deal, and moreso back in the day when mixing compiler objects was not always the most efficient final result so cross language projects had issues to work out. That problem has faded away also, for the most part.
Pointers are the door to everything. Languages without them simply cannot do some things. Pointers let you directly talk to hardware / drivers, without additional layers.
C++ also has an excellent go-to statement that tends to optimize very nicely.
I wish I had a buck for every project that starts out in design by someone saying "lets write the performance critical stuff in C or C++ and everything else in some other inefficient/bloated/crippled/messed up language".
Sometimes it worth mentioning the negatives as well. Low level code is often tied to a single hardware family, and non portable. And plenty of code suffers this, even when not low level -- when you get into hardware drivers, graphics/sound, or GUI code, c++ can be troublesome to keep portable if that even matters to the project.
Last edited on
C++ is good at low-level operations because one of its main design principles is "zero-overhead abstraction".
Where other languages implement the abstractions of computer science using additional indirections, repeated runtime checks, thunks/trampolines, and, more and more commonly, execution in a virtual machine, C++ produces code that executes on the actual machine and has no overhead unless explicitly requested.
The trade-off is of course that lack of runtime checks makes it possible for a program that compiles to experience runtime errors, though in modern C++ we can generally leverage the type system to guarantee that preconditions (like index is not out of bounds) are never violated.
Another relevant feature of C++ (shared with C, but not with any other language I know) is narrow contracts: lots and lots of core language operations have undefined behavior if the programmer doesn't supply the right inputs. This is extremely friendly to the optimizers: they assume the inputs are correct and transform programs in huge, sometimes surprising, ways. There's a small collection of code examples on http://en.cppreference.com/w/cpp/language/ub#UB_and_optimization showing what optimizers do to code because they assume the programmer knew what they were doing.
Where other languages implement the abstractions of computer science using additional indirections, repeated runtime checks, thunks/trampolines, and, more and more commonly, execution in a virtual machine, C++ produces code that executes on the actual machine and has no overhead unless explicitly requested.
The trade-off is of course that lack of runtime checks makes it possible for a program that compiles to experience runtime errors, though in modern C++ we can generally leverage the type system to guarantee that preconditions (like index is not out of bounds) are never violated.
Another relevant feature of C++ (shared with C, but not with any other language I know) is narrow contracts: lots and lots of core language operations have undefined behavior if the programmer doesn't supply the right inputs. This is extremely friendly to the optimizers: they assume the inputs are correct and transform programs in huge, sometimes surprising, ways. There's a small collection of code examples on http://en.cppreference.com/w/cpp/language/ub#UB_and_optimization showing what optimizers do to code because they assume the programmer knew what they were doing.
Topic archived. No new replies allowed.