Visual C++ Team Blog

TL;DR: Just set up the "Build" toolchain (configuration) in Qt Creator and point Qt Creator at your target (with the correct ssh user login) for when you click "Run" or "Debug".

http://wiki.qt.io/Raspberry_Pi_Beginners_Guide
http://wiki.qt.io/RaspberryPi2EGLFS

These two tutorials use slightly different setups, so don't get confused on details, but both are great to glean tips from.

I've successfully used Qt Creator on both a Linux VM (desktop Intel) and a Windows desktop to build originally-desktop-based Qt projects for embedded Linux on ARM. The projects are not headless, but also do not use X to run the Qt GUI. Instead they use EGLFS.

Even if your software doesn't have a GUI, you can still do remote debugging with Qt Creator... or Eclipse, or Visual Studio , or anything that has the proper hooks.

I don't think any sane developer would want to use a remote X server to get to an instance of an IDE.

As long as you have the proper cross toolchain (some cost $) set up correctly in Qt, and your target code is all included properly (libraries and headers for your target, NOT your dev machine), you should be able to do exactly what you want for any desktop+remote target pair.

Additionally you don't even have to work in Linux to target Embedded Linux:

https://wiki.qt.io/Visual_Studio_Add-in
https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/

MSVC STL dev here. We're doing something different this time around. VS 2015 RTM and Update 1/2/3 were binary-compatible (as usual) while adding lots of features to the compiler and STL (unusual). VS 2017 RTM and its Updates will continue to be binary-compatible while adding features, meaning that our DLLs are still vcruntime140.dll, msvcp140.dll, etc. The versions are admittedly a mess, so here's the magic decoder ring:

VS 2015: IDE version 14, DLL version 140, toolset version 140, compiler version 19.0 (the C++ compiler is older than the Visual part of Visual C++).
VS 2017: IDE version 15, DLL version 140 (same!), toolset version 141, compiler version 19.1

We still recommend that you build everything with VS 2017 consistently, as this will give you the most performance and correctness. However, you can mix in object files, static libraries, and DLLs compiled with previous versions all the way back to 2015 RTM, and things will continue to work (although you won't necessarily activate fixes in the newer version).

For more info, read the comments on https://blogs.msdn.microsoft.com/vcblog/2016/08/24/c1417-features-and-stl-fixes-in-vs-15-preview-4/ where I mentioned WCFB02.

VS/MSVC has improved a lot. There are details here: https://blogs.msdn.microsoft.com/vcblog/2016/06/07/compiler-improvements-in-vs-2015-update-3-rc/ but the long and short of it is that we are working on achieving complete C++98/11/14 compliance by (hopefully) the end of this year. And we have a number of C++ draft standard features implemented already, in both the compiler and the libraries.

Additionally, we're shipping a number of versions of Clang in VS (targeting Windows, targeting Linux/IOT, targeting Android/iOS) and contributing to the community. We're looking seriously into CMake support and contributing back to the community. And the VS Code editor runs on Unix-based OS with IntelliSense, debugging, etc.

So yes, VS has improved a lot, but we still have work to do.

I'd love to chat with you if you have questions. My email is firstname.lastname@microsoft.com. My full name is on the blog that I linked to but I'm really not that hard to find online.

And I've got questions for you if you use Clang and have any interest in Windows. Send me mail and we can maybe set up time for a phone/Skype call.

> So number of opponents is very minor but they make lots of noise. While the 'normal' people, those who really enjoy dictate are great majority, alas, not very vocal. This is communist lingo bro.

No, this has some basis: http://assets.csom.umn.edu/assets/71516.pdf

You never hear anyone going to post "oh wow I love systemd/my dell laptop/this website/" unless specifically asked, or when answering seemingly biased or sometimes incorrect "bad" reviews. I personally enjoy managing my computers much more since systemd.

That's like other technology stacks. For instance, some people were burned by CMake in 2008, didn't try to understand its logic and you still see them complaining on forums up to this day and you may think that this is a shitty unused buildsystem; but when Microsoft and Jetbrains did actual surveys it came out as very strong (more used than make) and growing:

https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/

https://www.jetbrains.com/research/devecosystem-2017/cpp/

And now with the one you excluded (VS Code), we are seeing them making a serious move on your two big advantages of IDEA over VS.

They have apparently built a lot of the "big" VS in C#, and they have apparently architected VS Code with a C# runtime on top of Electron to make it easier to port big pieces of VS into VS Code.

Today they announced a preview of their upcoming C/C++ extension (https://blogs.msdn.microsoft.com/vcblog/2016/03/31/cc-extension-for-visual-studio-code/) and they say their Python tools for VS are coming to VS Code this year.

And VS Code "runs on my platform(s)".

The more developers they convert to VS Code, which is a lot deeper than just an editor for C# and Typescript, the more influence they will have on development patterns on all platforms. This seems like a bigger push than just "make Windows the best platform for developing for all platforms". They're attempting to get devs who continue working on Mac and Linux to switch to their dev tools.

those are some cool changes. For those who can't/don'w want to watch the video:

- 24 bit color support added.

- lots of work to support more programs

- launch windows programs from bash (notepad.exe for instance)

- file change notification support (to allow for automatically rebuilding a website on file change for instance)

- can build a C++ project in Visual Studio and deploy it to your local WSL env, so you can run it directly from the local bash. (Visual Studio generates real linux binaries : ELF 64 bit lsb executable)

- Remote GDB Debugger: Can use visual studio debug engine to debug linux executables (It looks like this was possible before for remote machines [1], but now it can be done locally on a program running in WSL.)

[1] https://blogs.msdn.microsoft.com/vcblog/2015/11/18/announcing-the-vs-gdb-debugger-extension/