I am writing code in VS that should be ported later to Linux. I found that sometimes, I may use some functions or code that is available only on Windows and not on Linux.
Is there any way that I can set my Visual Studio to report me these non portable pieces of code?
I prefer to use VS during development and then use the code base and compile it in Linux.
You can treat MinGW as a reference compiler, just to check whether the code you write is portable.
You can also disable MSVC compiler extensions in the compiler options settings in Project Properties (or set /Za flag). That will most likely make at least <windows.h> stop compiling.
Frankly, though, I don't see a problem in simply not using nonportable things. Stick to standard library and libraries that you know are portable and you're good to go. (granted, syntactic extensions are easier to accidentally use, but then again their usages are also typically trivial to put back in proper way).
Related
I want to learn C++ and I want to know if using Microsoft VC++ will tie me to Windows. I specially need my project to also run on Mac. My projects are all Class libraries and have no dependency to UI. They are just calculations or file/network IO.
I really like working in Visual Studio and Microsoft way overall. So my priority is to go VC++ unless it makes painful to build cross platform apps for Windows and Mac. I mean at the compiler, libraries and language level. I don't want my parallel app to fall apart on certain platforms.
I personnaly use Visual Studio to build my code on Windows and other compilers to build the same code on other platforms (Mac, Linux, Android...).
To be sure you don't get locked with Windows, make sure (at least, it's not exhaustive):
You don't use any win32 API (prefer cross plateforme libraries like boost for instance for network, file system access...)
You don't use 3rd party libraries only available for Windows
Don't use CString, or anyother Microsoft class. Prefer STL.
Be careful with file system case sensitiveness too! (#include "Foo.h" while file is "foo.h" on disk will work on PC, not under Mac/Linux). Prefer naming ALL your files in lower case.
...
You may want to have a look at CMake. This tool can help you generating compilation project file for the same source to be compiled on different plateform. Then, you can generate vcproj/sln files to compile your code with Visual Studio on Windows, MakeFile(s) to compile it under Linux and XCode project files to compile it under MacOS. If somewone wants to compile you code under Windows with another compiler than Microsoft, it's also possible!
Also note that recent version of VS (2015) propose to compile for other targets that Windows (at least Android). But never tried that.
The compiler itself is pretty standard confroming by know (if you turn off the extensions) and more importantly, you can use the clang frontend (which is the default compiler on Mac) directly from within VS2015, so it is definitvely possible to write cross-platform code in VS (although it's certainly easier to use Windows specific constructs than it where if you'd use e.g. cygwin).
However, the windows API for network I/O is different from the one for Mac, so you should probably use a corssplatform library like boost asio for that.
As far as multithreading is concerned, you can do it in a standard and portable manner using the standard library's functions, classes and synchronization primitives, but the past has shown that they are often not the most efficient way to go. However, in most situations you'll want to use a more highlevel library for parallel programming anyway. The default on Windows is the PPL which is - I believe - not cross-platform, but there are other libraries you can use
Finally, you can use VS to remotely build your applications on Mac or Linux PCs using their local compilers and libraries. However, I don'T know, how well that works in practice.
Some open source projects explicitly state that in order to compile on windows, they need a microsoft compiler (often a specific version as well, as latter versions are incompatible or will refuse to compile older code).
Since it seems absurd to me that, since there are foss compilers that can compile for windows, a microsoft compiler would be necessary for any fundamental task, I'm assuming this is because those projects use api calls to libraries (such as msvcrt*.dll) that, for some reason, mingw-gcc, clang and other ports of compilers for windows are unable to compile against.
My understanding of these requirements is shallow, since my experience with compiled code comes primarily from linux and this worries me, since getting a microsoft compiler is non-trivial. the only way to get them is through the express editions of microsoft's visual c++, and even then, the most recent version will completely refuse to install on an old winxp machine like mine and the only version available at the moment is vc++express2010, which requires registrations to turn from trialware into freeware (and even then i'm not clear on if that'll work or what it entails - perhaps OS hooks to "debug" and other intereference?).
1) My question is, do these projects depend on microsoft compilers due to building against these microsoft-only libraries (which apparently foss compilers can't do)?
It would seem absurd if the reason is the build script or preprocessor directives, since those can be relatively easily ported.
2) Also, is it possible that, even if I avoid any msvcrt/.net/etc. calls, i can still find myself needing a microsoft compiler to compile native windows software (assuming no usage of libraries that do perform those calls)?
3) Can I simply use clang and some widget library to make native windows software just as well?
4) Can I modify the source of a project so that it doesn't depend on a microsoft compiler?
(ok that's 4 questions, sorry, this is quite hard for me to express clearly).
1) My question is, do these projects depend on microsoft compilers due
to building against these microsoft-only libraries (which apparently
foss compilers can't do)?
Compiler vendors and GUI framework vendors can supply DLLs that perform similar to the MS DLLs. Some of the MS DLLs are system DLLs and are used by the other compiler and framework vendors.
If you are using compiler or framework specific DLLs, they need to accompany the installation of your programs (projects).
2) Also, is it possible that, even if I avoid any msvcrt/.net/etc.
calls, i can still find myself needing a microsoft compiler to compile
native windows software (assuming no usage of libraries that do
perform those calls)?
No. If you scan through the posts on StackOverflow, there are many people who are using the Windows API directly, I guess what you are calling native windows software. Usually, the code for these API are located in a system API. The compiler translates the function call to a call into these DLLs, loading them as necessary.
3) Can I simply use clang and some widget library to make native
windows software just as well?
No, you can't. That's why they exist.
Again, many people are using frameworks like Qt and xWidgets without the MS compilers. I did that for a while. I switched over to Visual Studio, primarily for the debugger. I didn't like how other IDEs tried to use GDB. Otherwise, I wouldn't use MS because they tend to go by the Microsoft Standard language rather than the ISO.
4) Can I modify the source of a project so that it doesn't depend on a
microsoft compiler?
No, that is why there are freeware and other compilers out there.
Hmmm, one can use Java to create GUIs that don't use the MS compiler, but they use the Windows API.
Try installing Cygwin. When you look at all the libraries you will realize that projects can be created that don't use the MS Compiler. Again, read through the StackOverflow posts and you will find that people are using other compilers, such as Intel, GNU, Clang, Greenhills and others. Some compilers for embedded systems will also compile for Windows OS, so you can write code that works on both platforms.
Looks like you need to search the web for "GNU GUI tutorial C++" and see what pops up. Also, search for "wxWidgets" and "Qt" for other frameworks.
I receive C++ source code from a developer who is compiling using Visual Studio 2010, that I then need to recompile under various different compilers: GCC, LLVM, other versions of Visual Studio, etc. Sometimes the code that he sends me (that compiles without warnings in VS2010) fails to compile under the other compilers.
Are there any compiler settings he can set in VS2010 to increase the likelihood that his code will be cleanly portable?
At the language level, there is no silver bullet. The best you can do is to stick to the language standard as closely as possible. Most compilers have options to issue warnings or errors if you take advantage of an extension that's specific to a particular compiler (with Visual C++, /Za will disable non-standard language extensions). But this isn't perfect, as no compiler yet implements absolutely 100% of the standard, so you can still have portability problems even with strictly-compliant code.
Also be aware that lots of everyday code actually takes advantage of extensions or undefined- or compiler-defined behaviors, often without realizing it, so it might not be practical to compile in a fully standards-compliant mode.
You also have to be aware of things that the standards allow to be different. For example, types like int may be different sizes on different systems. Windows is LLP64, while most Unix-derived OSes are LP64.
At the system level, I don't know of a perfect way to make sure a programmer is not relying on something system-specific (e.g., <windows.h> or <pthreads.h>).
Your best bet is to make it simple for all developers to run test builds on all target platforms.
I currently develop in C++ on Windows, using Visual Studio 2010. After the official announcement of C++11, I have begun to use some of its features that are already available in MSVC. But, as expected, the great majority of the new changes are not supported.
I thought maybe the upcoming version of Visual Studio would add these new features. However, after reading this it looks like very little is going to change.
And so, I'm curious about the feasibility of using GCC on Windows rather than MSVC, as it appears to support the great majority of C++11 already. As far as I can tell, this would mean using MinGW (I haven't seen any other native Windows versions of GCC). But I have questions about whether this would be worth trying:
Can it be used as a drop-in replacement for cl.exe, or would it involve a lot of hacks and compatibility issues to get Visual Studio to use a different compiler?
The main selling point for Visual Studio, in my opinion, is it's debugger. Is that still usable if you use a different compiler?
Since GCC comes from the *nix world, and isn't native to Windows, are there code quality issues with creating native Windows applications, versus using the native MSVC compiler? (If it matters: most of my projects are games.)
In other words, will the quality of my compiled exe's suffer from using a non-Windows-native compiler?
MSVC has the huge advantage of coming with an IDE that has no equals under Windows, including debugger support.
The probably best alternative for MinGW would be Code::Blocks, but there are worlds in between, especially regarding code completion and the debugger.
Also, MSVC lets you use some proprietary Microsoft stuff (MFC, ATL, and possibly others) that MinGW has no support for, and makes using GDI+ and DirectX easier and more straightforward (though it is possible to do both with MinGW).
Cygwin, as mentioned in another post, will have extra dependencies and possible license issues (the dependency is GPL, so your programs must be, too). MinGW does not have any such dependency or issue.
MinGW also compiles significantly slower than MSVC (though precompiled headers help a little).
Despite all that, GCC/MinGW is an entirely reliable quality compiler, which in my opinion outperforms any to date available version of MSVC in terms of quality of generated code.
This is somewhat less pronounced with the most recent versions of MSVC, but still visible. Especially for anything related to SSE, intrinsics, and inline assembly, GCC has been totally anihilating MSVC ever since (though they're slowly catching up).
Standards compliance is a lot better in GCC too, which can be a double-edged sword (because it can mean that some of your code won't compile on the more conforming compiler!), as is C++11 support.
MinGW optionally also supports DW2 exceptions, which are totally incompatible with the "normal" flavour and take more space in the executable, but on the positive side are "practically zero cost" in runtime.
I want to add some information because the field may have changed since the question was asked.
The main problem for switching away from MSVC was the lack of a good IDE that flawlessly integrates with MinGW . Visual Studio is a very powerful tool and was the only player on Windows for quite some time. However, Jetbrains released a preview version of their new C++ IDE CLion some days ago.
The main benefit comes when working on cross platform applications. In this case, a GCC based tool chain can make life much easier. Moreover, CLion narrowly integrates with CMake, which is also a big plus compared to Visual Studio. Therefore, in my opinion, it is worth to consider switching to MinGW now.
GCC's C++11 support is quite phenomenal (and quite up to par with standards conformance, now that <regex> has been implemented).
If you replace your compiler, you'll need to make sure every dependency can be built with that new compiler. They're not made to be substitutable plugins (although Clang is working on becoming that way).
GCC is a fine compiler, and can produce code that has pretty much the same performance, if not better, than MSVC. It is missing some low-level Windows-specific features though.
Apart from this, to answer your questions:
To get VS to use GCC as a compiler, you'd pretty much need to turn to makefiles or custom build steps all the way. You'd be much better off compiling from the commandline and using CMake or something similar.
You cannot use the VS debugger for GCC code. GCC outputs GDB compatible debug information, and the VS debug format is proprietary, so nothing will change in that area anytime soon.
Code quality is just as good as you'd want it. See above.
No, the quality of your code will actually increase, as GCC will point out several assumed standard extensions MSVC would hide from you. All self-respecting open source projects can be compiled with GCC.
I my humble opinion, it's depends how someone started to code in the first place. I've been using g++ and gcc for more than 20 years now but the reason why i keep using gcc is mainly for licensing reasons. Although i like it too when i don't have a bunch of runtime dependencies or dll's to bundle with my stuff since i came from the DOS era, i still like my stuff small and fast. gcc for windows comes with standard win32 libraries and common control but i had to develop my own win32 controls for stuff that might require mcf shit to work properly or just to look nicer.
Although gcc might have strong support over internet, when it comes to win32 stuff, many rely on mcf and vc proprietary stuff so again, one may have to work his own issues around and be creative when difficulty arises.
I think it's all about needs and circumstances. If you are just a hobbyist coders and have the time for researches, creating you own libs and stuff but you want a solid compiler that's around since the late 80's and free, gcc sound perfect for the job.
But in the industry visual studio is a must if you want to be competitive and stay in the race. Many hardware manufacturers would prefer bundling visual studio compatible libraries for they hardware over some opensource gnu stuff.
That's my two cents.
To be honest, C++ should be handled with MS Visual Studio. If you want to make cross-platform or Unix apps, use GCC. GCC works and can be used with any IDE other than Visual Studio. Even Visual Studio Code can use GCC. Code::Blocks, Eclipse IDE for C/C++ developers, CLion, Notepad++ and even the good ol' tool we've always known, Notepad works with GCC. And finally, on a PC with low disk space, installing Visual Studio's "Desktop Development with C++" is something like 5 GB, if it was to be useful. And this is where GCC hits MSVC hard. It has native C support. MSVC can compile C, but only with a lot of fine-tuning. It takes a lot of time and effort to finally be able to compile. The final verdict:
If MSVC works, it hella works! If MSVC doesn't work, it HELLA DON'T WORK.
If GCC installs, it works, and if it doesn't work, it's the IDE's problem.
GCC is for people who don't mind spending 4 hours at the computer making it work properly. MSVC is for those who don't care about C and want it to install without any pokin' around.
It can't be used as a direct swap-out replacement for the microsoft compilers, for a start it has a vastly different set of command line arguments and compiler specific options.
You can make use of MinGW or Cygwin to write software but introduce extra dependencies ( especially in the case of cygwin ).
One not often touted advantage of gcc over cl is that gcc can be used with ccache to drastically speed up rebuilds or distcc to build using several other machines as compiler slaves.
Consider the Intel compiler (or "Composer" as they seem to have taken to calling it) as another option. I'm not too sure where its C++11 support is at compared with MS (certainly it has lambdas), but it does integrate very nicely with VisualStudio (e.g different projects within a solution can use the Intel or MS compilers) and there's also been some efforts made to match the MS compiler commandline options.
GCC and MSVC use different name mangling conventions for C++. C++ dlls compiled by one compiler can not be used in applications compiled with the other. I believe this is the main reason we don't see more widespread use of gcc in windows.
I like the Visual Studio IDE. I'm used to it and find it is the best IDE I've ever tried. We also find increasing use of C#/.NET here.
However, after the underwhelming announcement regarding C++11 features in VS11 I'm looking into replacing the compiler.
It seems that the Intel compiler fully integrates with VS but that doesn't mean it will compile our Windows code. I don't know how I'd fare with a try of g++ or clang
Can VS actually be productively used with a different C++ compiler to compile Windows code, that is legacy code using all kinds of Win32 / MFC / COM stuff?
Depends on how much use you made of the Microsoft-proprietary extensions. Things like #pragma once tend to be supported by all the major compilers, but the weirder COM things (e.g., #import and anything C++/CLI) probably won't be. No idea if MFC will build under the new compiler, but you'll probably have to link it statically or ship your own DLL; G++ definitely uses a different mangling scheme than MSVC.
I'm not sure how easy it is to replace cl.exe and keep your vcproj files intact (though some compilers actually do it), but there are always Makefile projects.
I have never actually worked with the Intel C++ compiler, but I see no reason why it wouldn't compile the code that VC++ does. Here is official Intel documentation.
I use Visual Studio 2008 with a Makefile project to cross-compile; no reason you couldn't do the same with a different Windows compiler.