Feedback request for Invariant Library idea

17 Mar 2017

      Hello!

I am asking for some feedback if my library idea is good enough to be part
of boost if it will meet the requirements.

When i started this small utility lib i had 3 goals in my mind:
- Write cleaner interfaces
- Be safer with pre and post conditions
- Eliminate redundant checks whenever possible at compile time

The goal is to solve this problem for primitive types.

*Example "bad" code:*

void set_red_color(int red) {
    //Why the precondition is not visible on the interface?
    assert(red >= 0 && red <= 255);
}

*Example "good" code:*

void set_red_color(bounded_i<0, 255> red) {}

*Example "bad" code:*

void foo(int bar) {
    assert(bar >= 0);
}

*Example "good" code:*

void foo(positive_i bar) {}
or
void foo(lower_bounded_i<0> bar) {}

Basically the main idea is to have an invariant_host class, which is
customizable via policies:
-* Invariant policy:* Define a static check() function which ensure the
invariant.

- *Fail policy: *Define a static trigger_assert function which is called
when the invariant policy::check is failed.
If the fail policy is disabled (constexpr bool flag), then the checks
doesn't happen.

Defining your own class looks like this:

template<typename PrimitiveType>
using my_type = invariant_host;

*Optimizations:*
bounded_i<0, 50>  bi (30); //trigger check
bounded_i<0, 100> bi2(bi); //range check happens at compile time
bounded_i<51, 52> bi3(bi1); //should be compile error
bounded_i<0, 50>  bi4(integral_constant); //check should happen
compile time

Things like operator+,-,*,/, bitwise operators etc can trigger checks.
Tho alot of times it can be optimized away. For example adding 2 positive
number should stay positive.

C++20(?) contracts will be great, it will allow us to write cleaner
interfaces, but i don't feel like it solve every issue i would like to
solve.

Do you think it would be a good addition to boost? I appreciate any
feedback!

Thank you very much!
Attila Szenczi

Attila Szenczi

Andrzej Krzemienski

Attila Szenczi

Andrzej Krzemienski

Attila Szenczi

tags

participants (2)