sorry title was a bit wrong. The true question is the Version we should
target.
The issue is the point where i noticed the question.
Am 11.08.2026 um 07:58 schrieb [email protected]:
Hi Jim, all,
I switched a bit the target, and try to do a minimal change raise to
Win 10 with modern compilers.
As cheap as possible.
I found following issue:
*An override may not make a weaker promise about throwing than the
thing it overrides* — because a caller holding a base pointer was told
"this never throws" and may rely on it.
Your instinct was close. The adjustment: it's not that the destructor
must be /valid/ at every level, it's that the *promise must not get
weaker as you go down the chain*.
What changed in C++11 isn't the rule — it's *who makes the promise*.
Under C++03, a destructor with nothing written on it had no promise,
so nothing could conflict. From C++11 on, the compiler fills one in,
and a class with nothing throwing inside silently gets /"never
throws"/. At a class inheriting from both a pre-UNO base and a UNO
base, three promises meet and only one was typed by a human — and the
compiler's deduced promise for the derived class is weaker than the
compiler's deduced promise for the legacy base. It fails in a class
where nobody wrote a destructor at all.
None of these destructors actually throws. It's a paperwork conflict,
and the fix emits identical machine code.
here is an abstract code example:
struct Legacy { virtual ~Legacy(); }; // no spec written
struct Uno { virtual ~Uno() throw(RuntimeException); };
struct Both : Legacy, Uno { }; // no destructor at all
The situation on windows:
ompiler / mode |SAL_THROW|expands to The destructor
conflict Forward declaration
VC9 (C++03) |throw(exc)| /doesn't exist/— no implicit
promises accepted
MSVC 14.29|/std:c++14| |throw(exc)| *error C2694* accepted,
silently
clang, Windows/MSVC target, c++14 |throw(exc)| *warning*
*warning*
…same, with|-Werror|on that flag
error error
clang, Windows/MSVC target, c++17 |throw(exc)| — *error:
dynamic exception specifications not allowed*
clang, MinGW target *nothing* /doesn't exist/— no specs at
all unused
I forgot what is the floor we have on Apple side.
For the existing issue i found a solution, to declare the runtime.
Which is cheap solution that makes AOO build. But Since i work with
C++14 I might miss some language error we might run into.
does it make sense to change the code to the highest floor Version we
need?
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]