C++ Insights – See your source code with the eyes of a compiler • Hacker News Board

Re: C++ Insights – See your source code with the eyes of a compiler

#51

Post by jstimpfle » Sat, Apr 06, 2024, 8:42 PM UTC

otabdeveloper4 wrote: post #50

flohofwoe wrote: post #46

Earlier quoted context omitted.

Frankly, that's stupid advice. Typically you have at least two build modes, debug and release. Debugging without optimization is easier because the source code maps to the compiler output, also a program without optimizations behaves the same as with optimizations, unless you put undefined behaviour into your code (should be a rare thing for an experienced programmer) or hit a compiler bug (also quite rare).

> Typically you have at least two build modes, debug and release. Legacy cargo-cult holdover from the 1980's. No real reason for it today. > also a program without optimizations behaves the same as with optimizations Not when you want to debug it.

That's a really interesting mix of wild claims and plain wrong statements.

Re: C++ Insights – See your source code with the eyes of a compiler

#52

Post by donadigo » Sat, Apr 06, 2024, 9:43 PM UTC

corysama wrote: post #7

C++ Insights is available online at https://cppinsights.io/ It is also available at a touch of a button within the most excellent https://godbolt.org/ along side the button that takes your code sample to https://quick-bench.com/ Those sites and https://cppreference.com/ are what I'm using constantly while coding. I recently discovered https://whitebox.systems/ It's a local app with a $69 one-time charge. And, it only…

I'll add to that my own Visual Studio extension that improves runtime debugging by showing you which lines are actively executing and what changes happened line-by-line: https://d-0.dev It integrates with the VS debugger completely and does not require any changes to one's codebase. It's also available on the marketplace if you want to try it out: https://marketplace.visualstudio.com/items?itemName=donadigo...

Re: C++ Insights – See your source code with the eyes of a compiler

#53

Post by azmr » Sat, Apr 06, 2024, 11:53 PM UTC

corysama wrote: post #7

C++ Insights is available online at https://cppinsights.io/ It is also available at a touch of a button within the most excellent https://godbolt.org/ along side the button that takes your code sample to https://quick-bench.com/ Those sites and https://cppreference.com/ are what I'm using constantly while coding. I recently discovered https://whitebox.systems/ It's a local app with a $69 one-time charge. And, it only…

Hey, thanks for the mention of WhiteBox! I'm the lead dev on it.

The currently-available version is focused on a "write-based" workflow for C and a subset of C++: JIT-compiling, running and auto-debugging the function you're working on in the background whenever you edit it.

It shows a timeline of how the data in your function changes, with the intent being to give you feedback as immediately as possible.

We're currently working on a "read-focused" workflow, which is basically about making WhiteBox also work as a timeline debugger (for EXEs compiled from any language) with a few extra tricks up its sleeve...

Feel free to ask any questions either here or on our discord: https://chat.whitebox.systems

Re: C++ Insights – See your source code with the eyes of a compiler

#54

Post by CyberDildonics » Sun, Apr 07, 2024, 3:38 AM UTC

otabdeveloper4 wrote: post #50

flohofwoe wrote: post #46

Earlier quoted context omitted.

Frankly, that's stupid advice. Typically you have at least two build modes, debug and release. Debugging without optimization is easier because the source code maps to the compiler output, also a program without optimizations behaves the same as with optimizations, unless you put undefined behaviour into your code (should be a rare thing for an experienced programmer) or hit a compiler bug (also quite rare).

> Typically you have at least two build modes, debug and release. Legacy cargo-cult holdover from the 1980's. No real reason for it today. > also a program without optimizations behaves the same as with optimizations Not when you want to debug it.

I'm not sure where you got these ideas, but there are tons of benefits to debug builds like catching out of bounds lookups on vectors the moment they happen and faster compilation.

It's bizarre that you don't realize everyone works this way.

Not when you want to debug it.

I think you're mistaking debug information not lining up with your program for different behavior, but these are not the same thing.

Re: C++ Insights – See your source code with the eyes of a compiler

#55

Post by mgaunard » Sun, Apr 07, 2024, 10:11 AM UTC

JonChesterfield wrote: post #34

mgaunard wrote: post #29

Earlier quoted context omitted.

You need to be able debug optimized builds. That's a requirement of the real world if you're a software engineer. Just learn how to use gdb, it's quite capable.

The complaint above isn't that gdb is hard, it's that the binary with debug info doesn't correlate very well with the source code after optimisations. Bugs tend to disappear on me when I change the optimiser flags or run the thing under gdb though. I've also had a program valgrind-clean that segfaults when run without valgrind. It's a confusing world out there.

Debugging optimized binaries is harder than debugging non-optimized ones, and requires more advanced debugging skills and gdb knowledge.

There is a reason why crash dumps on optimized builds used to be called "guru meditation".

