Library to facilitate the use of the “design by contract” principle [closed]

Answer 1

I have a litle c++ header with requirements, insurances and invariants. It has less than 400 loc and should fulfill your needs. You can find it under dhc.hpp It reports errors in a useful way and can be compiled out via defines.

#include <dbc.hpp>

class InvarTest {
public:
        int a = 0;
        int b = 9;

        INVARIANT_BEGIN
                Inv(RN(0,a,32));
                Inv(RN(0,b,10));
        INVARIANT_END

        inline void changeMethod() {
                Invariant(); // this runs the invariant block at the beginning and end of the method
                a = 33;         
        }
};

int testFunc(int a, double d, int* ip) {
        // RN = a in range 0 to 10, NaN = not a number, NN = not null
        Rqr(RN(0,a,10), NaN(d), RN(0.0,d,1.0), NN(ip));

        // Enr return the passed value
        return Esr(RN(0.0,a+d,20.3));
}

void testFunc2(std::vector<int>& a, std::shared_ptr<int> sp) {
        Rqr( SB(a,0), TE(a.size() % 12 == 0), NN(sp));
}

Answer 2

Try this one: Contract++. It has been accepted to Boost (but is not shipping yet).

Answer 3

Simplest?

Assert statements at the start of your function to test your requirements. Assert statements at the end of your function to test your results.

Yes, it's crude, its not a big system, but its simplicity makes it versatile and portable.

Answer 4

I followed the teachings of the following articles:

• An exception or a bug? (Miro Samek, C/C++ Users Journal, 2003)
• Simple Support for Design by Contract in C++ (Pedro Guerreiro, TOOLS, 2001)

What I ultimately applied was pretty much Samek's approach. Just creating macros for REQUIRE, ENSURE, CHECK and INVARIANT (based on the existing assert macro) was very useful. Of course it's not as good as native language support but anyway, it allows you to get most of the practical value from the technique.

As for libraries, I don't think that it pays to use one, because one important value of the assertion mechanism is its simplicity.

For the difference between debug and production code, see When should assertions stay in production code?.

Answer 5

Use standard ASSERT/Q_ASSERT, but beware of "invalid" assertions, especially if you leave such diagnostics in external testing (build without NDEBUG).

Small story regarding DBC implementation (using assertions) in a C++ project and "debugging always enabled" policy.

We were using pretty standard tools (ASSERT()/Q_ASSERT()) as DBC implementation until we hit the following situation in integration testing: our latest build was always failing just after start. It was not very professional to release such version (after week of internal QA efforts).

How the problem was introduced?

• A developer left wrong assertion (invalid logic expression) in source code
• All our pre-release builds had assertions enabled (to track errors in integration tests)
• Internal QA has different environment settings than integration tests, so the "assertion error" was not visible

As a result poor developer was blamed for this error (obviously without this ASSERT there would be no crash) and we had to release hotfix to allow integration tests to be continued.

First of all: I need assertions enabled in integration tests to track failed conditions (the more assertions the better), on the other hand I don't want developers to be afraid that some "extra" ASSERT will crash full software stack.

I found, probably interesting C++-based resolution for this problem: weak asserions. The idea is to not stop whole application on failed assertion, but to record stacktrace for later analysis and continue. We can check as many expectations as we like without fear of crash and we get feedback (stacktraces) from integration. Single process run can provide many failed assertion cases for analysis instead of only one (because there's no abort() called).

Implementation of this idea (using some LD_PRELOAD magic) is shortly described here: http://blog.aplikacja.info/2011/10/assert-to-abort-or-not-to-abort-thats-the-question/

Answer 6

Some design patterns, such as the non-virtual interface make it natural to write pre/post-conditions for a given method:

#include <cassert>

class Car {
    virtual bool engine_running_impl() = 0;
    virtual void stop_impl() = 0;
    virtual void start_impl() = 0;

    public:
    bool engine_running() {
        return engine_running_impl();
    }

    void stop() {
        assert(engine_running());
        stop_impl();
        assert(! engine_running());
    }

    void start()
    {
        assert(! engine_running());
        start_impl();
        assert(engine_running());
    }
}


class CarImpl : public Car {
    bool engine_running_impl() {
        /* ... */
    }

    void stop_impl() {
        /* ... */
    }

    void start_impl() {
        /* ... */
    }
}