Closed m-fila closed 1 week ago
Thank you
Should we explicitly
default
the empty destructors that we would otherwise remove here? It's not necessary from a c++ point of view, but it would make it very clear that nothing special is happening in this class destructor from just looking at the code.
I'd prefer to use implicit destructors when possible in the spirit of rule 0 (having = default
reads like there was a need to be explicit because the class does something not trivial with memory). But if there is a strong preference to have explicit destructors in the codebase then I can bring them back no problem
We seem to have an arbitrary mix of
override
andfinal
in our algorithms and classes. I think all algorithms could probably befinal
(especially the test and example ones). It's not very likely that something will inherit from them. For all the services a similar argument holds probably, so we could make almost everythingfinal
(?). This doesn't matter too much with functional algorithms, so I am not sure whether it's worth the effort in the end.
I was wondering if there is some conventions/deeper reason for the mix. Is there really a reason to not allow further overriding (final
doesn't have performance benefits and to me most of )? In that case maybe the classes should be final
?
I'd prefer to use implicit destructors when possible in the spirit of rule 0 (having = default reads like there was a need to be explicit because the class does something not trivial with memory). But if there is a strong preference to have explicit destructors in the codebase then I can bring them back no problem
Good point. I haven't really checked the existence of the constructors. So if we can go with rule of 0 let's go with that.
I was wondering if there is some conventions/deeper reason for the mix. Is there really a reason to not allow further overriding (
final
doesn't have performance benefits and to me most of )? In that case maybe the classes should be final?
Maybe it's time to come up with a convention and write it down into some general guidelines document.
Anything left here or can we merge this @m-fila?
It's good to go. I think we could propose a convention for final
later as no-one seems to have now a very strong opinion
I agree with algorithms being final, for services we should check if no one has derived another service from any of them.
BEGINRELEASENOTES
ENDRELEASENOTES
This is an attempt to slightly reduce the amount of dated and obsolete code:
empty()
methods instead of comparison forvector
andstring
reset(new