Re: why a member "swap" function shouldn't throw?
In article <1182086175.019990.315560@c77g2000hse.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:
On Jun 17, 2:20 am, "Daniel T." <danie...@earthlink.net> wrote:
James Kanze <james.ka...@gmail.com> wrote:
On Jun 16, 6:07 pm, "Daniel T." <danie...@earthlink.net> wrote:
James Kanze <james.ka...@gmail.com> wrote:
On Jun 15, 9:47 pm, "Daniel T." <danie...@earthlink.net> wrote:
Then provide a swap member-function that doesn't do
that. Someone else has already provided a link to the
GotW article that shows that, in principle, any class
can provide an exception safe swap function. This is
old ground.
The statement that "any class can provide an exception
safe swap function" isn't true.
Any class can, in principle, be written using the pimpl
idiom, and a class using the pimpl idiom can always
provide an exception safe swap.
So it's not "any class can provide an exception safe swap
function", but "any class using the pimpl idiom can provide an
exception safe swap function."
Therefore, any class can provide an exception safe swap.
You seem to have problems understanding English. It might be
possible to rewrite almost all classes so that they can provide
an exception safe swap, but you do have to rewrite the class,
and there can be very pertinent reasons why you can't. A class
which has a data member which doesn't provide an exception safe
swap, or which inherits from a class which doesn't provide an
exception safe swap, cannot normally provide an exception safe
swap.
Some may object: "Aha! Therefore this proves exception safety is
unattainable in general, because you can't solve the general problem
of making any arbitrary class strongly exception-safe without
changing the class!"
Such a position is unreasonable and untenable. The Pimpl
transformation, a minor structural change, IS the solution to the
general problem. To say, "no, you can't do that, you have to be able
to make an arbitrary class exception-safe without any changes," is
unreasonable for the same reason that "you have to be able to make an
arbitrary class meet New Requirement #47 without any changes" is
unreasonable.
...You Can Always Make Your Code (Nearly) Strongly Exception-Safe
There's an important principle here:
Just because a class you use isn't in the least exception-safe is no
reason that YOUR code that uses it can't be (nearly) strongly
exception-safe.
Not my words, that's a quote from Herb Sutter...
http://www.gotw.ca/gotw/059.htm