5 ms·

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 freaki

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.

pjmlp 2y ago
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.
motorest 2y ago
> 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?
menaerus 2y ago
"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.
- core-explorer 2y ago
  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?
TinkersW 2y ago
Everything you asked for has existed for like decades..
- whatever1 2y ago
  ? Which IDE hides the types in the source code to make it more compact?
  - CuriousCosmic 2y ago
    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.
    - whatever1 2y ago
      What the hell is a skill issue? Open a random GitHub repo. Do all of the authors of C++ have skill issues except you ?
      - motorest 2y ago
        > 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?
    - Spongman 2y ago
      not in the source code, in the debugger UI (callstack, watch/locals, etc...)
      - CuriousCosmic 2y ago
        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.

pjmlp 2y ago

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.

motorest 2y ago

> 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?

menaerus 2y ago

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

core-explorer 2y ago
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?

TinkersW 2y ago

Everything you asked for has existed for like decades..

whatever1 2y ago
? Which IDE hides the types in the source code to make it more compact?
- CuriousCosmic 2y ago
  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.
  - whatever1 2y ago
    What the hell is a skill issue? Open a random GitHub repo. Do all of the authors of C++ have skill issues except you ?
    - motorest 2y ago
      > 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?
  - Spongman 2y ago
    not in the source code, in the debugger UI (callstack, watch/locals, etc...)
    - CuriousCosmic 2y ago
      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.