4 ms·

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

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?

cenamus 5mo ago
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?
- usefulcat 5mo ago
  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.
  - pjmlp 5mo ago
    Basically nowadays they ship an interpreter in the box as well.
SuperV1234 5mo ago
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).
varispeed 5mo ago
Why people are still using debuggers? I never felt the need for them when doing TDD.
- mort96 5mo ago
  Because sometimes you have bugs and you haven't narrowed down the cause enough to write a proper test for it?
- pjmlp 5mo ago
  [dead]
- w4rh4wk5 5mo ago
  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 https://www.youtube.com/watch?v=UzD_Ze6zFKA Also, John Carmack's perspective: https://www.youtube.com/shorts/PRE51epznT8 https://www.youtube.com/shorts/PRE51epznT8
  - varispeed 5mo ago
    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.
    - w4rh4wk5 5mo ago
      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.
theICEBeardk 5mo ago
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.
kevin_thibedeau 5mo ago
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.

cenamus 5mo ago

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?

usefulcat 5mo ago
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.
- pjmlp 5mo ago
  Basically nowadays they ship an interpreter in the box as well.

SuperV1234 5mo ago

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).

varispeed 5mo ago

Why people are still using debuggers? I never felt the need for them when doing TDD.

mort96 5mo ago
Because sometimes you have bugs and you haven't narrowed down the cause enough to write a proper test for it?
pjmlp 5mo ago
[dead]
w4rh4wk5 5mo ago
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 https://www.youtube.com/watch?v=UzD_Ze6zFKA Also, John Carmack's perspective: https://www.youtube.com/shorts/PRE51epznT8 https://www.youtube.com/shorts/PRE51epznT8
- varispeed 5mo ago
  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.
  - w4rh4wk5 5mo ago
    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.

theICEBeardk 5mo ago

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.

kevin_thibedeau 5mo ago

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.