Do not use static_assert() to prevent template instantation errors
#77
Comments
|
What is the offending code that caused the failure? That static assert is there for a reason -- if it fires, then the dimensions of the multiplication don't line up, and multiplication is not possible. |
|
This is not the only overload participating in the overload resolution. The compiler can't choose the correct one because |
|
BTW, there are many other similar problems like that with this library. We have to meet at some point and work together to try to resolve those. Until then I recommend testing the library with various custom representation types. |
|
I need some example code to test against. |
|
The offending traits are in the body of the method but the method has an auto return type. As @mpusz is using decltype() with that method the compiler needs to look at the method body to determine the return type which fires the static assert. L For a normal method call it would probably work. |
|
I understand, but I can't provide it now as my code base is not stable. When it is on the mainline, I will provide one. In the meantime, here is a simple code showing why |
|
Yes, but overload resolution is not the source of the If I understand correctly, what you're saying is that overload resolution in your code is trying to resolve at least one overload whose matrix dimensions are incompatible with multiplication. And that overload is causing the And so my question is this -- how is it that you have an overload where you are trying to multiply two matrices with incompatible dimensions? This is why I wanted to see an example. |
|
Note that I am not disagreeing with your statements about using concepts -vs- static assert. I am however trying to understand the source of the |
As I said, I strongly suspect that it’s a decltype usage (not an actual call, see the error output) in @mpusz’s code and the usage of an auto return type in @BobSteagall’s code which means the method body has to be instantiated to infer the return type which causes the static assert. |
Yes, quite possibly true. But that begs the question -- |
|
In fact, as I look at the error messages, it appears to be an attempt to multiply a 3x1 matrix by a 3x1 matrix, which is incompatible. |
This is a multiplication of a vector with a physical unit from @mpusz’s library, so the multiplication from that library is supposed to be used IMHO. However, when the compiler determines the viable candidates for the operator* overload set (due to invoke_result / decltype usage) it needs the return type of all of these methods. And in order to determine its return type it needs to instantiate the method (because it has an auto return type) even though it will not be selected in the end. |
The offending code is: template<typename Rep = double>
using vector = STD_LA::fixed_size_column_vector<Rep, 3>;
Quantity auto v = make_quantity<isq::position_vector[m]>(vector<int>{1, 2, 3});
std::cout << "2 * v = " << 2 * v << "\n";There is NO
As I wrote before, my code is not ready to share now :-( However, the function that is being called here is just: template<typename Value>
requires(!Quantity<Value>) && detail::InvokeResultOf<quantity_spec.character, std::multiplies<>, const Value&, rep>
[[nodiscard]] friend constexpr Quantity auto operator*(const Value& v, const quantity& q)
{
return make_quantity<reference>(v * q.number());
} |
|
What are the types of |
|
|
|
Today I came back to LA and found the cause of If LA types and operators were guarded with concepts rather than |
Using
static_assert()allows great error messages but is a really bad solution for verification of a template instantiation. It does not SFINAE and is harmless to overload resolution.For example, I just obtained the following error message:
After commenting out the
static_assert()in op_traits_multiplication.hpp, my code compiled fine because a better overload was found.Use concepts instead to prevent instantiations of types like
multiplication_engine_traits.The text was updated successfully, but these errors were encountered: