why a member "swap" function shouldn't throw?

[James Kanze]

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."

You don't need to control all the classes involved... simply write your
class using a single pointer as a member. That way your class will
consist "of only non-class types".

That's often a way of getting around the problem, yes.

 

[Daniel T.]

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. What's your
point? My point is, if you are writing a class, and you want to provide
an exception safe swap, then you have no excuses... Just do it.

 

[Kai-Uwe Bux]

Therefore, any class can provide an exception safe swap. What's your
point? My point is, if you are writing a class, and you want to provide
an exception safe swap, then you have no excuses... Just do it.

I doubt the "therefore" part, but maybe, I am missing something. Could you
demonstrate/illustrate your claim by providing an implementation of the
pair-template (known from std:air) with an added thread safe swap member?

Note that the members first and second in std:air are not member
functions. I do not see how an implementation based on the pimpl idiom can
conform to that interface (which sometimes, as in the case of std:air,
may not be for you to change).


Best

Kai-Uwe Bux

 

[Daniel T.]

I doubt the "therefore" part, but maybe, I am missing something. Could you
demonstrate/illustrate your claim by providing an implementation of the
pair-template (known from std:air) with an added thread safe swap member?

That is not a class that you are writing. It was created by someone
else.* Again, if you are writing a class, and you want to provide an
exception safe swap, then you have no excuses.

* However, the obvious answer is to provide a non-throw swap function
for both elements in the pair...

 

[Kai-Uwe Bux]

What made you snip the sentence that I was explicitly referring to?

>
>Therefore, any class can provide an exception safe swap. What's your
>point?

Your claim, as I understood it, was that _any class_ can provide an
exception safe swap _because_ one can always use pimpl. I still don't see

That is not a class that you are writing. It was created by someone
else.*

So what? Are classes specified by others not included in "any class"?

I have been told that some programmers have to program according to specs
given to them. I just think, the hint "use pimpl" is not helpful in some of
those cases.

Again, if you are writing a class, and you want to provide an
exception safe swap, then you have no excuses.

I agree that if you _design_ a class (as opposed to provide an
implementation for an already specified class) you can make sure that a
swap member can be implemented in an exception safe way (provided you have
similar control over all member objects). That, however, is a somewhat
weaker statement than the claim that _any class_ can provide an exception
safe swap member function. It's more like: whenever you face a class for
which you cannot implement swap() in an exception safe way, the fault is
with the design and that class could be replaced (absent other
considerations) by a different class that does not suffer from the flaw.

You are right to make that point. It is an important point that puts the
problem into the context of class design, where it belongs. I just thought
that your pimpl remark might be an overgeneralization.


Best

Kai-Uwe Bux

 

[James Kanze]

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.

What's your point? My point is, if you are writing a class,
and you want to provide an exception safe swap, then you have
no excuses... Just do it.

If you can. You can't always. And in many cases, there's no
point in it. (I never provide one for entity classes, for
example, which don't support copy or assignment. Even when I
trivially could---there's just no point in it.)

 

[Daniel T.]

What made you snip the sentence that I was explicitly referring to?

You were referring to an ancillary comment rather than addressing the
point I was making. As the part I didn't snips says, "My point is..."

Your claim, as I understood it, was that _any class_ can provide an
exception safe swap _because_ one can always use pimpl. I still
don't see how to do that for std:air<>.

No, my claim as I have actually stated is, "If you are writing a
class, and you want to provide an exception safe swap, then you can do
that."

I agree that if you _design_ a class (as opposed to provide an
implementation for an already specified class) you can make sure
that a swap member can be implemented in an exception safe way
(provided you have similar control over all member objects).

Again, you don't need "similar control over all member objects." If
you are *designing* the class then you *can* provide an exception safe
swap. (period, full-stop.) No "provided", no excuses.

You are right to make that point. It is an important point that puts
the problem into the context of class design, where it belongs. I
just thought that your pimpl remark might be an overgeneralization.

Accepted.

 

[Kai-Uwe Bux]

Again, you don't need "similar control over all member objects." If
you are *designing* the class then you *can* provide an exception safe
swap. (period, full-stop.) No "provided", no excuses.

You still have to deal with tradeoffs in design issues. Suppose you have a
library designed to be used by deriving from its classes (this library has
some very good things going for it: replacing it would incur high
development costs on your part). Also suppose that its classes do not
provide exception safe assignment or swap. In that case, classes derived
from the library classes will have a hard time providing an exception safe
swap and designing your classes so that they have an exception safe swap
member may require you to write a complete wrapper around the library. You
are probably right that it _can_ be done, but you may be wrong in claiming
that there are "no excuses" for not doing it. Oftentimes, it just might not
be cost effective.


Best

Kai-Uwe Bux

 

[Daniel T.]

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