Hacker News Reader

Comment by stelonix | Hacker News Reader

I will have to disagree here. Visual Studio's C++ tools are fundamental for any C++ development beyond toy "hello world" and prototypes. I've been a Linux user for 8 years now and my biggest pain is the lack of a proper C++ IDE with decent debugging. Even if you forget an IDE, there are no decent debuggers[0][1].

[0]: https://scattered-thoughts.net/writing/looking-for-debugger/

[1]: https://scattered-thoughts.net/writing/looking-for-debugger-...

View on HN

QtCreator might be worth trying. It's focused on Qt apps, but it's a general C++ IDE. KDevelop is another one. I don't know if these would fit your purposes or not, but I'd be interested in hearing.

I think there is a level of familiarity bias that happens with debugging tools. I could probably get away with making gdb my login shell I live in it so much, and when I find myself using Visual Studio's debugger, I find it incredibly clunky. The things people complain about for gdb (e.g. you can't see the source code for where it is executing) I don't find to be a big deal (I just jump to the correct line in my text editor). Meanwhile, using Visual Studio is a complete pain for me, for reasons that clearly don't matter to people who use Visual Studio all the time (e.g. while possible, running multiple instances of a program side by side is annoying, quickly evaluating arbitrary expressions is more painful, setting data breakpoints is needlessly complicated (do they still ask if it is C or C++?), etc.

I think it must just be one of those things where the tool you use shapes the way you work, and so then when you switch tools, but try to work in the same way, you get frustrated.

I find windbg a good middle ground between the gdb/lldb style and visual studio overload.

source debugging is a minor component of GUI debuggers.

Having a graphical watch window with multiple variables, looking at registers in a different window while stepping through etc. is invaluable to me.

Also stuff like losing mental context because of dumping a long stack in the same window where I was just inspecting disassembly is frigging painful.

But I agree about familiarity bias in most cases.

To be clear, the posts you are referencing are about debugging an executable with no source code available, which is not the normal use case for a programmer.

It seems you have not read the post or you don't have experience with gdb or with Linux debuggers/ide combos. He's debugging zig, but his issues are with the ux and iirc he mentions few zig-specific bugs. I have been through the same ordeals while debugging C++ on Linux. In the end, there's only gdb with a command line interface. Couldn't get any nice IDE with watch, memory view or even simple breakpoints to work. Some have a few of those features but none has all of them working. Eg. if you have a working breakpoint it'll fail to properly inspect STL containers etc.

I'm sure there are many people saying "works on my machine", but it never worked on any of mine, sadly. Visual Studio simply works and has a nice, intuitive interface. Pressing F10 to step over will always be better than typing something in the gdb command line and hitting Enter.

Have you tried CLion?

I'm not sure that Visual Studio is particularly good at debugging zig either...

I haven’t had any trouble doing graphical debugging with VSCode and the C/C++ plugin. I get breakpoints, locals, watch, etc. The one thing I miss from Visual Studio is being able to easily change the watch window display format (e.g. showing a number as hex).

I agree totally. No one else has ever been able to make a debugger as good as Visual Studio. That's why I do all my core development work on Visual Studio, and only use XCode / code blocks for testing on Mac/Linux.

ugh, QtCreator is so much better especially than Xcode, and not even worth comparing to Code::Blocks

but what if you aren't using Qt?

QtCreator is a generic C/C++ IDE, built with Qt. (and since it has language server support nowadays it looks like it's useable for rust, etc). It has a profiling UI, valgrind support, etc etc.

It's also pretty decent for embedded!

Sometimes I feel they should rebrand it, because many people are blocked by the Qt name.

I better check it out then. Thanks.

VS is definitely one of the better C++ IDE's (if you're programming on Windows, at least); but I've found CLion to be a decent alternative on Linux (and macOS, but I just don't like XCode).

I'm curious, have you checked out JetBrain's CLion? while not free, it's pretty much the best CPP IDE out there, as it's usually the case with JetBrain in general.

The C++ debugger for vscode is pretty good, no visual studio but much less utilitarian than gdb.

I use C++ to mostly to develop backend servers. Since I use multiplatform libraries all active development and debugging happens actually on Windows. I maintain parallel project for CodeLite and makefile on Linux. Normally after I satisfied with the results on Windows I just click a button that triggers my build/test/deploy pipeline. From here all happens automatically but if the tests on Linux fail I would then fire up CodeLite to debug and find the reason. Mind you during last year I only had to do it twice. If I add/remove files / libraries this would be another reason to launch CodeLite to adjust Linux project accordingly. In theory I could do this on using CMake but it is simply not worth it for me.

I tried CLion and bugs / crashes with debugging and some other parts (do not remember exactly as it's been a while) prevented me from using it. Was not fond of its sluggishness either.

Reply on news.ycombinator.com