Question Details

No question body available.

Tags

c++ c visual-studio gcc terminal

Answers (10)

October 29, 2025 Score: 5 Rep: 38,264 Quality: Low Completeness: 10%

If your primary language is in fact C rather than C++, it may be worth noting that Visual Studio is going to lag behind GCC in terms of standards compliance, possibly in ways that will cause you problems.

October 29, 2025 Score: 4 Rep: 34,895 Quality: Medium Completeness: 60%

Like, of course I can't debug entirely in the terminal.

My small scale C programming for a PC is done entirely with a good text editor, the terminal, and running GCC or MSVC's CL from a batch file (to make the options simple to repeat), perhaps with a makefile for something a bit more complex that involves the GUI. The debug tools are my brains, divide & conquer, occasional printf() to see values, and intuition from experience.

I also build in run-time checks with conditional compilation whenever there might be out-of-range array indexing, divide by zero, etc etc. Another thing is to build the program in tiny steps, check it, stretch it, correct it and continue. Perhaps with dummy functions or over-simplification while I focus on one area, so there is always a functioning program to run.

Expanding on that, if my program is supposed to input X and output Y, it does not even attempt to output Y until it can input X and output X. And then each stepping stone between X and Y. They say about climbing a mountain, that you can't go directly to the top. You can only do it by setting stages to reach. So it's as much about development techniques as debugging techniques, and the right plan makes the debugging easier too.

I prefer to keep the tool chain as small as possible, but for larger projects the IDE is essential. And for something like an Android app, impossible for me to make even a simple "Hello, World!" without.

November 1, 2025 Score: 2 Rep: 1 Quality: Low Completeness: 50%

is there a debug functionality outside a fully fleshed-out IDE?

Firstly, Visual Studio isn't the only IDE in existence. Secondly, for most code editors you can set up some sort of a debugger interface.

of course I can't debug entirely in the terminal

You can. I highly recommend familiarizing yourself with gdb - the OG command-line debugger. I also suggest you check out cgdb - a TUI (text user interface) debugger based on gdb. Useful stuff and easy to set up!

Is it viable to code outside an encapsulating IDE such as Visual Studio, with standalone replacements for the features that an IDE provides?

This is something that everyone discovers for themselves. I suggest you try out both - creating your own "IDE" from replacements and using an actual IDE. See what you like more.

But, on the topic of Visual Studio, what I want to recommend against is fully relying on Visual Studio's solutions as your main method of building applications, because that limits you to Windows apps. If you are planning on building closs-platform apps, I suggest you also learn CMake in case you haven't already. CMake can generate both Visual Studio solutions and also Makefiles (that you use to build stuff on UN*X systems, for example). Might be off-topic, but I just thought I'd throw it out there

October 29, 2025 Score: 1 Rep: 192,932 Quality: Medium Completeness: 30%

is Visual Studio worth the annoyance that it is?

I'm uncertain what annoys you about Visual Studio, especially considering that you're presently using VSC. Based on the rest of your post, I guess that might have to do with how integrated into it the various development tools are. The integration is kinda the point of an IDE (as opposed to a mere editor), and most developers who use one wouldn't have it any other way.

An example of an honest concern that I have is: is there a debug functionality outside a fully fleshed-out IDE?

Visual Studio does provide some command-line tools, and I think a debugger is among them.

Like, of course I can't debug entirely in the terminal,

Why not? That's the traditional way. GUI debuggers have some convenience advantages, but there's nothing fundamental that they can do but a command-line debugger cannot.

but is there a debug tool that only does that — just helps debug and nothing else?

Visual Studio does provide some command-line tools. I think a more or less traditional debugger is one of them.

my question, rounded up, is: Is it viable to code outside an encapsulating IDE such as Visual Studio, with standalone replacements for the features that an IDE provides?

Sure. People wrote programs, including very large and complex ones, before IDEs were much of a thing. Some still prefer to work without IDEs. Gcc, make, and gdb FTW! I suspect, though, that these are mostly people like me, who consider it one of the major advantages of a GUI desktop that they can have many terminal windows open on it at the same time.

If you're not interested in the tool integration aspect of an IDE, then I guess the main reason to buy Visual Studio would be to get the Microsoft development tools bundled with it, including the command-line tools. Those would be more natural (or at least more native) for developing WinAPI programs than are the Windows-adapted GCC toolchains.

