Feedback request for Invariant Library idea
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<PrimitiveType, default_fail, my_invariant<PrimitiveType>>; *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<int, 10>); //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
2017-03-17 9:17 GMT+01:00 Attila Szenczi via Boost <boost@lists.boost.org>:
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.
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.
No, they won't. In particular, there will be no support for invariants. But also, it is not that clear that they will make it into C++20.
Do you think it would be a good addition to boost? I appreciate any feedback!
Your library matches close to constrained_value, that has been a candidate for Boost some time ago. Maybe you should check and compare with the author: http://rk.hekko.pl/constrained_value/ Your library -- it looks like it tries to specialize more for type int. A similar functionalit is available in the recently reviewed safe_numerics library. In documentation it even discusses the case like yours, and similar optimizations. You may wish to check it out: https://github.com/robertramey/safe_numerics/ Regards, &rzej;
Hello! I knew about safe_numerics and i felt like it's different from what i want. (tho i didn't check the whole lib) However, i didn't know about constrained_value, and it seems like this lib is exactly the same as mine. Even the design decisions are identical... so i reinvented the wheel. :'( Thank you very much! Attila Szenczi 2017-03-17 10:08 GMT+01:00 Andrzej Krzemienski via Boost < boost@lists.boost.org>:
2017-03-17 9:17 GMT+01:00 Attila Szenczi via Boost <boost@lists.boost.org
:
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.
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.
No, they won't. In particular, there will be no support for invariants. But also, it is not that clear that they will make it into C++20.
Do you think it would be a good addition to boost? I appreciate any feedback!
Your library matches close to constrained_value, that has been a candidate for Boost some time ago. Maybe you should check and compare with the author: http://rk.hekko.pl/constrained_value/
Your library -- it looks like it tries to specialize more for type int. A similar functionalit is available in the recently reviewed safe_numerics library. In documentation it even discusses the case like yours, and similar optimizations. You may wish to check it out: https://github.com/robertramey/safe_numerics/
Regards, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
2017-03-17 10:43 GMT+01:00 Attila Szenczi via Boost <boost@lists.boost.org>:
Hello!
I knew about safe_numerics and i felt like it's different from what i want. (tho i didn't check the whole lib)
However, i didn't know about constrained_value, and it seems like this lib is exactly the same as mine. Even the design decisions are identical... so i reinvented the wheel. :'(
This proves that the library is useful, and there is a demand for it. Your energy and motivation could still be used to get the library into Boost. I can see from the review schedule <http://www.boost.org/community/review_schedule.html> that this constrained_value library was even accepted, but then orphaned. Regards, &rzej;
Ohh, thanks, in this case i'll keep working on it. Regards, Attila 2017-03-17 11:07 GMT+01:00 Andrzej Krzemienski via Boost < boost@lists.boost.org>:
2017-03-17 10:43 GMT+01:00 Attila Szenczi via Boost <boost@lists.boost.org
:
Hello!
I knew about safe_numerics and i felt like it's different from what i want. (tho i didn't check the whole lib)
However, i didn't know about constrained_value, and it seems like this lib is exactly the same as mine. Even the design decisions are identical... so i reinvented the wheel. :'(
This proves that the library is useful, and there is a demand for it. Your energy and motivation could still be used to get the library into Boost. I can see from the review schedule <http://www.boost.org/community/review_schedule.html> that this constrained_value library was even accepted, but then orphaned.
Regards, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
participants (2)
-
Andrzej Krzemienski
-
Attila Szenczi