Portable way to disable RTTI and exceptions

Variables like CMAKE_VISIBILITY_INLINES_HIDDEN and CMAKE_POSITION_INDEPENDENT_CODE exist to add specific compiler flags in a portable way. Shouldn't exceptions and rtti be similarly treated ? adding GR- and fno-exceptions/fno-rtti flags isn't too difficult, but certainly not convenient.

added triage:feature label

Cc: @craig.scott @ChrisTX

Actually, in the boost cmake modules, we provide properties for that, see here. Of course, builtin cmake support would be better.

I don't have much experience with using either in production, but a few thoughts on this:

1. Not all compilers handle disabling RTTI the same way. MSVC doesn't permit any dynamic_cast usage with /GR-, but GCC and other compilers on POSIX platforms allow special cases like casting to an unambiguous base or to void*.

2. Not all compilers support disabling RTTI/exceptions. Oracle Developer Studio (known to us as SunPro) does not support either.

3. Disabling exceptions doesn't necessarily mean much. For GCC, you need to recompile libstdc++ for this to even make sense. You can't reasonably use a standard libstdc++ that was not compiled with -fno-exceptions together with -fno-exceptions code. Both are needed for this to work together. For MSVC, you can define the undocumented macro _HAS_EXCEPTIONS to 0. Otherwise, all STL functions or objects that might throw will burn. And on top of that, it doesn't even disable exceptions if you don't use /EHsc, but rather uses a very weird model, see here.

At the end of the day, I think disabling RTTI and/or exceptions is a headache that only has the advantage of slightly reducing code size. If there's a way to cast either option in a portable, consistent switch, that would be fine to add - but I'm somewhat doubtful.

So there are a lot of developers out there who do disable exceptions especially for realtime-critical code. We probably don't need to argue this point here, as there are recent proposals to change the language in a significant way to improve exceptions for these users ( see P0709 by Herb Sutter )

The question is if CMake can make it more convenient and portable. Half broken macros are the norm today: https://github.com/search?q=%22-fno-exceptions%22+language%3Acmake&type=Code

@kaidokert I didn't mean to say disabling exceptions isn't a thing taking place in practice. But, I'd claim that most users who do this are expecting GCC-like -fno-exceptions semantics. The core problem is and stays that disabling exceptions also disables standard C++ and how this translates to a given environment is difficult to say. Most likely, for all compilers that emulate GCC, the effects would be similar - but CMake tries to be compiler agnostic, and trying to summarize non-standardized behavior in various implementations in a single flag is... difficult. In fact, the P0709 proposal you mentioned is about this exactly: It tries to define a standard behavior with exceptions disabled (similar work is underway for RTTI), but we don't have that yet.

I'm not saying it can't be done or that the non-deterministic behavior of exceptions isn't a problem in some scenarios (realtime applications can't use them because of this) but I'm not seeing how it could be implemented in a meaningful way into CMake. The penultimate sentence in my previous post was merely regarding what I personally think about this trend of disabling exceptions just because "Google does it", nothing else. It's a trend that's taking place and if we could support it, it's a valuable feature, but it makes little sense to add a property that doesn't make this compiler agnostic.

mentioned in issue #19084

Please let me know what you think about !4634 (closed).

This looks perfect ! So this will be controllable per target with CXX_EXCEPTIONS and CXX_RTTI props, exactly as desired.

mentioned in merge request !4634 (closed)