I've downloaded the MSVC ABI version of Rust 1.7.0 and followed the guessing game section from the docs.
I notice that the builds use the native toolchain (Visual Studio 2015 Update 2 in my case) and therefore generate native PDBs (debugging symbols) consumable by native debuggers, such as WinDBG, CDB or the Visual Studio debugger. I can easily set breakpoints, step into standard library source and so on.
What I cannot do is to inspect variable values. Regardless of the debugger used, the 'Locals' display is empty.
From what I can gather, the Visual Rust/RustDT IDEs display locals when using GDB or LLDB as a backend, not the native Windows debugging engine. I'm not entirely sure if I can use these to debug Rust programs compiled for MSVC ABI (with PDBs and so on).
If I want to have the necessary debugging experience, is my only option to switch to the GNU ABI? Barring that, is there an easy way to map to Rust symbols (variable values) from the raw debugging tools (registers, memory map)?
Features don't exist until they're implemented. Rust is built upon LLVM and full PDB support has only recently been considered for LLVM. For now LLVM has only a limited PDB support, with the limitations best described on the Clang project's MSVC compatibility page. In my opinion, it's best to wait until the support is there, although for other programming languages interesting workarounds have been implemented.
Related
Visual studio 2015/2017/2019/2022 all come with (somewhat hidden) compiler for 32-bit ARM processors. The 64-bit ARM Windows also comes with support for running 32-bit applications. However, after I built some C++ applications using that 32-bit compiler I find myself unable to actually run it because build rules for most software include /MD compile flag which links the exe/dll-s against the dynamic VS runtime in a few dll-s (vcruntime140.dll, etc.). My arm system is missing that runtime (at least the arm version) and I cannot find it anywhere. All the publicly available runtime downloads include only x86, x64 and arm64.
What am I missing? Building modern software with the runtime linked-in is inefficient and often will not work correctly due to sharing runtime-specific structures across library boundaries. But the dynamic runtimes are nowhere to be found. Is 32-bit ARM considered deprecated or only useful for simple single-binary embedded applications? Or is there something about arm platform which makes linked-in runtimes work for applications spanning multiple binaries? Are the arm runtime installers available in some dark corner?
I have an installation of visual studio 2015 (french version). The installation itself take a lot of disk space. I have only C++ compiler installed without .net, C#, web and mobile developer toolkit.
Does anybody know what is the actual reason for too much disk space requirement compared to other C/C++ compiler toolkits (GCC, Clang).
another point:
Installing a language pack for english demands 4GB of disk space. Why it requires that much space where I am installing only a different language. I mean compiler executable remains same in this case. Just the internationalization parameters needs to be changed.
Is there any technical or commercial reasons to why Visual Studio do this.?
The installation itself take a lot of disk space. ... Does anybody know what is the actual reason for too much disk space requirement compared to other C/C++ compiler toolkits (GCC, Clang).
Because Visual Studio installs a heck of a lot more stuff than just a compiler toolkit like GCC or Clang. For example, it includes an IDE, an interactive debugger, a bunch of libraries, the source code for all of the included libraries, profiling and other tools, etc.
If you just want the compiler toolchain and not the IDE or anything else, download the standalone C++ build tools.
Or, for an earlier version of the build tools, just download the Windows SDK. (The build tools are no longer included starting with the Windows 8.1 SDK. Therefore, you'll need to get an older version, like the Windows 7 SDK.)
I am trying to compile qt, and am faced with two choices whether use MinGw or Visual Studio compiler? What is the difference between them, and are there any advantages/disadvantages of using one or the other?
They are both fine tools. The important thing to know is that they don't necessarily play well together. That is, as you link libraries together, they must all use the same tool chain. For this reason, in my opinion, it is better to use the Visual Studio compiler (MSVC), as it is the "first class citizen" on Windows; the others are treated somewhat as second class.
What I mean is that you can pretty much count on third party libraries being available in binary form using MSVC, or at least build instructions being available using MSVC. We had lots of problems with third-party libraries not being able to build in MinGW or having nonexistent build instructions and having to do a lot of manual Makefile editing, etc. You are much more likely to have things "just work" if using MSVC.
That is just our experience (we started with MinGW); your mileage may vary.
MinGW uses GCC, and GCC has one significant advantage to MSVC - it is portable. MSVC is limited to Microsoft platforms, GCC supports pretty much everything, including 8bit embedded CPUs. Meaning that you can use the same directives and compile extensions across different platforms.
Also, MinGW is compact, quick to install, and a version is even bundled with Qt. Unlike MSVC, which is not even available standalone, you have to install visual studio, which itself installs a bunch of garbage you don't need but can't opt out of.
UPDATE
It is now possible to get the MS compiler without VS, a.k.a MS Build Tools. Also, If you want to build chromium (a.k.a the QtWebEngine) for windows you have to use MSVC, that's a limitation imposed by google, as they only support building with the platform-native compiler.
Last but not least, you can get MSYS2, which has a repository with MinGW and a ton of ready to use static and dynamic libraries build for it, so you can avoid the arduous and often failure prone build process.
UPDATE
Just for the sake of reference, for VS build tools 2019, the C++ compiler alone takes up about 4.5 gigabytes of space, or about 8 if you just click "C++ build tools" and leave it at the default. For comparison, GCC 9.x is about 150 mb. In fact, the MSVC compiler alone is larger than the entire extensive collection of packages that I adopted for use throughout the years, plus their dependencies, for a total of over 200 packages. Additionally, I'd say MSYS had packages for about 98% of the libraries and tools I've found myself in need of, and those remaining 2% include libraries it had but were not configured in a way, suitable for my use case. And it goes without saying, the packet manager makes it trivial to keep versions up to date.
I would like to use C/C++ for coding my apps, but I need my apps running on all versions of Windows from XP to Win8, independently by any platforms, run time libraries and so on.
Briefly: What kind/type of C/C++ I suppose to use, be able to run my apps on every type of Windows without any additional installation, just default one. e.g Windows XP SP1
C++ can run on just about any OS, as long as you avoid (or, via conditional compilation, provide alternatives for) anything specific to one OS or version. Win32 code is almost all the same between versions; the main difference is added functionality in newer versions. Between Windows and, say Linux, though? Not so much. You kinda need to pick a platform, unless you want to either stick to text mode (which is pretty close between OSes, thanks to standards) or learn some whole other platform-neutral API like OpenGL, wxWidgets, GTK, etc.
As for which compiler to use, if you're sticking with Windows, I'd recommend Visual Studio. Microsoft has a free (Express) edition that will let you compile Win32 code or .net. (You'll need the paid version, or some playing around with the Platform SDK, to play with 64-bit though.) And the IDE isn't too bad either. If you just want a compiler, the Platform SDK has the same compilers VS has, and includes 64-bit support (and even a bunch of code samples and tools) as well.
As for being independent of any runtime libs: Every C++ compiler that's worth using has a runtime library. If you link statically against it, though, the parts you need will be embedded in your EXE. Alternatively, you have permission to distribute the runtime libs with your app (though you may need to install it via a package they provide, that you bundle together with your app...i forget how all that works).
All popular C++ compilers support XP up. You can statically link the runtime, or, for mingw, you can link against the runtime supplied with Windows.
I'm taking a class in which I'm required to write some C++ apps for Linux. I really, really dislike the dev tools available under Linux, but I love VS2010.
Is there any sort of compiler switch which will enforce ANSI or gcc compatibility in VC++? Or can I swap the compiler out for gcc and still use the VS environment?
You can disable Microsoft extensions to the ANSI C and ANSI C++ standards by specifying the /Za flag, which will make the compiler emit errors if you use non-standard C and C++ features.
http://msdn.microsoft.com/en-us/library/0k0w269d(v=VS.100).aspx
However, this doesn't preclude you from using platform specific headers.
This blog post seems to discuss something similar to what you're after.
I can't seem to find better info than this MSDN document regarding VS2010 ANSI compatibility.
Some alternatives to VS2010 include MonoDevelop - which supports C#, VB.Net, C/C++.
There's also Eclipse IDE for C/C++ Dev.
This stackoverflow question may also be of use.