C + + for "abnormal security" and efforts are worth---"effective C + +" __c++

Clause 29: Striving for "exceptional security" is worth it.

Before today's "Exception safe" Discussion topic, let's take a look at the following code:

Class prettymenu{public
:
    ...
    void Changebackground (std::istream& imgsrc);
    ...
Private:
    mutex mutex;
    image* Bgimage;
    int imagechanges;
};
void Prettymenu::changebackground (std::istream& imgsrc) {
    lock (&mutex);
    Delete bgimage;
    ++imagechanges;
    Bgimage=new Image (IMGSRC);
    Unlock (&mutex);
}   

This function is particularly bad when it is considered "exceptional security". Because:
1 easily disclose resources, if Bgimage=new Image (IMAGESRC) did not apply for resource success, then unlock (&mutex) will never be executed, which will lead to resource leakage;
2 The data pointed to is easily a bad block, because Bgimage=new Image (IMAGESRC) If an exception is thrown, then bgimage will not point to the newly generated zone, but continue to point to its original location, and its original memory area due to delete There is no data in the Bgimage, so Bgimage will point to an object that has already been deleted, causing the data phantom. that is, "abnormal security" requires us to meet the following two requirements: 1 do not disclose any resources, 2 do not allow data corruption.

So what's our solution? It is easy to solve the problem by using the Object Explorer mentioned earlier, lock resource management class can guarantee the resources will not leak, can refer to "clause 11" to deal with the solution of the self assignment problem. The resolution code is as follows:

void Prettymenu::changebackground (std::istream& imgsrc) {
    Lock M1 (&mutex);
    Delete bgimage;
    ++imagechanges;
    Bgimage=new Image (IMGSRC);
}

We've just focused on preventing resource leaks in the code above, and now we're focusing on bad blocks of code.
The exception security function provides one of the following three guarantees: 1 basic commitment; If the exception is thrown, anything within the program remains in effect, no object that or data structure will be corrupted, all objects that are in an internal consistent state; 2 strongly guarantee If the exception is thrown, the program state does not change, call such a function needs to have such a recognition, if the function succeeds, is a complete call success, if the function fails, the program will revert to the "call function" state, as in the database rollback operation, to ensure the consistency of the database; 3 do not throw the guarantee: The promise never throws an exception, because they are always able to complete the functions they originally promised, and do all the operations for the built-in types provide nothrow guarantee, which is an essential and critical basic material in the exception safety code.

For strong assurance, we usually have a design strategy called the copy and swap design strategy , the principle is simple: to make a copy of the object you intend to modify, and then make all necessary changes in the copy, if any modification action throws an exception, the original object remains unchanged state, With all the changes being successful, to replace the modified copy and the Meta object in an operation that does not throw an exception, the actual implementation is usually to put all "subordinate object data" from the original object into the other object, and then give the original object a pointer to the so-called implementation object (copy), This realization method is called "Pimpl idiom", the typical realization means such as:

struct pmimpl{
    std::trl::shared_ptr<image> bgimage;
    int imagechanges;
};
Class prettymenu{...
Private:
    mutex mutex;
    Std::trl::shared_ptr<pmimpl> Pimpl;
};
void Prettymenu::changebackground (std::istream& imgsrc) {
    using Std::swap;
    Lock M1 (&mutext);//obtain replica data for mutex
    std::trl::shared_ptr<pmimpl> pnew (New Pmimpl (*pimpl));
    Pnew->bgimage.reset (New Image (IMGSRC));//modify replica
    ++pnew->imagechanges;
    Swap (pimpl,pnew);//permutation (Swap) data, releasing mutex
}

Summarize:
1 Abnormal security function even if the exception will not disclose resources or allow any data structure corruption, such a function area is divided into three possible guarantees: basic type, strong type, do not throw abnormal type;
2 "strong guarantee" is often able to achieve copy-and-swap, but "strong guarantee" is not all functions can be realized or have practical significance;
3 The "Exception security guarantee" provided by the function usually is the weakest of the "exception security guarantees" of the functions that it calls.