[jstimpfle]

Maybe I'm wrong, but I believe that most of the architecting that you describe would be effectively what you do with regards to performance as well: Minimizing change of ownership, moving to a system with more static allocations with fewer "objects" that are linked into a variety of subsystems.

[strictfp]

Yes, that's true. In a sense, c++ requires good code structuring.

That's also part of why I enjoy returning to c++, the people involved know how to structure code and create clean architecture.

That said, sometimes c++ does get in the way. Creating trees or graphs can be cumbersome, and IMO it's very biased towards virtual methods to solve polymorphism.

Extending lifetimes by pooling or similar is also quite common, and is in my eyes sometimes overdoing it. If you for instance use Rust, you can be a lot more confident that the compiler catches these issues, and be more conservative and efficient in the solution.

[jandrewrogers]

> very biased towards virtual methods

This is a function of the type of software you write. There are many large C++ code bases that rely on various types of static polymorphism almost exclusively, rarely having a use case for virtual methods or dynamic polymorphism. There is a similar story with inheritance versus composition; some types of code bases naturally gravitate toward one or the other.

The nice thing about C++ is that it as amenable to any of these models should it benefit the application.

[strictfp]

I don't agree. The support for static polymorphism is in it's infancy at best.

[jandrewrogers]

Can you give some examples of what you mean? I use static polymorphism in C++ routinely and haven't felt particularly limited by it.

[strictfp]

Sure. I guess template-based polymorphism is alright for code dispatch. But if you want to store the different types of objects involved you have limited choices. There's no straight-forward support for sum types. std::variant is fairly new, has a cumbersome API, and is quite slow (ballpark the same as virtual calls). There's no support for methods on enums nor anything for customizing the fields of different enum constants. There's also no pattern matching or other really convenient way of deconstructing variants.

So while it's there, I would say that the oo virtual method style is much better supported, although storage for those usually requires some type heap allocation.

[jandrewrogers]

Okay, yeah, I would broadly agree with this. I think most people use template-based polymorphism, which is pretty flexible in practice. The use of virtual methods is verboten for many common use cases of C++, due to the necessity of being in paged memory, so constructions for dealing with polymorphism without virtual methods are commonplace. And std::variant is a bit of a hot mess.

[riking]

"hmm, you call it an 'enum class' yet somehow I cannot define methods on it"

[jhgb]

> and IMO it's very biased towards virtual methods to solve polymorphism.

Is it? These days I'd expect C++ to be very biased towards using templates for polymorphism. After all, templates are a thing that C++ provides with functionality that other languages often lack, whereas in the field of virtual methods/"dynamic dispatch OOP" C++ severely lags behind other languages. Choosing between two features of a language and using exactly the one that is worse in comparison to your competition feels wrong to me.

[FpUser]

I do not think C++ "lags severely in the field of virtual methods". I use both OOP and template based polymorphism depending on particular needs and see no significant problems in either.

[jhgb]

C++ can't do things today that Smalltalk and CLOS were able to do in the 1980s already; how is it not lagging behind in OOP? Hell, companies like Trolltech had to extend C++ for their own purposes to provide just a subset of the extra features (relative to standard C++) that had already been available in environments like Smalltalk or CLOS.

[ryl00]

> Creating trees or graphs can be cumbersome

Wouldn't Rust have the same problem with this (if not worse)?

[jhgb]

I was told that deferred_ptr/deferred_heap was supposed to solve these things for C++, so perhaps that would make Rust the option with worse problems in this department. Not sure where it got by now, though.

[leni536]

Sometimes (definitely not always) you can use std::function instead for dynamic polymorphism.

[cyber_kinetist]

…and when you do need a large number of dynamically allocced/deallocced objects, then using indices to arrays instead of pointers. Which kinda defeats the purpose of using the Rust borrow checker…