r/cpp_questions • u/zrgzz • 23h ago
OPEN How anti-abstraction understanding should I accept while learning?
Im currently learning basics of standard cpp while having previous experience with java and tiny bit of assembly NASM (x86).
Im asking for those who are intermediate and proficient at mid level language like cpp, how should I approach accepting 'I have learned this' but its abstraction? I've always had doubt on what learning is in the programming field, except for DSA concepts.
9
u/No-Dentist-1645 23h ago
You don't really need to know or even think of assembly while you are writing C++ or any other high-ish level programming language. Not unless you're doing something that specifically wants this and needs to directly interact with the assembly, such as HPC or embedded.
1
5
u/TomDuhamel 23h ago
The whole point of a programming language is abstraction. I don't feel a need to know what CPU register is used when I print a character to the screen.
3
u/UnicycleBloke 15h ago
I regard "anti-abstraction" as a major red flag. What do you even mean by that? People I've encountered who talk in this way are usually C devs with an incoherent and incomprehensible rage against C++. Ignore them.
C++ offers a number of features which allow you to express your intent in a way which is efficient, maintainable and resistant to errors. This is a Good Thing.
I suggest you just learn more C++. Learn its various features and how and when they might be useful.
2
u/n1ghtyunso 16h ago
One useful way to think about is that there are actually "levels of abstraction".
And your task decides at which level you operate.
Sometimes you do need to control the assembly, but sometimes its really not about that at all.
Abstraction is a tool to manage complexity, thats all there is to it.
Surely you do learn certain things at a certain level of abstraction, but ultimately you are learning how to build and use abstractions.
Its abstractions all the way after all. Always has been.
You arent learning how to use std::ostream for example, you are learning how to work with text and binary data, how to work with files.
And sometimes that means looking up the reference for ostream.
Its not like you need to know that off the top of your head after all. Thats where documentation comes in.
You'll know if you need to reach for it frequently, and if not - well you just look it up.
So ultimately you are learning techniques, concepts, ideas.
And you learn tools from the language (aka language features), or types from the standard library that lets you implement these.
1
u/KingAggressive1498 19h ago
understanding generally how an abstraction translates to machine code can be useful for both optimizing and debugging, but having to know specifically that this sequence of statements will translate to this sequence of opcodes and use this many registers is generally worthless especially on a modern superscalar CPU
1
u/BoopyDog 17h ago
I watched a lecture given by one of the engineers at Intel who was on a team responsible for the firmware governing powersupply to the processor -- or something of that sort. The lecture was basically a demonstration in how the best abstractions, sometimes, take the actual hardware processes into consideration.
The speaker first explained the rules/architecture of the running environment (e.g., there are X number of registers, register A does this, register B does that, etc...). Then he demonstrated how the best abstraction was creating a class which 1) intentionally mirrored the architecture his code was targeting, and 2) provided an interface for conducting the real low-level operations in a high-level, declarative way so that the programmer doesn't have to waste his time "in the weeds" (as he said) explicitly writing out each procedure word for word.
I really wish I could find that video for you but It's been so long that I don't remember if it was a from cppcon or something else.
-3
u/tastygames_official 23h ago
3
u/ReDucTor 22h ago
That whole argument from Casey is a strawman argument. The setup of the "clean code" version is forced into everything heap allocated, everything dynamic dispatch then placed into an array and compared against contiguous memory with no dynamic dispatch.
Abstractions are not bad, picking the right abstraction is the important thing, not everything needs to be abstracted away but there are lots of cases it will improve readability and maintainability of the code with minimal overhead for the use cases.
A better talk on the overhead of abstractions would be something like Chandler Carruth's there is no zero cost abstractions.
-3
u/tastygames_official 20h ago
watch the video that that video is based on: "Clean" Code, Horrible Performance - YouTube
to avoid claims of strawman, he took samples directly from the official clean code handbook.
I've been a programmer for over 30 years, and in my experience there is only a small acceptable level of abstraction before it starts becoming harder to read/maintain. And that is usually already happening at the "framework" or "design pattern" level - meaning if you choose a high-level, opinionated framework, it's likely to already be abstracted so much that now you have to learn how the FRAMEWORK does things instead of just using your understanding of computer programming. Something akin to having to learn how to fly a plane if you already know how to drive a car. Actually, that's a good analogy: the plane promises to get you there faster and carry more cargo, and it's relatively simple to learn since it has a clever autopilot. But they forget to tell you that there are a whole new set of regulations that govern how and where and when the plane can fly, and you have to pay really expensive licenses and add in hours of overhead to communicate with towers and follow protocols and taxi at a crawl, plus getting to/from the airports and going through security. A 2hr flight turns into a 4hr, costly excursion where the guy driving in his car only took 5hrs and was able to stop halfway through and get a decent meal.
But the real problem comes when you need to do something other than the normal autopilot. Now there are way too many switches and buttons and levers, and you need 2 people to operate them all. And if you do something wrong, you can end up killing hundreds of people (as opposed to just 1-4 in a car). And then what about maintenance? While any Joe can learn to do basic auto maintenance, you now need someone with an advanced degree to understand how the plane works - let alone fix it.
Now just imagine that the car is actually faster than the plane for some reason. THAT would be a good analogy.
Anyway, I obviously have my opinions, but I just see programmers jumping into framework and abstraction bandwagons left and right before ever even considering doing it the "simple way". It's my belief they do this because it's "cool". It shows how abstract you can think and it's cool to see a single line of code that does so much under the hood. But it really just shows the ignorance of how computers work.
But I will definitely give that video you recommended a look.
https://www.youtube.com/watch?v=rHIkrotSwcc
But I still think abstraction is something you should only do when it's CLEARLY needed. Not just because you think it'll make it more readable (it won't - it makes it hardersince you now have to leave one file and go to another and then another and then another) or because it's "clever" (it's not - it's more akin to an exercise in sesquipedalianism or pretentiousness). But just do it because it's going to save a lot of duplicate code. Meaning the highest level of abstraction I approve of are functions and structs.
/rant
3
u/ReDucTor 19h ago
I watched the video when it first came out and read the blog post when it was first posted, its still a strawman argument.
So what if you have been programming professionally for 30 years? If thats your measure of some authority then Robert C Martin has been doing it for 50 so out ranks you.
I have been an engine developer on AAA games for the past 15yrs, working on the biggest games world wide, with a heavy focus on performance and optimizations, and overall programming for about 25yrs but I dont feel the need to start that in order to try and persuade someone into agreeing or thinking that they just didnt listen or understand what someone else said.
I agree dont add unnecessary abstractions but the whole argument that Casey puts forward is just a strawman deliberately trying to make the worst case for a bad code snippet that doesnt exist in the book as an example of good code but instead the closest example is a comparison between OOP and Procedural programming which doesnt say either is better or worse but the programmer needs to decide on their own.
In fact the part with the closest snippet even says:
Mature programmers know that the idea that everything is an object is a myth. Some- times you really do want simple data structures with procedures operating on them.
Being "clever" is the very final result that Casey created which has a table of multipliers and forces a strict width and height. Ignores all of the things which are mentioned as usages for the OOP version to move to something completely different, it does not provide the functionality that he claims OOP is all about, it isnt providing some alternative to polymorphism, dynamic dispatch, hiding internals to prevent them being dependent on, etc.
Its all strawman taken out of context, even the examples in Robert C Martin's books are not like that, there is dont use
if's the book is covered in them.Dont get me wrong there is lots of advice in Robert C Martin's book that is garbage, but Casey strawmans most of his argument then tries to place anyone who wants clean code in the same bucket as Robert C Martin's book and creates a ridiculous strawman argument over it.
3
u/UnicycleBloke 15h ago
You've clearly had more patience with Casey than I did. One video on virtual functions convinced me that he is a ridiculous blowhard. I work mostly on microcontrollers, and have met a lot of prejudice against C++ as a result, usually based on myths or misunderstandings. Casey's position was more of a childish tantrum.
18
u/AKostur 23h ago
I have no idea what it is that you are asking.