One useful skill to get started is learning how to get at data and print it through various levels of complex C++ data structures, which might require leaning on the python API to stay sane.

Re: C++ Insights – See your source code with the eyes of a compiler

#56

Post by mgaunard » Sun, Apr 07, 2024, 10:12 AM UTC

CyberDildonics wrote: post #54

otabdeveloper4 wrote: post #50

Earlier quoted context omitted.

> Typically you have at least two build modes, debug and release. Legacy cargo-cult holdover from the 1980's. No real reason for it today. > also a program without optimizations behaves the same as with optimizations Not when you want to debug it.

I'm not sure where you got these ideas, but there are tons of benefits to debug builds like catching out of bounds lookups on vectors the moment they happen and faster compilation. It's bizarre that you don't realize everyone works this way. Not when you want to debug it. I think you're mistaking debug information not lining up with your program for different behavior, but these are not the same thing.

Debug/sanitized builds are for unit tests.

Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.

Re: C++ Insights – See your source code with the eyes of a compiler

#57

Post by CyberDildonics » Sun, Apr 07, 2024, 1:09 PM UTC

mgaunard wrote: post #56

CyberDildonics wrote: post #54

Earlier quoted context omitted.

I'm not sure where you got these ideas, but there are tons of benefits to debug builds like catching out of bounds lookups on vectors the moment they happen and faster compilation. It's bizarre that you don't realize everyone works this way. Not when you want to debug it. I think you're mistaking debug information not lining up with your program for different behavior, but these are not the same thing.

Debug/sanitized builds are for unit tests. Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.

Debug/sanitized builds are for unit tests.

What about just compiling and running your program after you make a change or get a crash?

Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.

Right... What's your point? This scenario doesn't overlap with regular iterations. Normal workflow and a crash after a program is distributed are two separate things.

Re: C++ Insights – See your source code with the eyes of a compiler

#58

Post by flohofwoe » Sun, Apr 07, 2024, 2:13 PM UTC

mgaunard wrote: post #56

CyberDildonics wrote: post #54

Earlier quoted context omitted.

I'm not sure where you got these ideas, but there are tons of benefits to debug builds like catching out of bounds lookups on vectors the moment they happen and faster compilation. It's bizarre that you don't realize everyone works this way. Not when you want to debug it. I think you're mistaking debug information not lining up with your program for different behavior, but these are not the same thing.

Debug/sanitized builds are for unit tests. Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.

Postmortem debugging on production builds and without debug info is just harder (depends on how much postmortem info your bug report system provides, and at least on Windows it still makes sense to create a PDB file and archive that inhouse to associate that with the minidump you're getting from the bug report, slightly mismatched debug info is still much better than no debug info at all). A production build crash doesn't mean that the symptoms are not reproducible on a debug build, and investigating the debug build after the bug has been reproduced is a lot more convenient.

Also a lot more bugs show up and are already fixed during development and never even make it to CI or even out into the wild. That's were debug builds and debuggers are most useful (during the initial development phase).

Sometimes I really have a feeling that software development is moving backward in time (shakes head). Debuggers are incredibly poweful tools, use them!

Re: C++ Insights – See your source code with the eyes of a compiler

#59

Post by mgaunard » Sun, Apr 07, 2024, 3:26 PM UTC

flohofwoe wrote: post #58

mgaunard wrote: post #56

Earlier quoted context omitted.

Debug/sanitized builds are for unit tests. Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.

Postmortem debugging on production builds and without debug info is just harder (depends on how much postmortem info your bug report system provides, and at least on Windows it still makes sense to create a PDB file and archive that inhouse to associate that with the minidump you're getting from the bug report, slightly mismatched debug info is still much better than no debug info at all). A production build crash do…

Of course you use the debugger to debug the core.

Doesn't change the fact it's completely unrealistic to expect that you can do that with a full debug build.

The industry has moved towards software as a service, and sometimes your service crashes and you need to figure out why.

Even if you want to turn the problem into a regression test that you can run a debug build against, you'll still need to look at the core of the optimized build to figure out what happened to begin with.

Re: C++ Insights – See your source code with the eyes of a compiler

#60

Post by mgaunard » Sun, Apr 07, 2024, 3:28 PM UTC

CyberDildonics wrote: post #57

mgaunard wrote: post #56

Earlier quoted context omitted.

Debug/sanitized builds are for unit tests. Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.

Debug/sanitized builds are for unit tests. What about just compiling and running your program after you make a change or get a crash? Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario. Right... What's your point? This scenario doesn't overlap with regular iterations. Normal workflow and a cra…

The crash when your program is distributed is the normal workflow. What matters is that your program runs flawlessly in its distributed environment, not that your test suite passes locally.

Testing is but a proxy to achieve the true goal, and is far from perfect.