FEAT: Support Qt 6.8 with C++17 #516

Activity

1. paceholder commented on Mar 9, 2026

   

   paceholder

   on Mar 9, 2026

   Last edited by paceholder

   Owner

   More actions

   Hi,

   not a proven solution, but might give you a couple of insights:

   The Core Problem
   Qt 6.8 uses C++20 features — specifically, it relies on the compiler supporting noexcept specifiers on comparison operators (like operator==) in a way that satisfies static_assert checks introduced in newer Qt versions.

   GCC 11's C++20 support is incomplete. In particular:

   Qt 6.8 internally uses macros like Q_DECLARE_EQUALITY_COMPARABLE which assume the compiler can handle noexcept on spaceship/comparison operators correctly under C++20
   GCC 11 has partial C++20 support but lacks full noexcept-on-comparison-operators compliance
   This causes the static_assert inside qmetatype.h to fire on every translation unit that includes Qt headers — hence hundreds of errors

   Solutions

   • upgrage GCC to 12 or 13
   • or use clang >=14
   • or downgrade Qt to <6.7
   • force C++17 in your CMake configs
2. JamesBloomScheff2 commented on Mar 13, 2026

   

   JamesBloomScheff2

   on Mar 13, 2026 via email

   Author

   More actions

   Hi again, Thank you for your attention in this matter. I have an additional question. All of our components compile with Qt6 without a problem. We are only having this problem when building QtNodes. We think it might have something to do with the fact that we build our components with c++17 and we think the QtNodes components are build with C++20. There is some code in Qt6 to disable the error when c++17 is used. I found the GNU compiler options in CMakeLists.txt and set it to use c++17. Is there any other place where I need to set the compiler switch? We seem to be having problems with stuff in the autogen folder. Thanks James Bloom-Scheff From: Dmitry Pinaev ***@***.***> Sent: Monday, March 9, 2026 4:53 PM To: paceholder/nodeeditor ***@***.***> Cc: BLOOM-SCHEFF James ***@***.***>; Author ***@***.***> Subject: Re: [paceholder/nodeeditor] Question (Issue #516) paceholder left a comment (paceholder/nodeeditor#516) Hi, not a proven solution, but might give you a couple of insights: The Core Problem Qt 6. 8 uses C++20 features — specifically, it relies on the compiler supporting noexcept specifiers on ***@***.***paceholder left a comment (paceholder/nodeeditor#516)<https://urldefense.com/v3/__https:/github.com/paceholder/nodeeditor/issues/516*issuecomment-4026840236__;Iw!!FbCVDoc3r24SyHFW!6FkvQh18I9iEbN99tdfj3q-QLmB76-xX3zmguS-LMCRW8sUuxJPsD-DMuWy3_DRqx1ReFOjJRasCGlRukzobxz-qpHvIg329$> Hi, not a proven solution, but might give you a couple of insights: The Core Problem Qt 6.8 uses C++20 features — specifically, it relies on the compiler supporting noexcept specifiers on comparison operators (like operator==) in a way that satisfies static_assert checks introduced in newer Qt versions. GCC 11's C++20 support is incomplete. In particular: Qt 6.8 internally uses macros like Q_DECLARE_EQUALITY_COMPARABLE which assume the compiler can handle noexcept on spaceship/comparison operators correctly under C++20 GCC 11 has partial C++20 support but lacks full noexcept-on-comparison-operators compliance This causes the static_assert inside qmetatype.h to fire on every translation unit that includes Qt headers — hence hundreds of errors Solutions * upgrage GCC to 12 or 13 * or use clang >=14 * or downgrade Qt to <6.7 — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/paceholder/nodeeditor/issues/516*issuecomment-4026840236__;Iw!!FbCVDoc3r24SyHFW!6FkvQh18I9iEbN99tdfj3q-QLmB76-xX3zmguS-LMCRW8sUuxJPsD-DMuWy3_DRqx1ReFOjJRasCGlRukzobxz-qpHvIg329$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/BGQEECMOYZYYOKW7Q4B7T334P4VJXAVCNFSM6AAAAACWMINLC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMRWHA2DAMRTGY__;!!FbCVDoc3r24SyHFW!6FkvQh18I9iEbN99tdfj3q-QLmB76-xX3zmguS-LMCRW8sUuxJPsD-DMuWy3_DRqx1ReFOjJRasCGlRukzobxz-qpMJkNG7W$>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email. Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer https://www.3ds.com/privacy-policy/contact/
3. lonnie-souder-ii

   added

   bug

   enhancement

   and removed

   bug

   on Apr 25, 2026
4. lonnie-souder-ii

   changed the title [-]Question[/-] [+]FEAT: Support Qt 6.8 with C++17[/+] on Apr 25, 2026
5. JamesBloomScheff2 commented on May 1, 2026

   

   JamesBloomScheff2

   on May 1, 2026 via email

   Author

   More actions

   Hi, I just updated to a newer version of QtNodes along with moving from Qt5.15 to some version of Qt6, and I’ve run into a problem when a node is moved. When a user moves a node, I pick up the new position by overriding setNodeData and storing the new position. NodeGraphicsObject::mouseMoveEvent would call MoveNodeCommand::redo() which would call setNodeData. With the new version of QtNodes, NodeGraphicsObject::mouseMoveEvent no longer calls MoveNodeCommand::redo() and setNodeData is never called for the new position of the node. 1. Doesn’t that mean that the saved position of the node in _nodeGeometryData is now incorrect? 2. What is the best way of picking up the new position? I have overridden QGraphicsScene::event so I could do a bunch of tests and figure out which node was moved, but that seems like a lot of work. I imagine that there is a better way. Thanks James Bloom-Scheff This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email. Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer https://www.3ds.com/privacy-policy/contact/