My investigation with Linux and macOS is that C++11 has been sufficient, especially for the updated versions of the various external dependencies we pull in. The C++98->c++11 bump is a bit less then jumping all the way to 14, which may be a factor.
Still curious about the feasibility of just baselining MSYS2 which provides both a gcc-based and clang-based build environment and just using the UCRT runtime instead of the MSVCRT... does anyone have any insights? > On Aug 11, 2026, at 9:11 AM, Peter Kovacs <[email protected]> wrote: > > > > Am 11. August 2026 13:07:10 MESZ schrieb Jim Jagielski <[email protected] > <mailto:[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] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> -- Jim "This is an outrage!" Tony Harrison
