Explicitly mark the destructor of GaudiParallelizer as noexcept(true)

Fixes GAUDI-1187, Gaudi failing to build against recent releases of
Intel TBB.

See merge request !132

GaudiMTTools/src/GaudiParallelizer.cpp

@@ -31,11 +31,6 @@ GaudiParallelizer::GaudiParallelizer(const std::string& name, ISvcLocator* pSvcL
   m_names.declareUpdateHandler (&GaudiParallelizer::membershipHandler, this );
 }
 
-// ============================================================================
-// Destructor
-// ============================================================================
-GaudiParallelizer::~GaudiParallelizer() {}
-
 // ============================================================================
 // Initialization
 // ============================================================================

GaudiMTTools/src/GaudiParallelizer.h

@@ -21,7 +21,9 @@ class GaudiParallelizer: public GaudiAlgorithm {
 public:
   /// Standard constructor
   GaudiParallelizer(const std::string& name, ISvcLocator* pSvcLocator);
-  virtual ~GaudiParallelizer(); ///< Destructor
+  
+  /// Destructor. An explicit noexcept(true) is necessary for Gaudi to build (see GAUDI-1187)
+  virtual ~GaudiParallelizer() noexcept(true) override { }
 
   virtual StatusCode initialize();    ///< Algorithm initialization
   virtual StatusCode execute   ();    ///< Algorithm execution

[Gerhard Raven]

actually, instead of making it more complicated, why not just get rid of this line and let the compiler sort it out? There is no need to add a default (trivial) destructor in a derived class -- the parent should have a virtual destructor, otherwise typically one should not derive from it, and thus the implicitly generated one should be good enough.

The only difference would be if the implementation is pushed into a .cpp file as that affects how things are linked, but in case of an inline defined trivial destructor even that does not make a difference. So I'd rather never ever see a trivial destructor inlined in a class that derives from something.... unless there is a comment above it that explains why it is there (and this one isn't one of those ;-)

[Marco Clemencic]

I agree. Once v28r0 is out, we can run a sed 's/<trivial destructor>// on Gaudi (GAUDI-1269).