Re: sc_unwind_exception constructor/destructor

Philipp,

I will make the following changes:

   virtual ~sc_unwind_exception() throw();
   virtual ~sc_report() throw(); // Already present in the PoC sim

People may still like to comment on the protected methods of
sc_unwind_exception....

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
John Aynsley <john.aynsley@doulos.com>
Cc:
SystemC P1666 Technical <systemc-p1666-technical@eda.org>
Date:
17/01/2011 16:06
Subject:
sc_unwind_exception constructor/destructor

John, all,

sorry for being late in catching this issue. There is a minor oversight
with the current declaration of sc_unwind_exception and sc_report:
Their destructors miss the required throw() specifier:

   virtual ~sc_unwind_exception() /* requires: throw() */;
   virtual ~sc_report() /* requires: throw() */;

sc_unwind_exception/sc_report are derived from std::exception, which has

      virtual ~exception() throw();

Some compilers (most notably GCC since some 3.x version) don't like
the missing throw specifier and are correct from a C++ POV:

      error: looser throw specifier for
             ?virtual sc_unwind_exception::~sc_unwind_exception()?

See ISO/IEC 14882:2003(E), 15.4(3):

 "If a virtual function has an exception-specification, all
  declarations, including the definition, of any function that
  overrides that virtual function in any derived class shall only allow
  exceptions that are allowed by the exception-specification of the
  base class virtual function."

That said, what's the motivation to make the copy ctor and destructor
protected in sc_unwind_exception?
  - Yes, this effectively prohibits catching these objects by-value.
  - Yes, this can be considered good practice.
  - No, it's not the same for sc_report.
  - No, it does NOT help in the requirement to re-throw them.

    Both, "catch( sc_unwind_exception const & )" or even "catch(...)"
could still swallow the exception completely, if not re-thrown by
the application. I don't feel strongly about this, apart from the fact
that this is not consistent with sc_report without obvious reasons?

Greetings from Oldenburg,
  Philipp

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.