4 ms·

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 c

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 4y ago
> 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 4y ago
  I don't agree. The support for static polymorphism is in it's infancy at best.
  - jandrewrogers 4y ago
    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 4y ago
      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 4y ago
        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.
        strictfp 4y ago
        > The use of virtual methods is verboten for many common use cases of C++, due to the necessity of being in paged memory I wasn't aware of this. Maybe I'm just out of the loop. Do you know where one can I learn more about this? I'm desperately trying to reduce the number of virtual calls in our codebase, but I'm hitting the aforementioned problems.
        jandrewrogers 4y ago
        It is a design problem endemic to database engines and probably file systems. A design requirement for most of the dynamic runtime data structures is that they can be directly paged to storage, either in whole or in part, and be paged from storage in an arbitrarily distant future on different machines with different compilers. In order to make this work, all data types used in pageable data structures must 1) have a size and alignment that is not compiler-dependent so that page types always have a size that is a strict multiple of the I/O page size and 2) not contain any pointers. This precludes vtables. This has traditionally been managed with CRTP, tagged unions, etc with some scaffolding to make it convenient and compliant with strict aliasing rules. Ideally, almost all of the dynamic polymorphism is pulled up to the level of the page types, an opaque blob of I/O friendly complex data structure, minimizing the amount you have to do. It is also important to note that JIT-ing has replaced many of the use cases for dynamic dispatch e.g. adding user-defined schemas at runtime. None of which may apply to your use case. Some things inherently require an unfortunate amount of dynamic dispatch.
        4y ago
leni536 4y ago
Sometimes (definitely not always) you can use std::function instead for dynamic polymorphism.
ryl00 4y ago
> Creating trees or graphs can be cumbersome Wouldn't Rust have the same problem with this (if not worse)?
- jhgb 4y ago
  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.
jhgb 4y ago
> 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 4y ago
  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 4y ago
    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.

jandrewrogers 4y ago

> 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 4y ago
I don't agree. The support for static polymorphism is in it's infancy at best.
- jandrewrogers 4y ago
  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 4y ago
    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 4y ago
      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.
      - strictfp 4y ago
        > The use of virtual methods is verboten for many common use cases of C++, due to the necessity of being in paged memory I wasn't aware of this. Maybe I'm just out of the loop. Do you know where one can I learn more about this? I'm desperately trying to reduce the number of virtual calls in our codebase, but I'm hitting the aforementioned problems.
        jandrewrogers 4y ago
        It is a design problem endemic to database engines and probably file systems. A design requirement for most of the dynamic runtime data structures is that they can be directly paged to storage, either in whole or in part, and be paged from storage in an arbitrarily distant future on different machines with different compilers. In order to make this work, all data types used in pageable data structures must 1) have a size and alignment that is not compiler-dependent so that page types always have a size that is a strict multiple of the I/O page size and 2) not contain any pointers. This precludes vtables. This has traditionally been managed with CRTP, tagged unions, etc with some scaffolding to make it convenient and compliant with strict aliasing rules. Ideally, almost all of the dynamic polymorphism is pulled up to the level of the page types, an opaque blob of I/O friendly complex data structure, minimizing the amount you have to do. It is also important to note that JIT-ing has replaced many of the use cases for dynamic dispatch e.g. adding user-defined schemas at runtime. None of which may apply to your use case. Some things inherently require an unfortunate amount of dynamic dispatch.
        4y ago

leni536 4y ago

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

ryl00 4y ago

> Creating trees or graphs can be cumbersome Wouldn't Rust have the same problem with this (if not worse)?

jhgb 4y ago
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.

jhgb 4y ago

> 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 4y ago
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 4y ago
  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.