But as long as you're satisfied with the development tools you're using now, I don't see much reason to spend money on VS.

October 29, 2025 Score: 1 Rep: 58,159 Quality: Low Completeness: 50%

OMG, there are a bunch of IDEs beside VS Code and Visual Studio. For example there is Netbeans, IAR Electronic Workbench, CodeBlocks and others. IMHO, Visual Studio debugger is nice because it is integrated tightly with Visual Studio. The gdb debugger runs in the terminal. Many IDEs have integrated with gdb, trying to visualize it.

My coworkers like Visual Studio Code because it integrates with different compilers and debuggers. I'm old-fashioned and like Visual Studio for medium to large PC applications, IAR Electronic Workbench for the ARM Embedded systems and g++/gdb for small programs.

FYI, the Visual Studio Community edition is free, but has some limitations (like publishing).

November 4, 2025 Score: 1 Rep: 234,581 Quality: Low Completeness: 0%

I have a 25K line C project that was written almost entirely using vi with gdb for debugging.

You don't necessarily need a GUI to do debugging, just good tools.

October 31, 2025 Score: 0 Rep: 12,668 Quality: Medium Completeness: 30%

Myself, I only use the free Visual Studio edition, not the "full" one. Mostly interested in the C++ compiler and the debugger.

My CMake setup supports both Windows and Linux builds -- which is a bit tricky at times, but since the initial setup work it's mostly about adding new sources, which is much more convenient now compared to having two distinct build systems (initially, I used cmake for Linux and a VisualStudio-solution for Windows).

Along the same lines, I want to look into getting vcpkg for the Linux build as well, instead of having a "ReadMe" about which packages to install on the system. It would also solve the problem of Debian always having packages that are somewhere between outdated and very outdated :-)

I use g++ to compile for Linux, and VisualC++ to compile for Windows. VC++ has the advantage that it is the "native" compiler for Windows; it can directly work with the Microsoft Windows SDK and produces all the debug-info that the VisualStudio debugger needs. Also, the FSF hates Windows -- so their so-called ports are pretty rubbish.

In addition, VC++ is completely unrelated to g++ -- sometimes, one of them complains about a problem that the other did not notice. While I still can't guarantee that the portable part of the code is 100% standards-compliant, having 2 compilers accept it is better than just 1 (Linux- and Windows-specific sources are only fed through one compiler, obviously).

It also happens that an error message that's completely mystifying on one compiler turns into a simple "oh, that's what it's complaining about... why didn't you just say so" on the other.

I might even be adding clang++ as a third option, but I'm not sure how well this can coexist with g++ on Linux, and it's also trying to mimick g++ shenanigans so it's likely less useful for catching portability issues.

In general, even if this weren't meant to be portable, I generally prefer the native solutions if at all possible. g++ on Windows feels like a bad idea to me. Of course, this would change if Microsoft killed the free edition, unless Windows-g++ turned out to be unbearable.

October 30, 2025 Score: 0 Rep: 61,283 Quality: Low Completeness: 30%

VS Code has a not-bad experience for C++ development. I'd recommend installing the MS cpptools extension, and CMake Tools or Makefile Tools if you use either of those buildsystem things. cpptools provides debug integration. I'm a (mostly) happy user of it.

Or just use GDB and the rest of your toolchain from the commandline. Yes, it's totally viable.

See also https://stackoverflow.com/q/78046085/11107541.

October 30, 2025 Score: 0 Rep: 14,265 Quality: Low Completeness: 0%

I use both, VSCode for editing (and nicer integration with copilot), but debugging I certainly do in Visual Studio because the debug experience there is certainly worth starting it up for.

November 3, 2025 Score: 0 Rep: 286,286 Quality: Low Completeness: 70%

The standalone debugger for C and C++ code on Windows is named "WinDbg". You'd want to install the "Debugging Tools for Windows" package. At one point you needed to run the Windows SDK installer (you can unselect all other features), but now there are (again) standalone installers, of which the simplest is just

winget upgrade Microsoft.WinDbg

See Install the Windows debugger

A lot of the information about WinDbg is focused on debugging device drivers, where it is pretty much the only game in town. But it also works just fine with user applications.