C++ 14 as Standard

[LeStarch]

We are considering moving our C++ standard from C++11 to C++14. The reason for this change is that C++14 fixes many issues with C++11, and the old compiler hold-outs that did not work with C++14 have been upgraded.

Please let us know your thoughts, and if you foresee any issues.

Note: at this time we are not considering an upgrade past C++14, but projects always have the power to set the standard for their code.

[mprather]

I recommend moving directly to C++17 rather than stopping at C++14. Two perspectives drive this recommendation:

First, from my observation, most projects and libraries moved from C++11 to C++17 instead of C++14. While C++14 offered incremental fixes, C++17 delivers a far greater payoff: richer functionality, more powerful constexpr, standardized utilities like std::optional and std::variant, and a stable foundation that will remain relevant for years.

Second, F´'s baseline decisions have a significant impact on third-party libraries. Our team has worked with JPL extensively, and for years we've had to constrain our software to C++11 or earlier to remain compatible across projects. In one case, we spent nearly a year maintaining a modified version of our libraries for a project that relied on an older F´ release tied to the C99 baseline and gcc 4.8.1 - just three patches shy of full C++11 support. Those missing patches forced extensive rework to keep our code aligned with F´ in 2019. While the rework technically met the C99 spec, it represented a step backward and underscored how much F´'s language baseline shapes the broader ecosystem.

When F´ later adopted C++11, it was really nice to see the upward lift (rising tide raises all boats). Coupled with F´'s growing footprint across more projects, the change had an even greater impact. I cannot overstate how nice it was to join a new project that declared it would use F` v3.5 and immediately know we met the compiler requirement.

In parallel, our team has been evaluating when to upgrade to a more capable language standard. For a couple of years now, our discussions have focused on when we would upgrade to 17 from 11. We've never considered 14 because the delta was too small to justify the disruption and the risk of alienating our existing customers was too high. However, we have strongly considered moving to 17. This change would allow us to eliminate C++11-era workarounds, give us a ton more constexpr functionality, and bring us within a decade of the current language version.

Here's the catch: while it's often said that projects can set their own standard, in practice they inherit the minimum set by F´. If F´ holds at C++14 while we move to C++17, projects that depend on both F´ and our libraries lose that choice entirely. Worse, we're eliminated from the discussion altogether. This is our conundrum and one that we fully acknowledge; however, it highlights how the framework's decision impacts projects that depend on third-party libraries.

The long-term benefits - stronger language features and alignment with the broader ecosystem - make C++17 the more strategic choice. We'd be excited to see F´ take that step, helping all teams move forward together. At the very least, I'd encourage putting a move to C++17 on the roadmap so teams can plan ahead with confidence.

[LeStarch]

We've done the upgrade in devel to C++14 since this is a step in the right direction. We can definitely take an action to look into C++17. Our biggest drawback is that historically certain compilers used in certain parts of the community don't support these newer C++ versions, which can cause problems.

Would you elaborate on "Here's the catch: while it's often said that projects can set their own standard, in practice they inherit the minimum set by F´"? My expectation was that this should work cleanly, but since it does not I'd like to understand and try to address it.

[mprather]

You're correct that F´ projects can adopt a newer language specification. In practice, though, most teams will align their language level with the framework's. This is true whether or not the framework is F´, cFS, ROS1, ROS2 or something else.

"Whatever F´ sets as their standard, that's what we're using" was a requirement I heard most recently. This reflects a specific project decision; nonetheless, it's a strategy that most projects follow. Teams generally prefer to inherit the compiler version rather than reconfigure language levels. Adjusting framework configurations is rarely trivial. It can introduce unexpected bugs and effectively force teams into validating the framework itself. That type of uncertainty is too risky and costly; thus, the answer is to pin the language level to the framework.