On Sat, Sep 17, 2011 at 1:08 AM, Ben Robinson <icaretaker@gmail.com> wrote:
On Fri, Sep 16, 2011 at 3:19 PM, Gennadiy Rozental <rogeeff@gmail.com
wrote:
Ben Robinson <icaretaker <at> gmail.com> writes:
As they say: I'll believe it, when I see it ;) Until that time this is all too much vapor for me. As I mention in other post, you never explained how this condition is checked and who is going to check it: compiler, preprocessor, person.
Gennadiy
My written communication skills could certainly be improved, I'll try again.
When compiled for production, the compiler will generate a compiler error for failing predicates/conditions which are statically asserted (exactly the same functionality as the BOOST_MPL_ASSERT_* macros).
When compiled for testing, the code will compile around the predicates, and during run-time, if the predicates/conditions fail, an exception is thrown.
This allows shipping the code with the usual static assert functionality, but now enables writing run-time unit tests for both regression testing, and confirming that the predicates do in fact fail when they should.
Is that a better explanation?
It would seem to me that, typically, removing a static_assert that would fail for a particular instantiation will just push the compiler errors further on down the code after the (removed) static_assert; i.e., the static_assert is only meant to catch compiler errors early and in a readable way. Do you have a particular use case in mind? - Jeff