Graphviz doesn’t seem to set any particular version of the C or C++ standards when compiling, with the exception of an optional C++11 if you are using QT5. Should we pick a standard and make it explicit?
In the past this might have been controversial, but I would think it’s safe to assume every supported platform has a toolchain with full support for at least C99 and C++11. This would allow some code simplification as well as more readable styles for new code.
I’ve picked C99 and C++11 because it seems like those are the most impactful for Graphviz. For C, we could go further to C11 but I’m not aware of any changes there that would be relevant to Graphviz. Similarly, I’m not aware of anything in C++14 or C++17 that would be a game changer for Graphviz.
I have a very limited understanding of autotools, so if we decide we want to do this I’d need some help with it.
Documenting the minimum version sounds like a good idea to me. I don’t have a strong opinion on whether that should be C99 or C++11. There are some particularly simplifying memory-management features in C++11 (unique_ptr, shared_ptr) but it looks like all the code I can find is C, not C++? I agree that C++14 doesn’t add much over C++11.
There are probably some old platforms without new C compilers, but they must be getting far rarer now with the constant need to patch & upgrade systems against security threats.
The C and C++ standards we would choose would be independent of one another. So we would choose between C89, C90, C99, C11 and C18, and then between C++98, C++03, C++11, C++14 and C++17. There is some C++ in the Graphviz tree, e.g. lib/vpsc/.
Some opinionated thoughts… The main win of going to C99 would be mixing variable declarations and code, i.e. not having to declare all variables at the start of a function. I don’t think it’s worth refactoring existing code for this, but we could at least write new code this way. IME having a variable declaration closer to where it is used significantly decreases the likelihood of bugs. The main win of going to C++11 would be, as you said, smart pointers and thus not having to do manual memory management. Range-based for loops are also a nice syntactic win that reduces the visual noise around iterating over a collection.
I would guess the oldest environments we need to support are some *nix (Windows and macOS seem to discourage running ancient toolchains). C++11 support is feature complete as of GCC 4.8.1 and it looks like all the features we would use are supported as of GCC 4.6. C99 support is feature complete as of GCC 4.5. Do you think it’s reasonable to set a baseline requirement of GCC 4.6?
Thanks for the reply, John. Seems fine to push this until the end of the year. Looks like we also test on CentOS-6, so presumably CI would have flagged this too.