4 ms·
You should use final to express design intent. In fact I’d rather it were the default in C++, and there was some sort of an opposite (‘derivable’?) keyword inst
by ein0p 3y ago
You should use final to express design intent. In fact I’d rather it were the default in C++, and there was some sort of an opposite (‘derivable’?) keyword instead, but that ship has sailed long time ago. Any measurable negative perf impact should be filed as a bug and fixed.
- deleted 3y ago[deleted]
- cesarb 3y ago> In fact I’d rather it were the default in C++, and there was some sort of an opposite (‘derivable’?) keyword instead Kotlin (which uses the equivalent of the Java "final" keyword by default) uses the "open" keyword for that purpose.
- josefx 3y agoIntent is nice and all that, but I would like a "nonwithstanding" keyword instead that just lets me bypass that kind of "intent" without having to copy paste the entire implementation just to remove a pointless keyword or make a destructor public when I need it.
- jbverschoor 3y agoIn general, I think things should be strict by default. Way easier to optimize and less error prone.
- leni536 3y agoC++ doesn't have the fragile base problem, as members aren't virtual my default. The only concern with unintended inheritance is with polymorhpic deletion. "final" on class definition disables some tricks thag you can do with private inheritance. Having said that "final" on member functions is great, and I like to see that instead of "override".
- pjmlp 3y agoAll OOP languages have it, the issue is related to changing the behaviour of the base class, and the change introducing unforceen consequences on the inheritance tree. Changing an existing method way of calling (regular, virtual, static), changing visibility, overloading, introducing a name that clashes downstream, introducing a virtual destructor, making a data member non-copyable,...
- leni536 3y ago> All OOP languages have it, the issue is related to changing the behaviour of the base class, and the change introducing unforceen consequences on the inheritance tree. C++ largely solves it by having tight encapsulation. As long as you don't change anything that breaks your existing interface, you should be good. And your interface is opt-in, including public members and virtual functions.
- pjmlp 3y agoNot when you change the contents of the class itself for public and protected inheritance members, which is exactly the whole issue of fragile base class. It doesn't go away just because private members exist as possible language feature.
- leni536 3y agoThat's not a fragile base, that's just a fragile class. You can break APIs for all kinds of users, including derived classes. Some APIs are aimed towards derived classes, like protected members and virtual functions, but that doesn't make the issue fundamentally different. It's just breaking APIs. Point is, in C++ you have to opt-in to make these API surfaces, they are not the default.
- pjmlp 3y agoI give up, word games to avoid acknowledging the same happens.
- jstimpfle 3y agoNow try a regular function, you will be blown away. No need to type "final"...