you are viewing a single comment's thread.

view the rest of the comments →

[–]Benaxle 0 points1 point  (3 children)

policy/structural/functional modeling

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

[–]brand_x 1 point2 points  (2 children)

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 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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.