Re: sc_unwind_exception constructor/destructor

John,

thanks, the missing throw()s are more important.

  I've just been curious about the motivation wrt. the restricted copy
ctor/destructor. I may miss the benefit of this and just had the
ingenuous user in mind, stumbling about an error when trying to catch by
value. But I don't think that it's an important issue.

Greetings from Oldenburg,
  Philipp

On 18/01/11 14:12, john.aynsley@doulos.com wrote:
> 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.