It supposedly integrates with Visual Studio, but does it come with it's own C++ standard library? Or does it use the one provided by VC++?
At least the last time I checked, it used the one that came with VC++. I believe you can buy the Dinkumware library for it separately, if you really want to (but Dinkumware supplies Microsoft's library, so you're getting a different version of the same, not something radically different).
Related
There is a library (.lib, we don't have the source code) which we use to communicate with a hardware device which was compiled using
_MSC_VER 1600
I wish to use a newer c++ standard while using this library. When I change it to the next higher available in VS studio I get the message that 1600 does not match 1900. Is there a way to use a newer c++ standard and continue the use of the old library?
The company which provided the files hasn't updated the drivers in years.
I found on SE various answers to this topic but most are on expert level on c++ compilation/linking. I had problems to understand them.
EDIT: It is not a DLL but a .lib file. This may be explain wy I could not understand this question and answer. Another similar answer is this one: C++ MSC_VER mismatch with Third Party library
. Does this mean that the answer is "No, it is not possible. You have to use an old compiler version?"
I was thinking STL was a standard implementation, though TR1 may not be. But does the platform matter? I was thinking it would work on Windows/Linux/Unix/Mac. I have people saying it wont work on anything other than Windows.
Please let me know.
-TIA
No, the STL ( not to be confused with the C++ standard library ) was developed by Alexander Stepanov when working for HP and Silicon Graphics. Much of the STL later was included into the C++ standard library, hence sometimes the STL and the templated containers in the C++ standard library are confused.
The second STL implementation (SGI) was designed to work with any standard complient C++ compiler, though IIRC not the early Microsoft 'C++' compilers due to lack of required features. (I seem to recall trying to play with it in the late 90s). The C++ standard library now requires some compiler intrinsics so there is no 'standard implementation' possible. (IIRC these are for atomic operations, but edit or comment if you know better)
So the implementation of the C++ standard library which ships with Visual Studio will only work with 'Windows'*, and probably only with Microsoft's C++ compiler. Other implementations will work with other compilers and on other platforms.
*Visual studio C++ can cross compile to other variants of Windows, so a version of the standard library for Windows 10 x64 will not work on Windows 7 ARM embedded.
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 am an experienced Mac/iOS developer, but I initially started to program in C++. I haven't touched C++ for years, and now, it's time to do so, because I want to have multi platform support for a new kind of file type I am trying to create.
C++ has evolved over the years, to what I find is a very bloated mess of 3rd party libraries and an effort by the C++ standards committee to control the evolution of the language. Hence, my questions.
I want to have as much advanced tools at my disposal as possible, and at the same time conform to standards as possible. My main development platform is OS X Lion, and I have access to a fedora 16 installation. I want to target Lion and above, Windows XP and above, and the latest Linux kernels, so backwards compatibility is not an issue here.
One choice is to install the Boost libraries to my machine, but to what I have experienced a long time ago it is a very painful process, with compile-time errors and quirks that have to be done to OS X. I don't know if that experience will be the same if I try that now. The other choice is to stick with TR1 which Lion currently offers. However, TR1 is not a standard as I understand, it is a de facto popular implementation of things that were scheduled to be done in C++11. That way I lose a lot of advanced features that Boost offers.
With these two options in hand, what is the recommended way to have advanced C++ features at your disposal and conform to standards as much as possible? If it's Boost, is it recommended to compile Boost as static libraries in order to avoid installing Boost on end-user machines?
What is the current support of Xcode 4.3 for C++11 features?
I would appreciate any comments on the above questions as well as any other thoughts on the matter. I am trying to get in sync with the current version and features of C++ and I begin to realize that this may not be so easy as I initially thought.
Thanks.
First of all, there are two very distinct parts in Boost:
those which are header-only
those which require compiled libraries
If you stick to header-only, it will definitely be much easier. Note that some libraries, like Asio, have two compilation modes (header-only and library). A number of useful libraries, however, such a boost::regex, do require a compiled library.
Second, C++11 support is moving fast. GCC 4.7 and the upcoming Clang 3.1 support all major features of the Standard, except from atomics (discussions are still ongoing on the best implementation strategies), so on Linux and Mac, things are great... however Visual Studio is lagging behind, and Microsoft is not really interested in moving fast, so on Windows support is minimal still (and advertised supported features are based on older versions of the Standard and not 100% compatible with the last version). It does not mean you cannot compile for Windows, merely that you should use Mingw or equivalent and thus forgo interaction with existing Windows DLLs.
Based on those two observations, I would recommend:
try to avoid C++11 for now if you want to interact with Windows DLL, otherwise I would recommend Clang (for its integration in XCode)
try to avoid Boost libraries and stick to the header-only parts (there is still much goodness)
if you want libraries, you can use DLL as long as you distribute them alongside the executable or use a package system or whatever, but it does present a greater difficulty (for the installation) than just static linking.
Note I'm not a Mac developer but I'd prefer Boost. Many C++11 standards are taken from it and you can expect more Boost features will be ported to C++ standards.
And as a Qt enthusiast: take a look at QtCore. It's very powerful and cross-platform.
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.