C++ macros can only take types and numbers (until variadic), and writing any code to operate on those inputs is challenging.
It's not too bad :)
(My parenthetical "maybe" is that I don't think compilers have to compute constexpr expressions at compile time. The compiler will be forced to when such expressions are used in contexts that require values at compile time. But I think it would be permissible for a compile to defer computation of a constexpr to runtime if the value isn't needed until runtime.)
#include <iostream>
consteval long factorial (int n) {
if (n == 0) return 1;
return n * factorial(n - 1);
}
int main() {
std::cout << factorial(7) << std::endl;
}
-- https://godbolt.org/z/TWe11hM6j
Nicely put 5040 in ESI register at compile time.
Granted, C++ isn't Lisp, but already has quite a room for creativity at compile time, and C++26 might finally have compile time reflection as well.
I don't see it here. This looks like compile-time execution to compute values. If it would be a macro, it could return source code.
Example of a library that generates serialization code, https://github.com/getml/reflect-cpp
As mentioned the ongoing C++26 proposal with produce the desired source code at compile time, thus reducing the amount of code of libraries such that one.
The term "macro" is overloaded. In a typical Lisp they are generating source as data, not just constant values. Lisp macros also work in interpreters and they can use arbitrary language features, incl. creating side effects or accessing external data sources.
--
The C++ standard is consistent in how it uses "macro," and it's strictly about the preprocessor kind of macros. "Metaprogramming" is also used in the standard, though not as extensively or rigidly (only 8 times in N4950), but both in the specification and colloquially it's more than just slapping consteval on a function.
Libraries like Boost.Preprocessor can’t be taken as an example of “cutting edge” preprocessor metaprogramming. It set a very low bar, and IMO has stifled a lot of developer creativity.
[1] https://github.com/rofl0r/chaos-pp/tree/master/chaos/preproc... [2] https://github.com/rofl0r/order-pp/blob/master/example/fibon...
The reason that they remained niche is that at the time MSVC had an extremely non confirming preprocessor and advanced PP libraries just weren't viable there.
Boos.PP was the most advanced you could get while staying portable.
There is no reason to encode value computations using template expansion anymore. Even a lot of type level computation can be done via plain function calls and decltype. "Old school" recursive template installation is really only needed when you need specifically the capability to pattern match on types of template specialization.
[1]> (defmacro factorial (n)
(labels ((fact (m)
(if (= m 0)
1
(* m (fact (1- m)))))) `,(fact n)))
[2]> (factorial 1000) [3]>
for the c++ version i don't think even `unsigned long long` can accommodate results from larger than approx. 21! or thereabouts.
https://www.forrestthewoods.com/blog/using-jais-unique-and-p...
I share it not to say “use Jai instead of C++/Rust”. But to instead say “templates and macros suck and it’d be great if Rust or other language copied good ideas into their ecosystem”.
Rust certainly led the charge with the borrow checker. Why not do better than macros and templates and generics?
Boost.Units is 20 years old. There is an unit system built in in c++11 just for duration, but shows what it can be done. There is no reason ever to use enable_if since C++20.
> Here's where Jai has a feature I've never seen before. I'm sure it exists in some language, but certainly not C++ or Rust!
The feature is #modify which is not needed in C++; for historical reasons, typically type level metaprogramming still different from value level, but it is not hard:
https://gcc.godbolt.org/z/PbzKeh38a
(defmacro factorial (n)
(labels ((fact (m)
(if (= m 0)
1
(* m (fact (1- m))))))
`,(fact n)))
Thus, this is okay:
(defmacro factorial (n)
(labels ((fact (m)
(if (= m 0)
1
(* m (fact (1- m))))))
(fact n)))
CL-USER > (macroexpand-1 '(factorial 10))
3628800
TNot to dog on C++ unfairly, CTE is pretty neat after all.
Funnily enough, PGs “On Lisp” has some really neat macros in it that demonstrate capabilities that just can’t be replicated with template based macros, iirc.
I can visualize this metaphor just fine, but I can't tell why it's useful. Can you make this concept more concrete?
Within the "program dimension" there is just no way to run code conditionally without an if, no matter how much you move left and right, you are constrained. It is only possible by using the "higher dimension".
One way to see this would be to do something like:
(defmacro print-value (a) (print a) a)
(print (print-value 1))
(print (print-value (+ 1 2))
;; output
1
1
(+ 1 2)
3
The value bound to a inside the macro is the unevaluated form (the first and third items printed out). In this case the macro itself is just the identity macro other than its print effect so it returns the original form, which is why we get 1 and 3 printed as well.
Here's an example of processing (very primitive) the unevaluated form to produce something new:
(defmacro infix (a op b)
`(,op ,a ,b)) ;; alternatively: (list op a b)
(print (infix 10 + 20))
;; output
30
https://tio.run/##fZDBDoMgEETvfsXculh7qP2hImJKSpUgSf17uiqJ1V...
(defmacro infix (expr)
(labels ((walk (expr)
(cond
((listp expr) `(,(second expr) ,(walk (first expr)) ,(walk (third expr))))
(t expr))))
(walk expr)))
You could use this to get constexpr like behavior but once you do that you run into problems, you can't do this for example:
(defmacro foo (a b) (+ a b))
(foo (+ 1 2) (+ 3 4)) ;; error
(let ((a 1) (b 2)) (foo a b)) ;; error
(foo 1 2) ;; => 3
(defmacro foo (a b) (+ (eval a) (eval b))
So C++ constexprs are less than Lisp macros, but if you want to use Lisp macros to do the same thing as constexprs you have to do more work. Check out On Lisp and Let Over Lambda for two books that go deep into macros in Common Lisp.
[0] I honestly don't know why you'd want to do this, but technically it's valid to do:
(defmacro foo () (some form to return))
(macroexpand '(foo))
;; => (some form to return)
def cond[T](p: Boolean, a: => T, b: => T): T = if (p) a else b
https://docs.scala-lang.org/tour/by-name-parameters.html
You can do the same in Java with more syntax.
The real power of Lisp macro is that you introspect the code and modify it, not that you can alter evaluation eagerness.
Think how much common code can exist in a software but cannot be refactored to a functions because it will have too many variables. Or the multiple problems with classes tree and overloading. Macros let you solve that.
I'm skeptical of this. Sounds ugly.
Interesting...can you give an example of a macro that solves this refactoring problem?
It's a bit hard to explain for me (English is not my native language). But it's the difference between coding a solution with all the edge cases baked in and coding an archetype that let you add your own cases. With functions, you abstract common algorithms, with macros you abstract common architecture.
[0] https://github.com/jwiegley/use-package/blob/a6e856418d2ebd0...
The correct analogue for Lisp macros is not C++ templates, but the C preprocessor itself. Specifically, a Lisp macro gets to take a particular section of code and change it as it wishes, with everything already conveniently tokenized for the programmer's convenience. Imagine if you could just write your own C preprocessor as part of your program and have the compiler automatically execute it on specific program areas that want your preprocessing.
Rust macros work similarly to this, the main difference being your syntax needs to be tokenizable as Rust instead of Lisp. But they're also rather powerful. So, for example, in Rust you only have one object system which has structs, traits, and very limited higher-kindedness[0]. But there's plenty of other object systems Rust would like to interop with: Objective-C, Swift, COM, and C++ among others.
The canonical way of doing this in Rust is to write a macro[1] that takes your class definition and converts it into a series of structs, traits, and/or function pointers that suitably interop with the foreign code. Code outside the macro then can reference the class created by the system.
If you don't have macros, your other options are:
- Metaclasses, which are the canonical way in Python of doing foreign object interfaces, though with an added wrinkle: multiple inheritance from classes of different metaclasses requires writing a combined metaclass that does both. In macros you usually just can't mix them like that, though I doubt you'd need to define a single class accessible from, say, both Objective-C and Windows COM.
- Write your own damned preprocessor. This is what Qt did with MOC (metaobject compiler) to get signals and slots[2]. If C++ had macros, Trolltech probably would have written MOC as a macro instead of a separate build step with a separate C++ tokenizer.
[0] A concept which I will not be explaining in this post, but it has to do with things like generic associated types which were needed for lifetime bounds on async traits
[1] Usually a "procedural macro", which is different from the pattern-matching macros Rust usually teaches in ways that don't matter here
For example, imagine that you want to program with state machines and you need a short notation for that in your programming language. In Lisp you could design a syntax for a state machine and the Lisp macro would transform state machine descriptions into the code used to implement them -> the generated code typically will be longer and full of implementation details -> in the state machine description one would only specify what's necessary. The Lisp macro will do the code transformation from using the new control structure to the implementation of the control structure.
Thus one can view Lisp as a programmable programming language.
Aside the complexity, the main thing C++ currently lacks is code introspection to modify existing code without using an ad-hoc DSL. I think that even the reflection proposals do not go as far as actually introspecting code.
Being able to write macros means I can write code the SHAPE that I want, regardless of underlying implementation, but I can also manipulate other equivalently meta forms as well as primitives, which sets it at a higher level than templates.
I’m terrible at explaining, but if you’ve never tried lisp I strongly and wholeheartedly suggest you give it a try. For learning, I’d recommend Racket. Try and get at least as far as syntax-rules and syntax-case.
Anyways, sorry for the bad explanation!
HN discussion: https://news.ycombinator.com/item?id=31199992