Re: Aliasing and Exception Safety Guarantee Classification
on Thu Dec 18 2008, Brendon <brendon.j.costa-AT-gmail.com> wrote:
Hi all,
I have recently been looking at some of the work done by others on the
automatic classification of Exception Safety Guarantees in C++. In
doing so I have been thinking about the affects of aliasing on the
safety classification. For example:
int A(int& param)
{
param++;
throw param;
//return param;
}
int B(int param)
{
A(param);
return param;
}
With the code shown: function B() meets the strong guarantee. However
what guarantee classification should given to function A()?
Basic.
My first thought was basic or whacky,
"Whacky" is not really a guarantee, frankly. I'm guessing you've been
looking at http://www.ddj.com/cpp/184401728. As I pointed out to the
authors while they were working on that article, while their algorithm
offers some insight into how exception guarantees compose, it's
incomplete. In particular, the algorithm can never reach the conclusion
that a piece of code is unsafe.
but to be honest I don't think it can be accurately classified at all.
Hum.
For function A() its guarantee depends on what "param" aliases, which
means it needs context to determine its guarantee, in which case the
guarantee does not really apply to the function itself but the caller
of the function.
I see what you're driving at. This is a subtle point that most people
are content to overlook, but you have to remember that invariants form
hierarchies. So, for example, even though an individual vector's
invariants may all be met, modifying that vector without also modifying
some other vector correspondingly could violate an invariant that exists
at a different level of the hierarchy (e.g. that these two vectors
maintain the same number of elements).
Another thing you have to keep in mind is that the program's invariants
can't be determined by looking at its functional code. Invariants
therefore only exist in documentation or tests. Any other relationships
maintained by a program can be considered an unintentional artifact. So
*in general* if you offer code like the above, with no documentation,
there's little we can say about the guarantees it offers.
In this case, however, the code is simple enough that we can analyze
everything. So, let's look at A. It modifies one datum, an int. From
A's point-of-view, nothing in particular relates that int to another
part of the program state (that would not be the case, for example, if
the int were directly accessed as a global). Does said modification
violate any of int's invariants? No. So A offers the basic guarantee.
It's that simple.
Is anyone aware of existing literature discussing the classification
of such functions that i might be able to read or am i just looking at
it too much and it would really just be classified as whacky?
Here are a couple serious treatments that I've read:
http://www.springerlink.com/content/h15788j13184712j/
http://tinyurl.com/munkby-schupp
Cheers,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]