fix virtual specifiers, remove redundant methods, unclutter

[m-fila]

BEGINRELEASENOTES

• fixed virtual specifiers, removed redundant methods, uncluttered code

ENDRELEASENOTES

This is an attempt to slightly reduce the amount of dated and obsolete code:

• missing or redundant virtual, override, final specifiers
• redundant declarations of trivial virtual destruction when base method already has virtual destructor,
• removed redundant empty destructors
• use empty() methods instead of comparison for vector and string
• use make smart pointer instead of reset(new
• use auto instead of repeating a type or type long iterator types

[tmadlener]

Looks like this was necessary ;)

I have two general-ish comments / questions

• 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.
• We seem to have an arbitrary mix of override and final in our algorithms and classes. I think all algorithms could probably be final (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 everything final(?). This doesn't matter too much with functional algorithms, so I am not sure whether it's worth the effort in the end.

[m-fila]

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 and final in our algorithms and classes. I think all algorithms could probably be final (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 everything final(?). 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?

[tmadlener]

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.

[jmcarcell]

Anything left here or can we merge this @m-fila?

[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

[jmcarcell]

I agree with algorithms being final, for services we should check if no one has derived another service from any of them.