Back to General and Gameplay Programming

Cost of Abstraction

Torsten · 2017-04-05T10:03:23

I found a forum post about someone wanting to easy iterating over a range of numbers -> normal for loops are too heavy, too error prune... The answer from one guy was very interesting, so i want to share that with you: This is the code he put up there: namespace util { class range { public: class iterator { friend class range; public: long int operator *() const { return i_; } const iterator &operator ++() { ++i_; return *this; } iterator operator ++(int) { iterator copy(*this); ++i_; return copy; } bool operator ==(const iterator &other) const { return i_ == other.i_; } bool operator !=(const iterator &other) const { return i_ != other.i_; } protected: iterator(long int start) : i_(start) { } private: unsigned long i_; }; iterator begin() const { return begin_; } iterator end() const { return end_; } range(long int begin, long int end) : begin_(begin), end_(end) { } private: iterator begin_; iterator end_; }; }; So that you can easiely iterate over a range of numbers with a crap api: auto range = util::range(firstIndex, lastIndex + 1); for (auto i : range) { std::cout << i << std::endl; } I have no words for this, just compare it with a simple for loop doing the same thing. Without any compiler optimization, its ridiculous how much instructions you pay for abstraction like this. Crap like this is the reason why almost every software on this planet is slow - especially the web! This is just a simple for loop, imaging that more complex stuff are build like this... What do you think?

General and Gameplay Programming Programming

Started by Finalspace March 29, 2017 11:27 AM

39 comments, last by Finalspace 7 years ago

penguinbyebye

379

March 30, 2017 08:43 PM

I get, abstraction is to make programmers' life easier, but to go to the point that you need to abstract a for loop?

But that is not at all what ranges are about. Also note that the loop in the code example is not really an abstraction. Well... it is, like every for loop, like the entire language... but the point is, this is really just a combination of standard language features (auto and range-based for), and a good one.

Yes, I know he wasn't talking about abstracting the 'for' loop per se.

As for all other advantages you mentioned (which I don't know why people see a critique as a reason to start a flame war of C-ish vs C++ style), you can also achieve using a 'while' loop. I never mentioned that one should not use a class in a loop. My critique was regarding the first post, as I emphatized more than once, as the user (of other forum) stated that using a class is 1) lighter and 2) less error prone than 'normal' loops:

normal for loops are too heavy, too error prune...

It's FINE to use a class, what is not fine is to teach beginners that using classes are magic solutions that will solve all your problems (anti-pattern). Not just that, but if the implementation of the class is somehow wrong, it just makes much more difficult to track a bug (contrary of what you said in your last paragraph), because it's less obvious if the problem is with the iterator implementation or the code running outside/inside the loop. And I think @Hodgman explained very well the reason I mean:

And sure that's smaller, cleaner, simpler... but I do actually believe that this smaller version is harder to fully understand than the first version because it's moved the actual mechanism elsewhere. When doing this kind of work, I prefer the concrete bitwise details to be front of mind, not obfuscated.

And don't relie on -O3 (good luck if you do). Not just it is a source of grotesque bugs, reordering and jumping operations, as it will make even harder to track those bugs. Linux kernel has often reported bugs that were introduced in the modules when compiling the using optimization.

Finalspace

1,222

Author

March 31, 2017 09:16 AM

The more important cost of abstraction is not the run-time performance, but the dependency of the loop on the external iterator definition, and the cost of the very opaque code.

Looking at the for loop itself there is a deeper mapping going on from C++ to assembly. This is a real problem not for performance, but for readability at-a-glance. I'm sure a smart compiler dev will figure out how to compile away all of the template cruft and whatnot. However, that does not mean a programmer should have to mentally compile away all the cruft as well!

The point of using C++ should be to write performant code that can be mentally translated to assembly without much trouble. The moment C++ starts looking like a higher level language it means users reading the code are suddenly faced with opaque abstractions that are hard to reason about on a low-level.

I see this problem in all companies I have ever worked for that use "modern C++" in their codebases. They all have had very hard to track down heap corruption, or have had lots of spontaneous behavior that is difficult to track down. It's hard to track down because it's hard to figure out what the machine is doing when looking at modern C++.

This applies to high-level languages like c#, java, javascript etc. as well, because i see this every day in my daily job (Working since 15 years in business software stuff).

They write tons of hard-to-understand abstracted code just for the sake of it or to hide the actual thing they are doing.

High level programmers dont care about performance, memory or how the cpu handles it.

I use abstraction only when it makes sense and helps me actually solving my problem in a better way.

My youtube channel: https://www.youtube.com/user/F1nalspace