[flagged]
C++ Insights – See your source code with the eyes of a compiler
11–20 of 70 posts
Re: C++ Insights – See your source code with the eyes of a compiler
#12I wish there was a way to show the code that is generated when using co_return or co_await
e.g. https://cppinsights.io/lnk?code=Ly8gaHR0cHM6Ly93d3cuc2NzLnN0...
Re: C++ Insights – See your source code with the eyes of a compiler
#13Honestly, from the title, I expected something that gave actual 'insights' into the compiler, rather than the code. For example, indicating applied and potential (missed) optimizations. But seeing what it was, I was definitely not unpleasantly surprised :) Being able to cut through abstraction is very nice and quite important when you want to understand WHAT you are writing from the machine's perspective (or even in…
I think Haskell creators never meant to have users care about those abstractions. It's more about what, not how, and given its terseness and power, I'd be happy to be a normal user.
Re: C++ Insights – See your source code with the eyes of a compiler
#14I wonder how helpful it is for g++? Myself and my ancient h/w and s/w engineering friends have been having a discussion recently about how the modern C++ language features are generating code that is not readily debugged at the source level. The compiler has always created assembly that implements the feature described by teh high level language, but histoirically these have had a relatively one-to-one relationship w…
Even C doesn't map any longer when taking into consideration -O3, UB, vector units, and compiler replaced standard library calls.
I miss the part of what a modern debug lacks.
Re: C++ Insights – See your source code with the eyes of a compiler
#15Earlier quoted context omitted.
The readme indicates that it uses system headers (G++ libstdc++) by default. Since it's source-to-source, I don't think being based on clang actually matters for anything unless you happen to use GCC-specific extensions. I would also expect clang and gcc to behave similary when cutting through abstraction. I'm not sure, but it also seems like the output code should be able to compile? Then you can probably use g++ fo…
Most of things that used to be g++ specific extensions are in standard nowadays. You can avoid by using a more recent c++ version.
Not really, only a tiny couple of them.
Re: C++ Insights – See your source code with the eyes of a compiler
#16I wonder how helpful it is for g++? Myself and my ancient h/w and s/w engineering friends have been having a discussion recently about how the modern C++ language features are generating code that is not readily debugged at the source level. The compiler has always created assembly that implements the feature described by teh high level language, but histoirically these have had a relatively one-to-one relationship w…
What do you mean exactly? Like the inability of putting a breakpoint on the loop condition of a range-based for loop?
Pretty easy in VC++ debugger.
Re: C++ Insights – See your source code with the eyes of a compiler
#17It looks like a perfect candidate for a vs code extension.
Re: C++ Insights – See your source code with the eyes of a compiler
#18It looks like a perfect candidate for a vs code extension.
I use neovim btw
Re: C++ Insights – See your source code with the eyes of a compiler
#19I wonder how helpful it is for g++? Myself and my ancient h/w and s/w engineering friends have been having a discussion recently about how the modern C++ language features are generating code that is not readily debugged at the source level. The compiler has always created assembly that implements the feature described by teh high level language, but histoirically these have had a relatively one-to-one relationship w…
Even C doesn't map any longer when taking into consideration -O3, UB, vector units, and compiler replaced standard library calls. I miss the part of what a modern debug lacks.
Don't debug -O3, or -O2 for that matter. Debug a separate debug build without optimizations, or don't heavily optimize your release build if you want to debug that (you know that obviously).
Even with optimizations disabled, debugging C++ can be quite painful. Only add a little template stuff to the source code, and a few "zero-cost" methods like indexing operators or cast operators, and it quickly becomes painful to step through code.
There should be a way to avoid stepping through boilerplate methods, but apart from specifying string patterns to exclude methods by name -- not inline with the method but in a separate debugging configuration (which is very very annoying).
The only solution I know is to use C++ features very lightly. Any other practical options?
Check this link and the twitter posts linked there, other well known developers have this issue: https://developercommunity.visualstudio.com/t/std::move-and-...
Re: C++ Insights – See your source code with the eyes of a compiler
#20Earlier quoted context omitted.
Even C doesn't map any longer when taking into consideration -O3, UB, vector units, and compiler replaced standard library calls. I miss the part of what a modern debug lacks.
Don't debug -O3, or -O2 for that matter. Debug a separate debug build without optimizations, or don't heavily optimize your release build if you want to debug that (you know that obviously). Even with optimizations disabled, debugging C++ can be quite painful. Only add a little template stuff to the source code, and a few "zero-cost" methods like indexing operators or cast operators, and it quickly becomes painful to…
Use modern IDEs with features like Just My Code, which already help a lot.
https://learn.microsoft.com/en-us/visualstudio/debugger/just...
Also, there are scenarios where debugging without optimizations isn't an option.
The issue with std::move has been solved for a while and was a VC++ bug, not C++.
https://devblogs.microsoft.com/visualstudio/a-year-of-cpp-im...