Modernize InertMessageSvc

• remove redundant destructor
• prefer inherited constructor
• avoid std::shared_ptr, emplace actions into the queue
• prefer lambda over std::bind

• [2017-11-27 08:02] Validation started with lhcb-gaudi-merge#326
• [2017-11-27 12:43] Validation started with lhcb-gaudi-head#1672

approved this merge request

assigned to @hegner

changed milestone to %v30r1

merged

mentioned in commit 87b68498

This MR breaks clang compilation, please fix ASAP. See https://lhcb-nightlies.cern.ch/logs/build/nightly/lhcb-clang-test/784/x86_64-centos7-clang50-opt/Gaudi/

This is very strange. The build error messages makes it look like for some reason, TBB failed to recognize Clang 5 as a C++11 compiler, and disabled the "emplace" method of the concurrent_bounded_queue, which should be there on C++11 compilers.

From a look at the corresponding TBB source code, it seems that the detection of either rvalue reference or variadic template support is failing.

The corresponding compiler feature detection macros are explicitly marked as badly written and requiring review in the TBB source code, though, that might explain things.

A short-term solution would be to replace "emplace" with "push", but the real long-term solution is to understand why this is failing. The proper std=c++14 flag is there on our side, so clang itself seems to be properly configured, but perhaps the issue comes from the libc++/libstdc++ version that we are using (which the TBB macros check).

That's what I could gather so far, anyone has more insight?

EDIT: Updated source code links to the TBB version that we are actually using (44_20160413 according to the build logs, which corresponds to TBB 4.4.4 according to the github version history).

mentioned in merge request !532 (merged)

see !532 (merged) -- this fixes the symptoms, and not the underlying problem which, as @hgraslan points out, is the feature detection in TBB not recognizing clang's standard compliance.

strange: pasting the TBB feature testing into godbolt seems to suggest they work just fine...

This makes me suspect even more that this is a libc++/libstdc++ issue, since that's the main remaining difference between our build environment and Godbolt's...

absolutely... and that may be a far more serious problem than this particular symptom...

Indeed. This is actually the main reason why we never use Clang in C++ lectures at LAL: STL implementations tend to blow up violently when put in contact with each other, and GCC and Clang have very strong and diverging opinion on what the best implementation is...

I seem to remember (very vaguely) that perhaps LCG clang uses an old gcc 4.8 (?) toolchain, which would imply a very old version of libstdc++... @clemenci surely knows more, as if my memory is right we may have actually discussed this...

We use gcc6.2 toolchain when building with clang, but @chasse noticed what is called 5.0 by SFT is not the final 5.0 (didn't have time to check myself).

Just FYI, I just tried to compile the master branch of Gaudi with an actual release version of Clang using the GCC 7.2 toolchain and still see the error.
Therefore, probably not a libstdc++ or clang problem.

added code cleanup label