Even with IDEs, reading C++ source code and compiler/debugger output consumes so much mental overhead for no reason. It is so ugly.
Do I need to see the freaking train-long types of every single thing in my entire codebase at all times? No.
We should have an option to only reveal types of specific items. For example I could hover over a variable and then reveal to me that it is a boost::beast::basic_flat_buffer<std::allocator<char> >.
By default types should be hidden, you care about the logic flow of your program. If you are triaging types, then they are still there for you.
> We should have an option to only reveal types of specific items. For example I could hover over a variable and then reveal to me that it is a boost::beast::basic_flat_buffer<std::allocator<char> >.
Which IDE do you use that does not support that already?
"Here is what I want from a future debugger when working on a hard to debug problem:
It should be able to show me the source code
It should be able to show me the IR
It should be able to show me disassembly
I want to be able to step through the program on each of these levels of abstraction, depending on the function and the problem."
You don't need a "future debugger" since current debuggers can do all of those already so I am not sure what the rant is about. Probably a skill issue.
I know how to see the source in my debugger and I know how to see the disassembly. Which IDE will show me the compiler's internal IR if I want something in between?
I'm sure, but could you point me in the direction of these tools?
I would love to supply GDB with some aliases for much used templates so I can have less verbose outputs
I'm not a C++ dev, but here are a couple of IDEs that I know have strong C++ support and much more user friendly debugging than using GDB via the command line...
At least in lldb (the LLVM equivalent of GCC's gdb however gdb should also do this), types should be shown as their declared type rather than the fully expanded resolved type. At least as long as you are running with debug information attached.
This means if you are declaring types with `using` declarations they should be showing up as that type in the debugger.
When you have async, lambdas, generics, functional programming, etc... then traditional debugging becomes a nightmare. Talk about debugging to someone who makes heavy use of these features and they will usually avoid the subject and talk about logging, unit tests, etc...
C++ as a language is not the worst here. But it mostly depends on how you use it. Do "C with classes" and you will be fine, code like the author does, with boost and all that, and it will be horrible. It is not that his code suck, it is that he is using a paradigm that makes it hard to use a debugger. Maybe he should consider logging and unit tests :)
This is not a criticism of the author, in fact, it shows that he takes debugging seriously and considers practical problems. The debugging situation is quite terrible right now, and it is great seeing that people are trying to do something about it. And yes, it is hard.
With zero reference to IDE based tooling, which exists for 30 years for a reason.
Even with IDEs, reading C++ source code and compiler/debugger output consumes so much mental overhead for no reason. It is so ugly.
Do I need to see the freaking train-long types of every single thing in my entire codebase at all times? No.
We should have an option to only reveal types of specific items. For example I could hover over a variable and then reveal to me that it is a boost::beast::basic_flat_buffer<std::allocator<char> >.
By default types should be hidden, you care about the logic flow of your program. If you are triaging types, then they are still there for you.
> We should have an option to only reveal types of specific items. For example I could hover over a variable and then reveal to me that it is a boost::beast::basic_flat_buffer<std::allocator<char> >.
Which IDE do you use that does not support that already?
"Here is what I want from a future debugger when working on a hard to debug problem:
It should be able to show me the source code
It should be able to show me the IR
It should be able to show me disassembly
I want to be able to step through the program on each of these levels of abstraction, depending on the function and the problem."
You don't need a "future debugger" since current debuggers can do all of those already so I am not sure what the rant is about. Probably a skill issue.
I know how to see the source in my debugger and I know how to see the disassembly. Which IDE will show me the compiler's internal IR if I want something in between?
Everything you asked for has existed for like decades..
I'm sure, but could you point me in the direction of these tools? I would love to supply GDB with some aliases for much used templates so I can have less verbose outputs
I'm not a C++ dev, but here are a couple of IDEs that I know have strong C++ support and much more user friendly debugging than using GDB via the command line...
https://www.jetbrains.com/clion/ https://visualstudio.microsoft.com/
? Which IDE hides the types in the source code to make it more compact?
In the source code? That's a skill issue not an IDE issue. If you have ugly types, you fix that in source code with `using` declarations.
What the hell is a skill issue? Open a random GitHub repo. Do all of the authors of C++ have skill issues except you ?
> What the hell is a skill issue? Open a random GitHub repo.
Can you be a bit clear? I rarely see any project whose authors express types with fully qualified names. What exactly are you talking about?
not in the source code, in the debugger UI (callstack, watch/locals, etc...)
At least in lldb (the LLVM equivalent of GCC's gdb however gdb should also do this), types should be shown as their declared type rather than the fully expanded resolved type. At least as long as you are running with debug information attached.
This means if you are declaring types with `using` declarations they should be showing up as that type in the debugger.
See, a good example of lacking IDE experience, that is just one of many Visual Studio debugger capabilities.
Which is about decade old feature by now.
most GUI debuggers are just a front for gdb, and have all the issues he's talking about in the article.
But is it really a C++ problem?
When you have async, lambdas, generics, functional programming, etc... then traditional debugging becomes a nightmare. Talk about debugging to someone who makes heavy use of these features and they will usually avoid the subject and talk about logging, unit tests, etc...
C++ as a language is not the worst here. But it mostly depends on how you use it. Do "C with classes" and you will be fine, code like the author does, with boost and all that, and it will be horrible. It is not that his code suck, it is that he is using a paradigm that makes it hard to use a debugger. Maybe he should consider logging and unit tests :)
This is not a criticism of the author, in fact, it shows that he takes debugging seriously and considers practical problems. The debugging situation is quite terrible right now, and it is great seeing that people are trying to do something about it. And yes, it is hard.
Does rust do it any better? don’t they have similar weird symbol names?
Just curious…
C++ itself is a nightmare
> C++ itself is a nightmare
Only if your nightmare is writing software using anything at all.