Hacker News Reader

Comment by w4rh4wk5 | Hacker News Reader

I've been wondering about debug-ability of code using reflection. X-Macros are quite annoying to step through in most debuggers, though possible. While the code in the first example is evaluated fully at compile-time, how would you approach debugging it?

View on HN

The answer is being debated at the moment in c++ papers and building on experience from other languages with extensive compile time evaluators like D. One thing that is happening is that we will get compile time exceptions (a paper for that is aiming to add this to the language in c++29 has come out) which may help us in reporting problems. Which will be important as there is also a lot of papers and talk about an extension of reflection allowing for better output generation which as far as I know was deferred until reflection had been accepted.

But there is also good news that with the advent of JIT like components for compile time evaluation in progress and the like of CLion having the beginnings of a compile debugger in combination with concepts there is a chance some help is available and on the way.

However right now you have to rely on compiler errors and static_asserts which is not ideal of course.

Nothing that makes it straightforward. Testing via `static_assert` is a good strategy, but it's not debugging. I believe there are some ways of printing custom diagnostics during compilation, but I am not aware of any step-by-step debugging tool that runs at compile-time.

In practice, I haven't really needed to ever debug `consteval` functions -- it's quite easy to get the right behavior down thanks to `static_assert`-based testing and thanks to the fact that they do not depend on external state (simpler).

Keep macro generated code isolated in self-contained wrapper functions that just return a static object corresponding to an argument. Then you can treat them like black boxes that never fail and never need to be stepped over.

I mean it's still C++ that's compiled and executed, surely the compiler would be able to provide a way to hook into that?

I don't recall the source, but I don't believe most (any?) c++ compilers implement compile-time code evaluation by compiling and running code.

For one thing they are required to disallow all undefined behavior for compile time execution, and some forms of UB only occur when the code is run.

Basically nowadays they ship an interpreter in the box as well.

Why people are still using debuggers?

I never felt the need for them when doing TDD.

It's not that people are _still_ using debuggers; it's that people have actually discovered debuggers and workflows that are more productive than adding print statements, recompiling, and rerunning the program.

Casey has been talking about this some time ago: https://www.youtube.com/watch?v=UzD_Ze6zFKA

Also, John Carmack's perspective: https://www.youtube.com/shorts/PRE51epznT8

If you need to step with debugger, it means you are probably not understanding the code and cannot step through in your mind. Good test suite eliminates the need to debugger too.

Yeah, in my field this approach is pretty much infeasible.

Typically, I am given an ancient code base that is full of bad decisions, hard to read code and no tests in sight. Sometimes there are assertions, if I am lucky. It's impractical to create a reliably test suite, or rewrite everything from scratch.

Here, I heavily rely on a debugger just to make sense of the code. Sure, I'd wish that all of this code would just be sparkling clean, easy to read, free of UB, etc. But that's not the reality I work in, and good debugger is my number one tool getting the job done.

And don't even get me started on dealing with closed source implementations where all you could read is disassembly.

Because sometimes you have bugs and you haven't narrowed down the cause enough to write a proper test for it?

Reply on news.ycombinator.com