3 ms·

> OO with class hierarchies is a broken model. If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write onl

> OO with class hierarchies is a broken model. If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs. I think C++ is not going "to go" anywhere and is here to stay for a long, long time, and have it's place in programming language "pantheon" similar to C. C++ gives programmer freedom, which is too much to handle for many. Restrictive language is a good way of preventing bugs, but in C++ you can just select what language features you are gonna use and have similar result.

qb45 13y ago
If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs. Except that abstract classes are pretty much the only way to implement type-checked interfaces and they are, well, classes.
- cbsmith 13y ago
  Not at all. You can use CRTP, you can use structs, you can use SFINAE, etc. UPDATE: And for the record, inherence of pure interface classes works just fine in C++. The stuff where it gets ugly is when you try building a deep inheritance hierarchy of behaviour. It can work, but usually not terribly well.
MaulingMonkey 13y ago
> If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs. Functions and structs is not much freedom. But you're quite right: nothing forces you to write in C++. > I think C++ is not going "to go" anywhere and is here to stay for a long, long time, and have it's place in programming language "pantheon" similar to C. Sure. Or COBOL, or any other number of languages in which massive legacy codebases have been written. At best, one avoids them in their own work. > Restrictive language is a good way of preventing bugs, but in C++ you can just select what language features you are gonna use and have similar result. Even when you whittle down the feature list far beyond what you can still reasonably expect to be even remotely productive with, simple matters like uninitialized variables can still go uncaught if your compiler can't catch every single use case and you don't wade through a slew of false positives with maximum warnings and warnings as errors. One is forced to use time-expensive static code analysis, enforced by CI build process, to begin to even remotely approach the general runtime safety of something like C#. These options are extremely useful when you're stuck with a C++ codebase, but I wouldn't describe it so casually, as if they were quick and simple to implement and enforce.

qb45 13y ago

If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs. Except that abstract classes are pretty much the only way to implement type-checked interfaces and they are, well, classes.

cbsmith 13y ago
Not at all. You can use CRTP, you can use structs, you can use SFINAE, etc. UPDATE: And for the record, inherence of pure interface classes works just fine in C++. The stuff where it gets ugly is when you try building a deep inheritance hierarchy of behaviour. It can work, but usually not terribly well.

MaulingMonkey 13y ago

> If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs. Functions and structs is not much freedom. But you're quite right: nothing forces you to write in C++. > I think C++ is not going "to go" anywhere and is here to stay for a long, long time, and have it's place in programming language "pantheon" similar to C. Sure. Or COBOL, or any other number of languages in which massive legacy codebases have been written. At best, one avoids them in their own work. > Restrictive language is a good way of preventing bugs, but in C++ you can just select what language features you are gonna use and have similar result. Even when you whittle down the feature list far beyond what you can still reasonably expect to be even remotely productive with, simple matters like uninitialized variables can still go uncaught if your compiler can't catch every single use case and you don't wade through a slew of false positives with maximum warnings and warnings as errors. One is forced to use time-expensive static code analysis, enforced by CI build process, to begin to even remotely approach the general runtime safety of something like C#. These options are extremely useful when you're stuck with a C++ codebase, but I wouldn't describe it so casually, as if they were quick and simple to implement and enforce.