Amazing! This is why I love C++ so much, just the shear amount of things you can do. You just wrote a program that is completely "run" by the compiler, there is very little "runtime" code. Talk about a huge performance boost. With this you can completely offload the cpu runtime to the compiler when possible. Templates, SFINAE, and Meta-programming for the win! Pretty cool stuff indeed.
The separated function for evaluating the conditions is a nice move, which can be improved with constexpr lambda. :) It's exciting to see it working. Thanks!
Was writing the function "is_both" the only way to make the code work? IMO you could just have removed the "else" from "else if constexpr(std::is_floating_point::value)".
Many programmers I've spoken to have expressed concerns about compile time of templates. So much so that some refuse to write templates even when it would probably save development time. Do you think constexpr will speed up compile time enough to catch on with these kinds of programmers?
Can I use ternary instead of is_both or it could prevent constexpr to be calculated at compiletime? The ternary is (is_integral && ! Is_same ? numeric_limit < number : false
At the start (say 1:41), how is the code for the function "print_type_info()" compiling even though it's parameter is simply a type ? (ie, there is not variable name for the parameter there ...) ??
At around 9:43 you mention the first constexpr if will be compiled, but its nested constexpr if block won't be compiled. I didn't understand that well enough. Can you elaborate a bit? Thanks.
The idea is that at runtime the conditional branching wont exist. Each time the compiler must instenciate a new declaration of the function it will search for each constexpr if wich blocks to use by computing the ifs until it founds the wright one. Then it'll declare the function for using only the blocks that have been selected. template void func() { constexpr if (R) printf("true "); else printf("false "); } func will create void func() { printf("true "); } when func will create void func() { printf("false "); } The main reason to do so is that it reduce the need to use SFINAE, It's a simpler way of doing that: template class Func; template class Func { public: static void func() { printf("true "); } }; template class Func { public: static void func() { printf("false "); } }; Func::func(); Func::func();
That's an interesting point of view... personally i tend to prefer simple code to faster-but-complex code because eventually compilers get much better/quicker/smarter for simple code than for complex code.
For library designers, that's worth thinking. I remember painful typename hells when i learnt those template ::value, so i guess i'm more of a user (though i heavily template sometimes)
mmh, seems to be only valid at runtime, which is strange, it should be constexpr... or perhaps i'm missing some rule like "you can't call a constexpr function in a template parameter" godbolt.org/g/xcPX80
What if some expression cannot be evaluated at compile time? E.g. if you put something like t == 1000 in condition? Or constexpr if put restrictment on statement inside? I expect that non-constexpr function will be created. But for some reason I fear that a copy for each time function was called an instance will be added. E.g. one for call with 0 as argument, one for call with 1 and so on. Would be messed up to put __LINE__ to output to check. Also "go vim"!
Amazing! This is why I love C++ so much, just the shear amount of things you can do. You just wrote a program that is completely "run" by the compiler, there is very little "runtime" code. Talk about a huge performance boost. With this you can completely offload the cpu runtime to the compiler when possible. Templates, SFINAE, and Meta-programming for the win! Pretty cool stuff indeed.
The separated function for evaluating the conditions is a nice move, which can be improved with constexpr lambda. :)
It's exciting to see it working. Thanks!
At 8:00 you said "at nine eleven" instead of line eleven
I'd give this comment 1000 internet points for helpfulness. +1
they kind of half-done it with no constexpr switch :)
love your videos jason.
they are pure awesomeness!
Was writing the function "is_both" the only way to make the code work?
IMO you could just have removed the "else" from "else if constexpr(std::is_floating_point::value)".
Fantastic. Looking forward to have this in my compiler. Thanks for another great video.
Many programmers I've spoken to have expressed concerns about compile time of templates. So much so that some refuse to write templates even when it would probably save development time. Do you think constexpr will speed up compile time enough to catch on with these kinds of programmers?
Would it be similar to #ifdef type arguments in speed? Just with the ability to use complex C++ expressions.
Can I use ternary instead of is_both or it could prevent constexpr to be calculated at compiletime? The ternary is (is_integral && ! Is_same ? numeric_limit < number : false
I guess "is_both" can now be easily and more generically implemented in "concepts" in C++20
At the start (say 1:41), how is the code for the function "print_type_info()" compiling even though it's parameter is simply a type ? (ie, there is not variable name for the parameter there ...) ??
it is type with no variable name
void foo(my_type)
is same as
void foo(my_type VariableName)
At around 9:43 you mention the first constexpr if will be compiled, but its nested constexpr if block won't be compiled. I didn't understand that well enough.
Can you elaborate a bit? Thanks.
The idea is that at runtime the conditional branching wont exist. Each time the compiler must instenciate a new declaration of the function it will search for each constexpr if wich blocks to use by computing the ifs until it founds the wright one. Then it'll declare the function for using only the blocks that have been selected.
template
void func()
{
constexpr if (R)
printf("true
");
else
printf("false
");
}
func will create
void func()
{
printf("true
");
}
when func will create
void func()
{
printf("false
");
}
The main reason to do so is that it reduce the need to use SFINAE,
It's a simpler way of doing that:
template
class Func;
template
class Func
{
public:
static void func()
{
printf("true
");
}
};
template
class Func
{
public:
static void func()
{
printf("false
");
}
};
Func::func();
Func::func();
I got it now.
It is basically compile time code path checking so we don't need to do it at runtime.
Thanks! :D
Exactly. It's compile-time coding
Side-note : you can use std::is_same_v and std::is_integer_v instead of the complicated (and old) ::value :-)
That's an interesting point of view... personally i tend to prefer simple code to faster-but-complex code because eventually compilers get much better/quicker/smarter for simple code than for complex code.
For library designers, that's worth thinking. I remember painful typename hells when i learnt those template ::value, so i guess i'm more of a user (though i heavily template sometimes)
mmh, seems to be only valid at runtime, which is strange, it should be constexpr... or perhaps i'm missing some rule like "you can't call a constexpr function in a template parameter" godbolt.org/g/xcPX80
So, static_if did make it after all.
What if some expression cannot be evaluated at compile time? E.g. if you put something like t == 1000 in condition? Or constexpr if put restrictment on statement inside? I expect that non-constexpr function will be created. But for some reason I fear that a copy for each time function was called an instance will be added. E.g. one for call with 0 as argument, one for call with 1 and so on. Would be messed up to put __LINE__ to output to check.
Also "go vim"!
This can potentially replace #ifdef in some instances
is_both would look much better without the if constexpr. It would just be "return std::is_integral::value ... ;"
What terminal theme is it? Looks so crisp. Is the OS the latest Ubuntu?
Do you think constexpr if can be used to replace logic that has do be done in #ifdef now?
IMO, you shouldn't have run the program by executing "./a.out" to show that the results are printed at compile time.
Bruh... 5:51
any one please explain. what is reason behind getting error at 9.02?
The sentence immediately after time offset answers the question. It's because the constexpr if conditions don't short circuit.
I think you have to complicate your code, as part of your habit.