I am developing some applications (MSVC++) and I always run into deprecation warnings. To be general, in this question I am asking lets say I use the standard C90:
fopen()
over
fopen_s() <- as msvc++ suggests for me to use
Does this mean that after compiling my application, lets say a windows 8 user wants to use it, would he get less of the feature from it, in lesser terms, does that mean when he runs the application then the fopen() function will not be recognized since it is "deprecated" (I assume it means it's outdated)?
Also, if say it doesn't matter whether I use it or not, MSVC++ says that I can use the _CRT_SECURE_NO_WARNINGS flag to ignore deprecation, if so, where can I include this flag so it ignores the warnings?
In the case of the MSVC runtime functions, no, there is no risk of compatibility problems if you use deprecated functions like fopen().
The code for fopen() exists in the MSVC runtime library and your application either (a) links with that library statically, or (b) uses a specific version of a DLL. The DLL version used by the app will be the same wherever your app runs, so you don't have to be concerned about Windows 8 not having an appropriate DLL.
The MSDN documentation Security Features in the CRT states:
In this context, "deprecated" just means that a function's use is not recommended; it does not indicate that the function is scheduled to be removed from the CRT.
Related
I've been looking into some of the features of the "newer" C++ standards (C++11 and C++14), and that got me thinking about something. I'm currently using the VC++2008 compiler for my projects (for various reasons), which means that the newest standard I have access to is C++03, plus TR1. TR1 has some nice things in it, but there are features in C++11 and C++14 that would be nice to have.
My question is this: Would there be any way that I could build some code using a newer compiler (say MSVC2012 or 2013) to build libraries or DLLs using the newer C++11 and C++14 functionality and then link that into my project that's running the '08 compiler?
The only thing that I could think of that wouldn't work would be anywhere I had to have a C++11 or C++14 feature in a header included by my '08 compiler project. However as long as everything "new" were hidden behind my interface, shouldn't this work?
Yes but its going to get ugly.. since the ABI is not compatible you'll have to go down to the "extern "C" {}" ABIness.
That means you can't pass C++ objects at all.. like I said, painful. It also means it must be a DLL since you won't be able to link in a static lib with another ABI.
Its up to you if its worth wrapping up a DLL in a C API just to use a couple of new features or not, I would recommend just upgraded the whole project though.
I almost forgot, you probably can't link the import lib either, so you'll have to have some code that uses LoadLibrary, GetProcAddress and FreeLibrary (did I mention this is ugly/painful?).
Unfortunately, what you're trying to do is not possible with MSVC. They intentionally break binary compatibility with every major release as stated in MSDN documentation:
To enable new optimizations and debugging checks, the Visual Studio implementation of the C++ Standard Library intentionally breaks binary compatibility from one version to the next. Therefore, when the C++ Standard Library is used, object files and static libraries that are compiled by using different versions can't be mixed in one binary (EXE or DLL), and C++ Standard Library objects can't be passed between binaries that are compiled by using different versions. Such mixing emits linker errors about _MSC_VER mismatches. (_MSC_VER is the macro that contains the compiler's major version—for example, 1800 for Visual C++ in Visual Studio 2013.) This check cannot detect DLL mixing, and cannot detect mixing that involves Visual C++ 2008 or earlier.
Your options are to then only pass around POD types, or implement COM interfaces to interop between the DLLs compiled using different version of the VC compiler, neither of which is particularly palatable.
My advice would be, if you must stick with VS2008 for certain legacy applications, suck it up and deal with the feature set it supports (at least you have TR1). For newer projects, try and talk your team into using newer versions of VC.
I'd like to ask whether or not there is an advantage in msvcr100 over msvcrt and what would the advantages be.
When compiling with the msvc compiler, the executable I get is linked to msvcr100, so it requires MS Visual C++ Redistributable to be installed. If I compile it with g++ (mingw), then there's no such requirement. I'm guessing it's linked to msvcrt, instead.
I prefer to keep dependencies at a minimum, so I want to know if there's any point in using a compiler that links to mscvr100.
Thank you.
Msvcrt.dll is a private DLL, intended to be used only by Windows itself. Different versions of Windows have different versions of msvcrt.dll.
You'll have a serious headache when you discover that the way you use the CRT causes failure on a particular Windows version. Including the kind of failure that requires a time machine, a new version of Windows may have a new copy of msvcrt.dll that makes your program fail. A problem otherwise known as DLL Hell.
The advantage of using msvcr100.dll is that the odds for to happen are much smaller. You work with a known version of the CRT. Even if there's a breaking change in Windows itself that breaks msvcr100.dll then there's still a solution: you can update it. That is not possible with msvcr.dll, it is a DLL that's covered by the File System Protection feature. Overwriting it with an installer would normally be pretty disastrous because that can break Windows itself. But it cannot cause failure, Windows automatically restores it. Also the reason you should not follow Voith's advice.
If you use an MS compiler later than version 6, then you will have to link to the runtime specific to that compiler. You do not have any choice in the matter. Since the MSVC runtimes are not system DLLs, you will need to distribute them with your application.
If you use MSVC6, or a compiler that can link against msvcrt.dll, then you can link against msvcrt.dll.
The mingw compiler is quite configurable. However, I believe that it usually will link against msvcrt.dll. Since msvcrt.dll is a system DLL (since Windows 2000 IIRC) you do not need to distribute it.
I'm assuming in all of this that you link to the runtime dynamically. That is the preferred option, but it is always possible to link to the runtime statically. When you do that, you make your application standalone.
It all boils down to which compiler you prefer to use. If you prefer to use a modern MSVC, then you'll need to accept the runtime distribution, or link statically.
The question says it all.
I understand that VC11 is currently only in beta, but what I'm asking is:
experience with trying to link with a closed source (widely used if possible) library compiled with vc10
specifications from Microsoft saying explicitely if yes or no the vc11 will be able to link with vc10 libraries.
I'm talking about C++ case only.
You may want to read this answer for the case of dynamic linking.
Regarding static linking, I think you can't safely link C++ libraries written with VCx with code compiled with VCy. For example, STL containers implementations change from version to version (and even within the same version, there are changes between debug and release mode, and settings like _HAS_ITERATOR_DEBUGGING, etc.).
Quoting VC++ STL maintainer:
The STL never has and never will guarantee binary compatibility
between different major versions. We're enforcing this with linker
errors when mixing object files/static libraries compiled with
different major versions that are both VC10+ [...]
That's a resounding no! Every major release of VS has a new version of the dynamic CRT, names are msvcr90.dll for VS2008, msvcr100.dll for VS2010, msvcr110.dll for VS11.
Using the dynamic CRT (/MD compile option) is important when you return C++ objects like std::string from an exported function, or otherwise return any pointer that needs to be deleted by the client code. That can only work properly when the client code is using the exact same version of the CRT as the DLL. Implicit is that this won't be the case when these chunks of code each have their own dependency on a msvcrXXX.dll version, they'll inevitably have incompatible CRT versions that don't share the same heap allocator.
You can write DLLs that are safe to use with any CRT version but that requires carefully crafting the API so that these dependencies do not exist. The COM Automation model is an example of that.
For dynamic libraries, there should be no problem, as they follow well-defined ABIs. You can link to dll's from any compiler, any time.
Static libraries are trickier. As far as I know, Microsoft has never guaranteed cross-compiler compatibility for those. In particular, features such as link-time code generation have been known to break compatibility between earlier releases. .lib files do not have a single well-defined format like DLLs do.
It might work, because Microsoft rarely breaks compatibility unless they have to, but as far as I know, it is not guaranteed.
Of course, if the actual functions and types exposed by the DLLs don't match up, you'll run into problems.
In VC11, the sizes of almost all standard library data structures have been changed (Microsoft finally employs the empty base class optimization, effectively reducing the size of all containers which use the default allocator.), so trying to pass a std::string from a DLL compiled with VC10 into a module compiled by VC11 will certainly break.
I don't see any reason why they could be incompatible. No matter what C++ compiler you have used to produce LIB files as soon as they follow format specification. You could check this question if you are interested in details of format.
Thinking of using MinGW as an alternative to VC++ on Windows, but am worried about compatibility issues. I am thinking in terms of behaviour, performance on Windows (any chance a MinGW compiled EXE might act up). Also, in terms of calling the Windows API, third-party DLLs, generatic and using compatible static libraries, and other issues encountered with mixing parts of the same application with the two compilers.
First, MinGW is not a compiler, but an environment, it is bundled with gcc.
If you think of using gcc to compile code and have it call the Windows API, it's okay as it's C; but for C++ DLLs generated by MSVC, you might have a harsh wake-up call.
The main issue is that in C++, each compiler has its own name mangling (or more generally ABI) and its own Standard library. You cannot mix two different ABI or two different Standard Libraries. End of the story.
Clang has a specific MSVC compatibility mode, allowing it to accept code that MSVC accepts and to emit code that is binary compatible with code compiled with MSVC. Indeed, it is even officially supported in Visual Studio.
Obviously, you could also simply do the cross-DLL communication in C to circumvent most issues.
EDIT: Kerrek's clarification.
It is possible to compile a large amount of C++ code developed for VC++ with the MinGW toolchain; however, the ease with which you complete this task depends significantly on how C++-standards-compliant the code is.
If the C++ code utilizes VC++ extensions, such as __uuidof, then you will need to rewrite these portions.
You won't be able to compile ATL & MFC code with MinGW because the ATL & MFC headers utilize a number of VC++ extensions and depend on VC++-specific behaviors:
try-except Statements
__uuidof
throw(...)
Calling a function without forward-declaring it.
__declspec(nothrow)
...
You won't be able to use VC++-generated LIB files, so you can't use MinGW's linker, ld, to link static libraries without recompiling the library code as a MinGW A archive.
You can link with closed-source DLLs; however, you will need to export the symbols of the DLL as a DEF file and use dlltool to make the corresponding A archive (similar to the VC++ LIB file for each DLL).
MinGW's inclusion of the w32api project basically means that code using the Windows C API will compile just fine, although some of the newer functions may not be immediately available. For example, a few months ago I was having trouble compiling code that used some of the "secure" functions (the ones with the _s suffix), but I got around this problem by exporting the symbols of the DLL as a DEF, preparing an up-to-date A archive, and writing forward declarations.
In some cases, you will need to adjust the arguments to the MinGW preprocessor, cpp, to make sure that all header files are properly included and that certain macros are predefined correctly.
What I recommend is just trying it. You will definitely encounter problems, but you can usually find a solution to each by searching on the Internet or asking someone. If for no other reason, you should try it to learn more about C++, differences between compilers, and what standards-compliant code is.
Does Visual C++ runtime imply Windows platform? I mean if I write a program that only directly uses functions specific to VC++ runtime and doesn't directly call Windows API functions can it be recompiled and run on any OS except Windows? I don't mean on Windows system emulator, I mean a ready implementation of VC++ runtime for some other OS.
The Visual C++ runtime contains the standard C++ library and platform specific auxiliary functions.
The Windows API is part of the Windows SDK, and is not included in the Visual C++ runtime.
When you compile a C++ program on a different platform you will use that platform's C++ library implementation.
I mean if I write a program that only directly uses functions specific to VC++ runtime and doesn't directly call Windows API functions can it be recompiled and run on any OS except Windows?
As long as you only use standard C++ functions and classes, yes.
I don't mean on Windows system emulator, I mean a ready implementation of VC++ runtime for some other OS.
The runtime itself is only available on Windows, as the implementation is very platform specific. As I have mentioned above, you only get source level compatibility and only if you don't use MS specific functions.
The "VC++ Runtime" refers to Microsoft's implementation of the standard C and C++ libraries on top of Windows, so yes, in that sense it does imply the Windows platform. (In fact, it's implemented in terms of the Win32 API since the OS needs to support all of those great things the standard library can do for you).
However, since it's just the implementation of the standard libraries for the C and C++ languages, as long as you're careful to write portable code (don't assume type sizes, don't use platform/compiler specific extensions to the standard, beware of functions with differing names/arguments, etc. etc. etc.), you should be able to recompile it for any platform that has a C/C++ standard library implementation available.
These are two different questions. If you stick to portable parts of C and RTL, you can of course recompile for a different platform - I do that on daily basis. But a VC++-generated executable can only be run on Windows - it's a Windows executable :)
However, don't assume that the whole VC++ runtime library is portable. Some functions are (strlen() for example), some exist but are named differently (strnicmp()), some are simply absent on other platforms.
I mean if I write a program that only directly uses functions specific to VC++ runtime and doesn't directly call Windows API functions can it be recompiled and run on any OS except Windows?
If by "functions specific to VC++ runtime" you mean standard library functions, then the answer is yes (but with some caveats)
If you mean non-standard functions that are in the VC runtime but aren't standard, like _snprintf(), then the answer is generally no (but other implementations might support them so you might be able to get away with it).
The caveats from the 1st answer are that your program might take advantage of implementation specific (or even unspecified or undefined) behavior that might make it not work the same on a different platform, even if your program uses nothing but standard library functions. In most cases these issues won't be a problem, but they are something to take into consideration when writing code that you want to be portable.
Once upon a time it was possible (Visual C++ 4.x?) to target Mac (68000 processor) with MFC/Visual C++, but that project has been abandoned for a long time.
Microsoft Mobile/Smart Device is some sort of cross development supported in the latest version of Visual Studio.