Modernize the codebase - overrides, nullptrs and redundant voids

[JanVogelsang]

This PR acts as an addition to PR #2479. No new types of changes will be introduced by this PR, only missed cases of those discussed in the prequel-PR are added. These cover the following three types of issues:

1. Using nullptr instead of NULL or 0 to initialize empty pointers or to check for an undefined pointer.
2. Removing the redundant void argument from function with empty argument lists.
3. Add missing override specifiers for overridden functions in derived classes and, if applicable, remove the redundant virtual specifier when override is set as well.

There are a few possible other changes that could be included in this PR:

4. Mark overridden functions as final in models, as those will not be overridden any further. This is based on the assumption that models won't ever be based on another model (i.e., derive from another model). The final specifier is utilized by some compilers to increase performance of the compiled code. I have not seen any benchmarks yet that show how significant the performance increase can be, but even if performance is unaltered, marking a final function as final would hurt nobody.
5. Change all occurrences of && to and as well as ! to not. We started doing this in Modernize the code base and make it more compliant to common C++ style guides #2479, and we should either do it everywhere or nowhere at all.
6. Shorten if( ptr != nullptr ) to if ( ptr ) as both behave the same for all compilers that follow the C++ standard.

[heplesser]

There are a few possible other changes that could be included in this PR:

I would advise against more complexity in this PR.

4. Mark overridden functions as final in models, as those will not be overridden any further. This is based on the assumption that models won't ever be based on another model (i.e., derive from another model). The final specifier is utilized by some compilers to increase performance of the compiled code. I have not seen any benchmarks yet that show how significant the performance increase can be, but even if performance is unaltered, marking a final function as final would hurt nobody.

I tried final with SpikeEvent, because spike-delivery is significant for runtime and includes a large number of function calls (was a bit tricky since I had to de-inherit DSSpikeEvent). I did not see any change in runtime. Given the complexity of almost all methods in models, I would not hope for much. One could give it a little try with handle(SpikeEvent&), but I would not get my hope up high.

5. Change all occurrences of && to and as well as ! to not. We started doing this in Modernize the code base and make it more compliant to common C++ style guides #2479, and we should either do it everywhere or nowhere at all.

Our policy so far has been to fix this if there are other changes to the code. I would suggest to isolate this in a separate PR if we want to do it everywhere.

6. Shorten if( ptr != nullptr ) to if ( ptr ) as both behave the same for all compilers that follow the C++ standard.

Do it in this PR where you make changes involving nullptr anyways and then a separate PR.

[JanVogelsang]

Sounds good, regarding no. 6, is there a good way of finding all occurrences of != nullptr in all lines that changed in a specific commit? Doing it by hand would be quite tedious..

[JanVogelsang]

By the way, the MacOS check fails again without any errors, probably because of some warnings. These warnings are fixed in the other PR though, so I won't fix them here again. How should I handle this?

[heplesser]

By the way, the MacOS check fails again without any errors, probably because of some warnings. These warnings are fixed in the other PR though, so I won't fix them here again. How should I handle this?

First get #2493 merged, then merge master into this PR, which should solve the problem. I would generally suggest that you build your work on the branch for #2493, so that when #2493 is merged, the change set from this PR simply becomes smaller.

[JanVogelsang]

I did already do that, actually. All changes here are completely additional to those in #2479 . I now also merged master into this and will now wait to see if all warnings are gone.

[JanVogelsang]

I addressed no. 6 in PR #2496 to keep different types of changes strictly separated. #2496 is based on the changes of this PR, we should therefore merge this PR first and then review the other one.
Both PRs should be fairly easy to review with less to discuss, as there were no special cases in both of them. The reviewing process should also be smoother now that I learned a lot from #2479.

[heplesser]

Looks got to me, thank you! In the spirit of keeping PRs orthogonal, I think it is right to leave && and || in place here even in statements that are touched.