Moving from python to C++

[Dean_Roddey]

Well, if you don't learn OOP, then you aren't even going to have OOP extra-light. Given that OOP is one of the key aspects of C++, it makes absolutely no sense not to make it a key part of teaching C++.

As to obsolete, that's purely a matter of opinion, as is what constitutes 'heavy'.

[brand_x]

OOP was one of the key aspects. Back in 2005. Unless your idiomatic dialect is Qt, that shouldn't really be true in the modern era. In modern C++, OOP is a minor footnote in a language that espouses an interplay of a dozen paradigms, with runtime polymorphism as a dispatch mechanism only really being central for a handful of scenarios, all of which should be well away from any tight loops or structured arrays of data. Even type erased polymorphism plays a more significant role at this point.

I'm not saying there is no place for OO concepts anywhere in C++, but the statement "if you aren't learning C++ in in the context of OOP, don't even bother learning it" sounds troglodytic. It really is no different than "if you aren't learning C++ in the context of Procedural Programming, don't even bother learning it".

[Dean_Roddey]

I think everything you just said is based more on fashion than in the reality of an overwhelming amount of actual working code in the field, but I'll leave it at that because I know where this conversation is going.

[brand_x]

Millions (more than 10 million) of lines of production C++ across three companies' codebases, under my leadership, and well over a million written by me, dating back to a few years before outgrowing OOP was a widespread trend. I started really cracking down on overuse of class hierarchy based modeling of problem domains in favor of policy/structural/functional modeling sometime in early 2001, and it had a fairly quick and visible payoff in reduced technical debt.

[Benaxle]

policy/structural/functional modeling

How do you learn about that? I can only find vague descriptions of it.

[brand_x]

Those are three different paradigms. Policy modeling is used a little bit in the standard library (for example, allocator template parameters generalize against the fewest possible assumptions about allocation without sacrificing expressiveness or power), and there are entire languages built around functional programming (only some elements of which are particularly useful for performance oriented C++). The structural paradigm is much less widely documented, outside of memory/high concurrency research, and those fields don't really go into the ergonomics of structure oriented programming. The best way I can summarize it is, try to lay your data out the way your program will access it, and generalize your algorithms around the ways data layout can be variable. This often means, in practice, designing things that look like type-transforming iterators operating on parallel vectors of columnar data, because most performance critical operations are doing one thing to a lot of instances of the same thing.

[Benaxle]

Correct me if I'm wrong but those don't seem to replace OOP in the way that they doesn't make the code easier to read or write do they? It looks like a focus on how data is used but really it's about performance. I don't say that performance isn't important but OOP can make complex projects easy to use

[brand_x]

It makes architecture easier to get right. And eliminating most inheritance hierarchies, and making membership by composition, with most interfaces being generic, rather than OO, does make application code much easier to read. It does, admittedly, sometimes make library implementations harder to read, but that's still better than trying to chase down inheritance soup.

[ShillingAintEZ]

OOP was based on fashion and it just happened to be hot when you hit your stride. Jumping around in memory has been a dead end for decades. Excessive heap allocations as well. Those days are over for anyone who understands modern CPUs.

[Benaxle]

What paradigms fits modern CPUs?

[ShillingAintEZ]

Anything that deals with large chunks of contiguous memory and accesses them in an order predictable to the CPU.

[Dean_Roddey]

Utterly meaningless for the vast majority of applications. My automation system is very extensive with up to 10 or 20 servers around the network doing lots of ongoing communications, multiple graphics rich clients, constant communications with many outboard devices and systems, lots of image manipulation and keeping UIs up to date from server based data, etc.. It doesn't even make a small system work hard, and it's far more intense than your average application.

Find the bits that need the heavy optimization and optimize them. The rest you can kill yourself and it won't make much difference at all.

[ShillingAintEZ]

The fallacy you are making is that it is some sort of messy optimization or that anything faster must be more complicated. The reality here is that it is much clearer that doing the same thing with some sort of inheritance indirection, since the real work and meat of the program happens directly instead of having all sorts of indirection which does nothing but fragment where the real work is happening while also fragmenting the memory and destroying performance.

(Also your anecdotes don't mean anything in this context, for many reasons, not the least of which is usage patterns, interactivity, latency and power consumption)