VS Code immature for C/C++ development on Windows
CURRENT STATUS: Don’t use VS Code for C/C++ production until you really really enjoy it’s other features.
This is not a rant post (except for one paragraph at the end), but rather a report on what to expect when you are considering using VS Code.
I’m trying something new this time. I decided to stay with VS Code for a while, even if it’s slowing me down, as opposed to leaving and never going back. So I’m filling and pursuing issues I find with C/C++ development, building and debugging. And here’s the current summary for VS Code 1.8.1 and C/C++ extension 0.9.3.
Features that I enjoy
Integrated shell (even integrated cmd.exe that I have customized) saves a lot of Alt+Tabs (especially if I keep several projects open).
Very simple every-day git features in the UI. (you can’t do everything, but basic add, commit, push and pull work quite well from the UI, even the merge/diff viewer is there)
Integrated MS debugger that seem to be shared with VS2017 itself. (It is a bit slow, but it’s quite okay for everyday debugging. I’d use VS for more hard-core debugging tasks.)
Not focused on C/C++ only. I can work on Python, Lua, HTML, JS with the same shortcuts. Most of them already offer debugger.
Very well polished UI that doesn’t distract.
Minimal need to have IDE-specific project configuration files (I only have very basic configs that I can just copy to other project).
Note that I use standard Visual Studio Compiler and respective Visual Studio debugger integration provided by cpptools . I haven’t tried gcc/gdb or llvm/lldb and I don’t plan to. Also I don’t look for code intelligence nor autocomplete, I just need Sublime-level of editing features with building (and optionally everyday debugging).
Grouping compile errors by file
Compiler output is fed into Problems view by grouping the issues by file, which is largerly unhelpful. In C you want to see the original order of issues from the compiler, as you almost always care about errors on the top of the list (that later propagate to the rest of the source code producing a flood of misleading errors). Therefore F8 (jump to next issue location) does not work.
Cursor in problems view
The cursor in Problems view is not reset after a new build, that means that jumping to next issue location won’t work if you already reached the end of the list. This also has a huge dependency on following issue.
Warnings produced for all files opened in VS Code
The Code Intelligence in cpptools (C/C++ plugin for VSCode) produces warnings like Include file not found in include directory for all files, especially for those that don’t belong to the project. I use code from my older prototypes and open the files in the VS Code, which causes Problems view to overflow with the warnings.
While normally I wouldn’t care, this causes the Problems view to never empty, which in turn causes the next-issue-cursor to never really reset, hence it doesn’t work after a new build. You have to go to the Problems view yourself (Ctrl+Shift+M) and hit Page-Up several times (as Home doesn’t work there).
Case-sensitive file path handling on Windows
Windows’ file system is case-insensitive, therefore you get paths with various case letters to be fed into the software. Programs usually deal with this by normalizing the paths, or simply by using case-insensitive compare (and only normalize slashes if they support both / and \). VS Code currently only handles paths as case-sensitive, which causes tons of problems.
New editors are opened for files with even slightly different paths, and each is being treated as a completely separate file. So if you change it, save it and then open the other editor (with the same file, but different case letters in the path) you’ll be forced to manually Compare and merge the changes before it allows you to save. This is extremely annoying and I already lost several changes.
The cpptools plugin is obviously feeding paths with essentially random case compared to Explorer (integrate file browser in the side-panel of VS Code), so each time you go to next issue, or stop on breakpoint, or click on call stack, there’s a good chance it’ll open a separate editor for the file.
I spent good amount of life on opening and closing issues in vscode and cpptools as they were each blaming the other. This obviously is best handled in the vscode itself as otherwise each of the plugins will have to provide own path normalization.
Minor issues
A very slow response times from Sublime. It’s not lagging, rather it’s a bit lazier than Sublime, even for typing. But that’s to be expected.
I’d expect to see Debug output console to be shown when I start debugging a file. This does not happen automatically. I’m yet to investigate whether I can configure it.
I’d expect to see Problems view to be opened after the build is finished (if there are issues). However, currently I’m happy this doesn’t happen and only the build task output is shown as I’m forced to use it.
Setting up tasks.json (for one-of tasks like builds) or launch.json (for setting up the debugger) rarely provides enough information on what went wrong, so you’ll have to debug problems with paths and syntax yourself. Luckily I only have to do this once and then copy the two files to my projects.
Some shortcuts like "Split Window" do not work. (I had to reconfigure them)
Bookmarks are provided as separate plugin. (Not a big deal, I'd just expect them to be in core)
WARNING: RANT! When you combine all the major issues together, the actual workflow in VS Code feels extremely comical, I even consider streaming it and making a (music) compilation video, just for the fun of it. (And because I remain extremely irritated with amount of lack of interest for basic and essential issues, while issues like "text label misaligned by 2px" are getting attention).
All these issues were reported, some of them got interest from the developers and some minors are even fixed in the dev branches waiting for release.


















