4 ms·
With C++20 almost anything can be used in constexpr context (vector, unique_ptr, virtual, function, etc.) and as long as it's in the scope it can be tested at c
by kris-jusiak 3y ago
With C++20 almost anything can be used in constexpr context (vector, unique_ptr, virtual, function, etc.) and as long as it's in the scope it can be tested at compile time which guarantees memory safatey, no UB, etc. Additionally, since constexpr can be executed at run-time and code has been tested at compile-time already therefore 'static_assert' is (almost) all you need - https://godbolt.org/z/P4cqboGx6 https://godbolt.org/z/P4cqboGx6.
- saagarjha 3y agoHave zero cost abstractions gone too far?
- AshamedCaptain 3y agoI really don't think it works that way. You can for sure write code that will leak and otherwise be UB but run compile-time just fine.
- kris-jusiak 3y agoconstexpr has to checked for leaks and UB so as long as there is coverage at compile-time (static_assert + constexpr) I would assume there shouldn't be neither leaks nor UB. But the context is limitted where that can be applied and actually compiles. For example, there is no way to do it with global variables but with limited scope that's possible.
- AshamedCaptain 3y agoAt the very minimum, you can simply do is_constant_evaluated to change behavior depending on runtime vs compile-time...
- the_mitsuhiko 3y agoI _think_ you cannot conclude from a constexpr not having UB at compile time that it won’t have UB at runtime.
- kris-jusiak 3y agoI guess so, can't think of an example now but I'm pretty sure there are subtle corner cases (as always) and it depends on the testing, coverage and potential limitations of checking things at compile-time, though, IMHO, the technique is promissing and can help with a lot of use cases but defo not everything.
- layer8 3y ago(nevermind)
- jvanderbot 3y agoI think it's worth pointing out that your statement is true by definition, perhaps not true by implementation in these cases. It's not like UB produces _random_ behavior, it's just not specified what compilers _should_ do in those cases. Of course, cannot be relied upon.
- deleted 3y ago[deleted]
- jcelerier 3y agoSuccessful compilation of UB is explicitly disallowed by the standard in a constexpr context
- layer8 3y agoThanks, I wasn’t aware. Although that seems to be restricted to core language UB and not include standard-library UB: https://stackoverflow.com/a/72494688/623763 https://stackoverflow.com/a/72494688/623763
- DannyBee 3y agoThe standard explicitly disallows compiling of UB for constexpr. Otherwise, what you write is provably correct - UB is not statically decidable in all cases (and depending on the type of UB, not even in a lot of cases).
- soulbadguy 3y ago>constexpr has to checked for leaks and UB so as long as there is coverage at compile-time Source ?I am not sure constexpr give any garanty regarding UB and/or leaks
- 3836293648 3y agoConstexpr at compile times gives that guarantee, not constexpr in general. Hence static assert to force comptime evaluation
- soulbadguy 3y ago> Constexpr at compile times gives that guarantee Can you point to a source for that ? I am not trying to be pendantic, but genuilly curious
- dgellow 3y agohttps://en.cppreference.com/w/cpp/language/constant_expression https://en.cppreference.com/w/cpp/language/constant_expressi... Point 8: > A core constant expression is any expression whose evaluation would not evaluate any one of the following: > 8. an expression whose evaluation leads to any form of core language undefined behavior (including signed integer overflow, division by zero, pointer arithmetic outside array bounds, etc).
- layer8 3y agoI hope there’s also some text in the standard prohibiting implementations from allowing any other expressions as a constant expression (which they otherwise could as a language extension), and thus requires compilation failure for such expressions?
- kps 3y agoPragmatically, you can't stop extensions; if the fine print for `--std=cool++23` says that this mode is not actually C++23-compliant, nearly nobody will ever notice or care. Pragmatically, if a popular compiler makes `--std=cool++23` the default, and requires `--std=C++23 --iso-eic-jtc1-sc22-wg21 --pompous` to get standard-conforming behaviour, nearly nobody will do that; instead they will complain that other compilers lack the extensions.
- layer8 3y agoExtensions can be standard-compliant, in the sense that they don’t violate any prescription by the standard, and thus a program cannot assume their absence. My question was whether the standard actually takes care to render the acceptance of constexprs-with-UB non-standard-compliant. That is, in addition to “must accept X”, does it also say “must only accept X”?
- tlb 3y agoIndeed, it fails if you invoke UB. For example, an int overflow in a constexpr causes a compile error: <source>:5:17: error: static assertion expression is not an integral constant expression static_assert(1024*1024*1024*3 != 0, "UB"); https://godbolt.org/z/Wc591En7E https://godbolt.org/z/Wc591En7E
- mikepurvis 3y agoFrom an overall performance point of view, I wonder how the timing works out for the compiler to run your unit tests like this vs to produce and invoke a binary. I bet it's mostly a wash, and the ergonomics of conventional gtest macros look way better to my eye.
- kris-jusiak 3y agoHmm, there are obvisouly trade offs (it depends on the compiler how many tests, how are they written, etc.) but for apples to apples comparision the gtest binary would have to be either compiled with sanitizers (that would be probably slower to compile than static_assert tests without sanitizers) or run with valgrind or similar (execution would be much slower, static_asserts tets don't have to be executed, compiles=green).
- ynik 3y agoThe idea to let the compiler run the tests only works if you constexpr everything, which means putting all code in headers. This effectively means giving up on separate compilation. Worse, if you use some mixture (most code in headers but you still have >1 compilation unit), your compile times completely explode as essentially all code is compiled repeatedly for each unit.
- cozzyd 3y agoThere are other ways to do this. I made a proof of concept of using linker sections to allow you to sprinkle tests within the implementation inline once... https://github.com/cozzyd/examc https://github.com/cozzyd/examc (this is obviously not production-ready, just serves as a proof of concept). Basically the idea is that the test code gets written to a different linker section that your test runner can iterate through, when tests are enabled. This is easy on gcc because it generates automatic constants for the beginning and end of different linker sections. There may be away to do this with clang as well, but I never use clang.
- gpderetta 3y agoPragmatically you can write your code in such a way that you can get immediate feedback in your IDE as you write the code if a static assert fails as you are implementing your function. You could of course set up your runtime tests in a similar way, having the ide run them back to back as you are writing code, but it is more complicated, especially if the code is in an intermediate state that it is not fully compilable. So in the end it is not a huge breakthrough, but having compile time tests is still quite a nice feature.
- zerr 3y agoDepends on how you define a class. E.g. you are not using std::list in your example.