Question

For example, I have to assure that a certain function for a certain real-time system works for 20 ms or less. I can simply measure time at the beginning of a function and at the end of it, then assert the difference to be satisfactory. And I do this in C++.

But this look pretty much like contract, except time checking is a post-condition, and time measurement at the beginning is not a condition at all. It would be nice to put it into contract not only for the notation of it, but for building reasons as well.

So I wonder, can I use contract capabilities to check the time of function working?

Was it helpful?

Solution

Sort of, but not really well. The reason is variables declared in the in{} block are not visible in the out{} block. (There's been some discussing about changing this, so it can check pre vs post state by making a copy in the in block, but nothing has been implemented.)

So, this will not work:

void foo()
in { auto before = Clock.currTime(); }
out { assert(Clock.currTime - before < dur!"msecs"(20)); }
body { ... }

The variable from in won't carry over to out, giving you an undefined identifier error. But, I say "sort of" though because there is a potential workaround:

import std.datetime;
struct Foo {
    SysTime test_before;
    void test()
    in {
        test_before = Clock.currTime();
    }
    out {
        assert(Clock.currTime - test_before < dur!"msecs"(20));
    }
    body {

    }
}

Declaring the variable as a regular member of the struct. But this would mean a lot of otherwise useless variables for each function, wouldn't work with recursion, and just pollutes the member namespace.

Part of me is thinking you could do your own stack off to the side and have in{} push the time, then out{} pops it and checks.... but a quick test shows that it is liable to break once inheritance gets involved. If you repeat the in{} block each time, it might work. But this strikes me as awfully brittle. The rule with contract inheritance is ALL of the out{} blocks of the inheritance tree need to pass, but only any ONE of the in{} blocks needs to pass. So if you had a different in{} down the chain, it might forget to push the time, and then when out tries to pop it, your stack would underflow.

// just for experimenting.....
SysTime[] timeStack; // WARNING: use a real stack here in production, a plain array will waste a *lot* of time reallocating as you push and pop on to it

 class Foo {
    void test()
      in {
        timeStack ~= Clock.currTime();
      }
      out {
         auto start = timeStack[$-1];
         timeStack = timeStack[0 .. $-1];
         assert(Clock.currTime - start < dur!"msecs"(20));
         import std.stdio;
         // making sure the stack length is still sane
         writeln("stack length ", timeStack.length);
       }
    body { }
}

class Bar : Foo {
 override void test()
  in {
     // had to repeat the in block on the child class for this to work at all
    timeStack ~= Clock.currTime();
  }
  body {
    import core.thread;
    Thread.sleep(10.msecs); // bump that up to force a failure, ensuring the test is actually run
  }
}

That seems to work, but I think it is more trouble than it's worth. I expect it would break somehow as the program got bigger, and if your test breaks your program, that kinda defeats the purpose.

I'd probably do it as a unittest{}, if only checking with explicit tests fulfills you requirements (however, note that contracts, like most asserts in D, are removed if you compile with the -release switch, so they won't actually be checked in release versions either. If you need it to reliably fail, throw an exception rather than assert, since that will always work, in debug and release modes.).

Or you could do it with an assert in the function or a helper struct or whatever, similar to C++. I'd use a scope guard:

void test() {
    auto before = Clock.currTime();
    scope(exit) assert(Clock.currTime - before < dur!"msecs"(20)); // or import std.exception; and use enforce instead of assert if you want it in release builds too
    /* write the rest of your function */
}

Of course, here you'll have to copy it in the subclasses too, but it seems like you'd have to do that with the in{} blocks anyway, so meh, and at least the before variable is local.

Bottom line, I'd say you're probably best off doing it more or less the same way you have been in C++.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top