Am 11. August 2026 13:07:10 MESZ schrieb Jim Jagielski <[email protected]>:
>I've no real experience with building for Windows so these questions are based
>100% on ignorance. What about building with MSYS2 (and the UNC) or maybe WSL?
>I know that we use cygwin to drive things but my understanding is that we
>still depend on Windows specific SDKs and compilers. Would a pivot to a total
>MSYS2 build bypass all that?
Sorry, i did not write clearly.
In order out code compiles on newer compilers we might need to change code.
I am looking into compatibility of C++98 to C++14. If the compilers is newer,
it might need C++17 or newer. At least the AI claimed that other changes would
become necessary if we use an compiler that is newer.
It might be small things.
So if the compilers on Mac the lowest is C++17, It may be worth it if I do the
windows update with a newer version.
Since for my personal fun I keep C++98 compatibility for now. That would mean
AOO would be by nature able to be compiles by a bigger range of compilers.
>
>I _think_ that that would also allow us to support Win7, but again, I'm not
>exactly sure.
>
>> On Aug 11, 2026, at 1:58 AM, [email protected] wrote:
>>
>> 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
>>
>
>--
>Jim
> "This is an outrage!"
> Tony Harrison
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]