On Monday 25 November 2024 03:24:02 Pacific Standard Time Volker Hilsheimer via Development wrote: > This is a debug build with VS2022, cl version 19.41.34123. The issue would > probably not happen in a release build. gcc and clang seem to cope as well.
That's because I tested gcc for my all-Qt build. Getting the compiler to work with qtopcua was not fun. At least it wasn't tst_qstringapisymmetry that just caused a massive swapping and killed my system just by using std::tuple. qtbase is the only module I ever build for anything that isn't GCC + Linux. > But if we do that kind of thing, then it’s probably a safe bet that clients > will also generate meta-object relevant types from some spec or some other > APIs (such as a COM type library or similar; hello ActiveQt, at least). Maybe, but the likelihood of a type with 16000 enumeration entries is low. Even if you look at the source for this header, it was coded in such a way the Q_NAMESPACE can be disabled, because I'm guessing other compiler limitations had happened in the past. The CMakeLists.txt for it has something too. > The issue would probably not happen in a release build It does happen. I'll disable namespace 0 for MSVC. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
