profiling.h conflicts with Qt

[zappaz00]

profiling.h has method with name "emit" and strongly conficts with Qt keyword emit() used for signal/slot mechanism; Please, rename this method (problem starts from one api and absents in parallel studio). Qt won't fix it. Now developer can't correctly use Qt and TBB together.

[alexey-katranov]

Consider #309

[zappaz00]

Consider #309

I saw it when I tried to find the solution
There isn’t the solution and issue closed. Only advice about avoidance usage Qt and TBB together or use QT_NO_KEYWORDS. But if Qt already in huge project - it's really hard.
Maybe add namespace or change to other name for TBB function emit?

[vlserov]

profiling.h is a public API and changes might affect other users.
Using TBB with QT_NO_KEYWORDS is the right way. But if project is huge and it's complicated, consider to use workaround suggested for Boost Signals: boost signals doc

#ifndef Q_MOC_RUN
#if defined(emit)
    #undef emit
    #include <tbb/tbb.h>
    #define emit // restore the macro definition of "emit", as it was defined in gtmetamacros.h
#else
    #include <tbb/tbb.h>
#endif // defined(emit)
#endif // Q_MOC_RUN

[alexey-katranov]

rename this method (problem starts from one api and absents in parallel studio)

The same code was located in tbb_profiling.h with TBB that was a part of Intel Parallel Studio. Maybe oneTBB includes profiling.h in some additional place. What headers do you include from oneTBB?

@vlserov Perhaps, we can try to think about some workarounds or options to hide this code when user requests.

[keithel]

@zappaz00 QT_NO_KEYWORDS does not need to be defined when compiling Qt (which one comment in #309 mentioned). You just need to define QT_NO_KEYWORDS before including any Qt headers, and then replace you use of signals, signal, slots, slot, and emit with Q_SIGNALS, Q_SIGNAL, Q_SLOTS, Q_SLOT, and Q_EMIT, respectively.

If you're not actually using the emit function in OneTBB, in a file that includes some OneTBB thing that defines emit, then I think you can just get away with including the OneTBB headers before any Qt ones, and everything will compile ok. If you're using the OneTBB emit function, however, then you need to go with the QT_NO_KEYWORDS approach.

You can apply QT_NO_KEYWORDS across your whole app, or just apply it targeted, to each affected source file.

See https://doc.qt.io/qt-6/signalsandslots.html#using-qt-with-3rd-party-signals-and-slots for more information.

[luntik2012]

@keithel renaming emit it tbb looks much easier, there are a lot of workarounds and they all look ugly

[mnikelsky]

You don´t even have to rename it, just adding something like
#pragma push_macro("emit")
#undef emit
....
#pragma pop_macro("emit")

to profiling.h fixes the issue. Just add a TBB define we can set to OneTBB so we can decide whether we want to have this or not. Having to patch the tbb each time a new version comes out is annoying.

[gtkramer]

TBB and Qt ultimately need to be able to co-exist in an application. Using the -DQT_NO_KEYWORDS macro after doing a find and replace operation on a Qt code base of any size is a great start and should work for most folks to deconflict these emit symbols. In some cases though, it's not enough. While it will work with Qt and VTK, it won't with other extensions like qicstable, which need to be updated. This is quite messy and very unfortunate.

[kikaxa]

A bit of shame that so many implementation details leak and break other libraries(concerns both qt and less tbb).
It is not possible to work around in other huge library(ies) that pull in tbb somewhere, it is not reasonable to change standard qt code that is using emit.

best fix is to hide as much implementation from headers.
in our case, removing the body of event in a patch is enough to make it work.