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.
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.
Firstly, please forgive my ignorance regarding these matters, I have done a search and not found any comprehensive answers as of yet.
I plan on learning how to develop for Windows, however I am very fond of the GNU toolchain and don't really want to move onto using big environments like Visual Studio until I feel more comfortable with the underlying basics.
From what I understand, one can download the Windows SDK, which contains the headers and libraries needed to build native Windows applications.
Is the SDK literally just a collection of libraries and headers? If so, as my logic goes, it should be possible to point MinGW towards these libraries/headers, and simply build as normal.
When I build using Visual Studio, I can't see what preprocessor directives are being defined, what is being linked in etc. etc., as I am still learning, I like to be able to know exactly what is going on, preferably so I have to manually define, link etc. Hence the question.
So, what I want to know: is my logic correct?
Again, apologies if the question is rudimentary, I am still learning.
P.s. I am planning to develop Windows applications in a windows environment, this is not a question regarding cross-compilation.
Thanks!
MinGW is not compatible with the official Windows SDK, with one of the reasons
being that the SDK contains many VS-specific things (opposed to the GCC base
on MinGW). MinGW has adapted many of the necessary files, and for many programs
this is enough.
You don´t need to know the VS project settings for some program;
MinGW is still GCC in the core and used as such. If you can compile
programs with GCC on linux, learning how to use MinGW won´t be hard.
If you need functions/structures/etc. which are not yet part of it,
you´re out of luck, other than doing the adaption yourself, which
can be everything between very easy or very hard, depending on the case.
Additionally, proper thread usage is a bit quirky (has some "hidden" pitfalls,
which could go unnoticed in an actual program for years, but then...).
(While this is a disadvantage to VS, you´ll get C++11/14 (while VS hasn´t
even finished with 11, see link), better optimzation in many cases etc.)
If you´re choosing what exactly to download, look at WinGW-W64 instead of
the "original" old one. The original project somewhat stopped, has poor
lib support compared to W64, no 64bit compiler etc. (and don´t misunderstand
the "W64", it can be used for 32bit programs too)
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.
What's in MS Visual C++ runtime library? I mean, I googled it, and I always found things like help, app xxxx gives me MS Visual C++ runtime library error, with no explanation.
I thought that Windows C runtime libraries come with Windows? Not with VC++? Thanks.
EDIT:
First, thanks for answers. I thing now I have bad idea of runtime libraries in windows. I mean, the first part, that Windows internally has its win32 API and so, that's OK, I knew it. Also, that Win32API are from kernel and user parts.
But I always thought that functions like GDI are accessed as DLL (which I still believe they are). But I thought even functions like printf and so are in some windows file.
So, am I right, when I know get it that "simple" functions like printf need to be linked directly and than use only Kernel part of OS directly, and more sophisticated Windows API functions are linked as dlls, therefore ARE NOT distributed with compiler but with OS? And they subsequently access Kernel?
I mean, lets say GDI, I tell it to draw picture, it makes all the hard work in user mode and than call kernel function which puts it all in framebuffer?
And last thought, why is this even solved this way? I mean, if VC++ runtime is just layer between C and WinAPI, why cant VC++ call directly WinAPI?
This is an oversimplification, but it will give you the gist. The MSVCRT is a set of DLLs that implements parts of the C++ language. Functions like printf, memcpy and the like are implemented in these DLLs.
Every program that is compiled with a particular compiler and dynamically linked to the C++ runtimes must somehow have the correct version of the CRT binaries on the target machine. As a result, applications that ship to end users are often (usually?) also shipped with a package of these DLLs. This package is called a "redistributable" (or "redist"), and there is a different one for every combination of exact compiler version and target platform. For example, there are seperate and distinct redists for each of the following:
MSVC 10, 64-bit windows
MSVC 10, 32-bit windows
MSVC9, 64-bit windows
MSVC9 SP1, 64-bit windows
et cetera.
Yes, Windows usually "comes with" some version of the CRT. However, it comes with the version(s) that it needs in order to run the apps that shipped with Windows. If Windows and all it's apps were compiled in MSVC8 SP2 and your app is compiled in MSVC10, the CRT you require won't be present on the box simply because it's running Windows.
This is why its common practice to ship apps along with redists.
EDIT:
By way of Houdini like magic, I predict your next question will be "where do I get the redists?"
The answer is, from MicroSoft. Try a google search for "msvc 9 x64 redist" and you will find:
http://www.microsoft.com/downloads/en/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6&displaylang=en
A brief answer would be that the MSVS C/C++ runtime implements functions like malloc/free, stdio, iostream and some c++-stuff like dynamic_cast and exception handling. These differs between versions of visual studio, so there are different runtimes for different versions.
Windows ship mostly with a C API (the Win32 API) which rather different from the C/C++ standard library. The MSVS C/C++ runtime calls into this API to allocate memory, etc etc.
(I suppose some of the applications included with Windows are written with MSVS and in C++, so they do include the MSVS runtime for that version.)
Also, the runtime changes as new Visual Studio versions are released. A Windows release lasts much longer than that.
They are the libraries that implement the C and C++ standard library functions. Standard functions such as printf are implemented in these libraries.
The core Windows libraries only provide interfaces to system calls, i.e. the Win32 API, since that is all you need to build a full-featured Windows application. The VC++ libraries are mostly wrappers around this API, and are analogous to the glibc library on Linux.
As an example, malloc from the C library might in turn use the VirtualAlloc API to allocate memory.
Programs compiled with Visual C++ require a "runtime" - this is a bit of code that handles application startup/shutdown, memory allocation/deallocation, support for reading and writing files, etc.
This is not part of the operating system, and not part of the final application - Because all C++ applications can share it, by default the runtime is a separate installation.
In addition, each version of Visual C++ has its own runtime installer, because with each version there are slight differences and improvements in the way all this works. There are also different verisons of the runtime for different platforms (e.g. x86 and x64)
Hence, there are a number of "Visual Studio XXXX runtime installer (YYY)" downloads available from Microsoft, where the XXXX is the visual studio version (2005, 2008, 2010, etc), and YYY is usually "x86" or "x64".
Most applications that need the runtime will automatically install it if needed, so generally end-users are not very aware of these redistributables.
Currently I`m using Visual Studio for writing code in C++. But it seems so weighty that I decided to switch for another one, preferably free, not so strict to system resources (I mean memory, of course) as VS to learn libraries, such as Boost and Qt. What compiler do you suggest?
I'd suggest using Visual Studio's compiler from the command-line. You get the same high-quality compiler, without the resource-hogging IDE.
Although the IDE is pretty good too, and probably worth the resources it uses.
Code::blocks is exactly what you are after. You can can download it here: http://www.codeblocks.org/downloads/5
Choose the version with the mingw compiler bundled with it (Windows port of GCC). You can switch between that and the VC++ compiler as and when you like.
Code::Blocks has all the stuff you want, debugger integration, code completion, class browser, todo list etc. etc. It even import visual C++ projects.
Don't use Dev C++ which has already been recommended. It's very very old and outdated.
If you want to learn unix tools download and install cygwin It's a good set of tools but a full install takes up 5 or 6 gigs because so much is included.
There is always Digital Mars. Also, you can freely download Microsoft WDK
which comes with their C/C++ compiler and command-line build system.
You will be hard-pressed to find an IDE as capable as MS VS. It is incredibly feature-rich.
However, if you just want command line compiling and linking it can do that too.
GCC is also an option.
Please note that you do not need another compiler or IDE to use boost libraries. I wouldn't replace Visual Studio with any other IDE/compiler, at least not on Windows. Installing Cygwin or SUA (better than Cygwin, closer to the Windows Kernel) will only be a pain just for what you are trying to reach.
Try to minimize the memory usage by disabling unnecessary things, keep the amount of open source files small, use an alternative to document explorer to find help (your browser on msdn will do). Besides that, I wouldn't call a few ten megabytes of memory a high usage. As long as it doesn't slow your system down there is not a real issue.
A better idea would be to upgrade your computer rather than to replace something powerful with something that you don't know.
Seriously there is no real alternative to Ms's compiler on Windows. All the others are OK if you can't spring for Visual Studio or if you are just doing hobbyist work. Cygwin can be a pain to deal with.
If you don't want the IDE as someone else suggested just use the command-line compiler.
I've found VS to be quite good for doing Boost + Qt work. Especially if you have the Qt + VS integration tool. You get a GUI designer and respectable Qt project management tools.
If you are looking for a compiler that uses fewer system resources than the MS ones, you'll probably find that most modern compilers that are able to compile a good part of or almost everything in Boost will be quite heavy on system resources, both processor usage and memory consumption. To a certain extent that's just par for the course when it comes to C++.
That said, I do like to have a second compiler around if I'm writing portable code as it's a lot easier to iron out portability issues when you can ensure that the code compiles in different environments. If you want to do all that on Windows, may Cygwin is worth a look. However it does seem that the GCC you get with Cygwin is not exactly what you'd call up to date.
The aforementioned Digital Mars compilers are well worth a look, Walter Bright (the guy behind them) has been writing C++ compilers for a long time and they're pretty good. I have used them off and on since the early nineties and I've always been happy with them. Not to mention that they always seemed noticeably faster than the Microsoft offerings, but I haven't got any recent measurements to back that up.
At the end of the day, most third-party tool vendors on Windows tend to target the MS environment so if you're writing C++ code professionally and need/want tools like leak detectors, you pretty much need to be able to build with the MS compilers, even if they aren't your main development environment.
I sugget , Netbeans.org
NetBeans IDE , download the Cygwin , follow one tutorial from http://www.netbeans.org for C++ confuguration at Netbeans IDE , just 2 steps.. and u are ok
autocomplete (faster than VS')
classes
and all... you want xD
It needs to mention about DevCpp. It is a simple UI wrap for gcc compiler (oh my, it is sounds like a tautology). It provides lightweight IDE but not so stable (so, its IntelliSense is somewhat buggy).
If you use Qt why not use their IDE, QtCreator, there is compiler, debugger and GUI designer. All comes in one nice package and works on Windows, Mac and Linux.
In my opinion it's better than Code::Blocks (also based on MinGW/GCC).