5 ms·
If you really want that, it seems better to provide them properly like Rust proc-macros than to provide them in C++'s awful half-baked form.
by roca 6y ago
If you really want that, it seems better to provide them properly like Rust proc-macros than to provide them in C++'s awful half-baked form.
- saagarjha 6y agoRust’s compile-time meta programming is lacking at the moment, unfortunately. It doesn’t have const generics yet, and the standard library is a bit anemic and this extends to the type programming utilities as well.
- adev_ 6y ago> If you really want that, it seems better to provide them properly like Rust proc-macros than to provide them in C++'s awful half-baked form. - C++-17 (-20) constexpr is one century in advance in front of rust macro in term of power and what you can do with it. It is not even comparable. - C++20 compile time execution is currently pretty clean and has nothing to do with this template mess shown here. Definitively not "half baked".
- tines 6y agoYes. From what I understand, Rust's macros/generics are not Turing complete.
- steveklabnik 6y agoThey are. Procedural macros especially are a function that takes tokens and returns tokens, and have the full language at their disposal.
- tines 6y agoAh interesting. But I imagine that token-based macros don't give you access to the types in the program being compiled do they? i.e. a c++ template can tell when two types are the same but a token level macro wouldn't be able to do that I think.
- steveklabnik 6y agoCorrect.
- roca 6y agoCompile-time function evaluation is quite a different feature from macros. Most of what you would do with macros (e.g. output entirely new definitions of functions, types, etc) can't be done with constexpr at all.
- tines 6y agoAnd vice-versa.
- pjmlp 6y agoC++'s awful half-baked form comes with 40 years of IDEs, libraries, GUI tooling, OS and GPGPU SDKs, so while I do like Rust, I rather use C++ for the time being, as clunky as it might be.