Qt4: a bug (?) in qbasictimer: `error: expected unqualified-id before ')' token`

[barracuda156]

While suffering with attempts to fix blackomega ObjC++ sources to compile with gcc14, one of the persistent issues was the following:

In file included from /opt/local/include/qt4/QtCore/qtimer.h:47,
                 from /opt/local/include/qt4/QtCore/QTimer:1,
                 from /opt/local/var/macports/build/_opt_local_ppcports_audio_blackomega/blackomega/work/blackomega-2e5894f5c56621ead53ce68d9416042751e81b82/source/audioio/inc/AOBase.h:13,
                 from /opt/local/var/macports/build/_opt_local_ppcports_audio_blackomega/blackomega/work/blackomega-2e5894f5c56621ead53ce68d9416042751e81b82/source/audioio/inc/AOCoreAudio.h:12,
                 from /opt/local/var/macports/build/_opt_local_ppcports_audio_blackomega/blackomega/work/blackomega-2e5894f5c56621ead53ce68d9416042751e81b82/source/audioio/src/AOCoreAudio.mm:1:
/opt/local/include/qt4/QtCore/qbasictimer.h: In destructor 'QBasicTimer::~QBasicTimer()':
/opt/local/include/qt4/QtCore/qbasictimer.h:60:35: error: expected unqualified-id before ')' token
   60 |     inline ~QBasicTimer() { if (id) stop(); }
      |                                   ^
make[2]: *** [source/audioio/CMakeFiles/audioio.dir/src/AOCoreAudio.mm.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from /opt/local/include/qt4/QtCore/qtimer.h:47,
                 from /opt/local/include/qt4/QtCore/QTimer:1,
                 from /opt/local/var/macports/build/_opt_local_ppcports_audio_blackomega/blackomega/work/blackomega-2e5894f5c56621ead53ce68d9416042751e81b82/source/remote/inc/RemoteIF.h:12,
                 from /opt/local/var/macports/build/_opt_local_ppcports_audio_blackomega/blackomega/work/blackomega-2e5894f5c56621ead53ce68d9416042751e81b82/source/remote/inc/AppleIRRemoteController.h:8,
                 from /opt/local/var/macports/build/_opt_local_ppcports_audio_blackomega/blackomega/work/blackomega-2e5894f5c56621ead53ce68d9416042751e81b82/source/remote/src/AppleIRRemoteController.mm:1:
/opt/local/include/qt4/QtCore/qbasictimer.h: In destructor 'QBasicTimer::~QBasicTimer()':
/opt/local/include/qt4/QtCore/qbasictimer.h:60:35: error: expected unqualified-id before ')' token
   60 |     inline ~QBasicTimer() { if (id) stop(); }
      |                                   ^
make[2]: *** [source/remote/CMakeFiles/remote.dir/src/AppleIRRemoteController.mm.o] Error 1

Modern gcc breaks down on this. It looks like this id is just locally defined in the header, and it does not need to be precisely id, which results in a conflict with the reserved keyword.
Can we patch it to be tid instead or w/e else, just not id?

[RJVB]

On Friday June 20 2025 04:04:59 Sergey Fedorov wrote: 60 | inline ~QBasicTimer() { if (id) stop(); }

Yes, this will cause issues when compiling as ObjC++ You could try to look at the preprocessor output to see what that code actually expands to before hitting the actual compile stage (replace `-c` with `-CC -dD -E` in the compiler invocation). There's a tiny chance that `id` is actually a macro that can be undefined.

Modern gcc breaks down on this. It looks like this `id` is just locally defined in the header, and it does not need to be precisely `id`

Yes, it's a private member variable so you could do that. However, this will *probably* mean you'd need to recompile everything that uses QTimers because it will try to access QBasicTimer::id via that public member function backdoor. The alternative is to de-inline the offending function(s). If it's only the dtor you wouldn't even notice a performance hit, and it's an ABI-safe change. Funny thing is that Qt5 uses the exact same code, and I've never run into issues like you describe... maybe because clang is smarter here?

[barracuda156]

Funny thing is that Qt5 uses the exact same code, and I've never run into issues like you describe... maybe because clang is smarter here?

It is certainly not Qt4-as-such issue, since this worked fine with clang for me too – with Qt4 on Sonoma.
Also, Xcode gcc has no problem with it either, so it is not gcc as such, but only the modern gcc.

I do not know if it is a modern gcc regression or rather clang is too lax though.