Re: The C++ article in April issue of DDJ
On Mar 20, 12:10 am, Greg Herlihy <gre...@pacbell.net> wrote:
On 3/19/07 12:24 PM, in article
1174327364.944342.298...@l75g2000hse.googlegroups.com, "Andrei Iltchenko"
[...]
"The destructor is quite empty, but it can't be dropped. The compiler
will indeed generate a default destructor for you, but the default
destructor doesn't come with an empty throw() exception specification.
This is required because std::runtime_error defines such a virtual
destructor. Exception specifications are an annoying misfeature of C++
that specifies what exceptions a method may throw and are part of the
method signature. Thankfully, they are optional so you don't see them
a lot in the wild. "
This comment is specious as there is no point in overriding the
destructor for the purpose of obtaining an exception specification
that doesn't allow exceptions. This is because:
1. The destructor in std::exception is defined as follows (See Section
18.6.1):
virtual ~exception() throw();
2. std::runtime_error publicly inherits from std::exception and relies
on the compiler to implicitly declare the destructor.
3. The language is clear that an implicitly-declared destructor "shall
allow no exceptions if every function it directly invokes allows no
exceptions" (See 15.4/11-13)
The example in ?15.4/13 paraphrases the relevant requirement: "a function
that overrides a virtual function from a base class shall have an
exception-specification at least as restrictive as that in the base class."
I'm not sure where you're quoting; in my copy of ISO 14882:1998,
?15.4/12 starts: "An implicitly declared special member function
(clause 12) shall have an exception-specification." and then
goes on to describe how this exception specification is defined.
According to the standard, the implicitly generated destructor
should have the correct exception specification, so the user
shouldn't have to provide one.
In practice, I've had problems with non-conformance in this
regard myself, and also always provide the constructor
explicitly. What's the good of my code being standard
conformant if the compilers I have to use don't allow it?
[...]
I find it quite sad that a magazine that used to be renowned for the
quality of its articles, didn't put enough effort to catch such
blatant omissions during the article's editing.
A reputation for quality and accuracy are all the more reason to reserve
judgement before deciding (and announcing) that the apparent "blatant"
errors in this article are so obvious, or whether (after further research)
they may turn out not to be errors at all.
I agree here. In practice, I would have written the class
almost exactly the way the author of the article did. The only
problems I see are that 1) he based his comments on his
compiler, without stating that the compiler wasn't conformant,
and 2) his statement about why the mutable was needed was a bit
misleading (but only the why---it is definitly needed). In sum,
two very minor points, all things considered. If there's any
real criticism to lay against the article, it's that exception
types which allocate dynamic memory right and left aren't
necessarily a good idea in certain types of applications; this
point should probably have been mentionned. (This doesn't mean
that the idea is bad, and should be avoided. Just that it does
have one aspect which probably needs to be considered in certain
contexts.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]