Trivial C++ code passes in a test project and fails in the main one - c++

These two trivial lines of code:
const bool equal = (HUGE_VALF == HUGE_VALF);
static_assert(equal == true, "Fatal error");
in a test program work perfectly (no warnings and no errors).
When I copy them in the main project, I get this error on the assert:
error C2057: expected constant expression
Here the equal object is a constant with value = true.
Those lines of code are in both cases inside functions.
The two projects have identical settings (C++11, Visual C++ 2013 compiler, Visual C++ 2019 IDE, /W4, no optimizations).
What could be the reason of this different behaviour from the compiler?

When a newer Visual Studio IDE (like VS 2019) loads an older project for the first time, it asks to retarget the project. If You have the old Visual Studio installed, You can reject this action. Then the compiler from the original VS will be used by the newer IDE.
After loading the solution, in the Solution Explorer next to the project name, You will have the Visual Studio which will be used to compile the project.
If the paranthesis is missing, that means the compiler and standard library from the current Visual Studio is been used.
As mentioned in the comments:
I have no parenthesis after the project name (if I am looking in the right place). However, I realised about the issue in the include file paths: Test Project: 14.24.28314\include\cmath; Main Project: Microsoft Visual Studio 12.0\VC\include\cmath, i.e. a much older version, that internally still relies on the C math.h header. So, same compiler (VS2013), different libraries...
This indicates that You have most probably retargeted the project or created a new project in VS 2019.
To make a project in VS 2019 make use of the older compiler, You need to got to the project Properties -> Configuration Properties -> General -> Platform Toolset and change it to the appropriate Visual Studio.
Also make sure that all configurations (Debug, Release,...) for all machine types (32bit, 64 bit) have this setting the same value.
Because the test project is using VS 2019 - it has all the required definitions - so it works.
So the issue is that most probably, VS 2013 standard library is not C++11 complete and does NOT have a definition for HUGE_VALF.
But it could contain a definition for HUGE_VAL

Related

Are dll made from Visual Studio 2019 (v142) are imported in Visual Studio 2013 (v120) project?

I made a C++ Windows library with Visual Studio 2019 (toolset v142).
Now my library should be included in other C++ project which is build in Visual Studio 2013 (toolset v120).
What I want to know is: Is it a problem to use a dynamic library built with the v142 toolset in a build using the v120 toolset? If so, how can I rebuild the library in Visual Studio 2019 to fix this?
When my clients build their project with my library in VS2013 with
release mode there is no problem. But the build failed in debug mode.
After changing from release to debug mode, the project properties are reset, and you need to manually set it again.
If you use a pure C interface, ensure that the exported things do not have C++ data types and there will be no errors. And you need to make sure your clients use the same environment as you.
If you have to pass the C++ data type, not only the compiler version must be the same, but the C++ version must also be completely consistent. For example, the data structure of MSVC C++17 std::string has changed,
If different versions are passed to each other, the program will crash.

How to solve: The "Microsoft.VisualStudio.ProjectSystem.References.UnresolvedBuildDependencyProjectReference" reference could not be resolved?

In the Solution Explorer, the vcxproj projects that have references, show a warning symbol on each of the references associated with the project. When the reference is highlighted, the properties panel indicates that the Full Path is:
The Microsoft.VisualStudio.ProjectSystem.References.UnresolvedBuildDependencyProject Reference" reference could not be resolved.
If the "..." box is pressed, the same error messagebox is shown and I am unable to select a new reference. I have tried deleting the reference and adding it again, but the result is the same. When new projects references are added, the result is the same.
All this happens when I compile using the Visual Studio 2008 (v90) toolset. If I compile using the Visual Studio 2015 (v140) toolset, the Full Path to the referenced library is shown correctly.
Some Background:
I upgraded my project from Visual Studio 2008 to Visual Studio 2015. This project contains a mix of managed and unmanaged with type .vcxproj. On this machine, the Visual Studio 2008 redistributable has been installed. This enabled me to compile using the Visual Studio 2008 (v90) toolset. My intention is to first compile my project with my VS2008 settings within VS2015 (For restrictive reasons, I have to use the v90 toolset). Thus, I configured the VC++ directories accordingly. There is no Linker option in the Configuration properties of the linking project. In the properties of the reference, the following configurations are enabled:
Copy Local - True
Copy Local Satellite Assemblies - False
Reference Assembly Output - True
Link Library Dependencies - False
Use Library Dependency Inputs - False
Full Path - The "Microsoft.VisualStudio.ProjectSystem.References.UnresolvedBuildDependencyProjectReference" reference could not be resolved
I ran into the similar issue. In my case just closing the solution and opening it again fixed the issue.

Does VS2013 use the same C run-time as VS2012 (e.g., msvcr110)?

I've generally assumed that each version of Visual Studio was tied to a different version of the C run-time. For example: VS2005 : msvcr80.dll :: VS2008 : msvcr90.dll
One of my co-workers told me that his installer indicated that our VS2013 project had a dependency on msvcr110.dll. We both found this odd, because this is the same dependency used by VS2012.
However, MSDN backs this up:
Visual Studio 2012 C Run-Time Libraries
Visual Studio 2013 C Run-Time Libraries
Does Visual Studio 2013 indeed reuse the run-time from 2012, or am I missing something?
Edit: I forgot to mention in my original question that the Visual Studio 2013 redistributable run-time comes with a file msvcr120.dll. My confusion comes in from the fact that this file exists, yet is neither identified by our installer nor mentioned in the MSDN documentation.
Edit: After talking with my co-worker about how the dependency was being determined, the reason the installer thought our projects had a dependency on msvcr110.dll was because it was looking at an old build.
This just unfortunately coincided with the copy/paste error in the MSDN documentation regarding the versions of the run-time. I'll contact Microsoft to let them know about the documentation error. Thanks again for the help, everyone.
Note: Even if they did use the same run-time, I wouldn't assume such for any future releases. I just found this curious.
By default VS 2013 C and C++ projects will depend on msvcr120.dll (or the debug build equivalent of msvcr120d.dll).
However, it's very easy to change the dependency to msvcr110.dll by changing the 'platform toolset' to "Visual Studio 2012 (v110)" in the project settings if VS1012 is installed on the machine. Older versions of the runtimes going back to VS 2008 (v90) are supported.
I assume that the doc page for the 2013 runtime that you linked to wasn't updated due to a simple oversight.

Il mismatch between 'P1' version '20080116' and 'P2' version '20070207'

I am building MFC application which uses other c++ library.I am using vs 2008 and compiled all the library project in vs 2008.
It is compiling well in debug mode but failed to run in Debug Unicode mode,Release,Release Unicode mode.
I found in the net that VS 2008SP1 is required to be installed but how come it is compiling in debug mode.
Please suggest how to overcome this problem.
If compiling a solution with multiple projects you should compile all projects with the same compiler (version) to be sure it works.
I once got the same error message like you. If I remember correctly the problem occured because link time code generation was used. My solution was to rebuild all, another solution might have been disabling link time code generation.
In Microsoft terminology, P1 is the parser (front-end), and P2 is the code generator (back-end). With link-time code generation (LTGC) enabled, the result of P1 is stored in a file and P2 is performed later at link time.
If you downgraded your compiler, you should do a full rebuild, otherwise the link step will try to use the incompatible P1 output, which will trigger that error.
If you upgraded the compiler, Visual Studio automatically does a full rebuild, so this should never happen (if it does anyway, just perform a full rebuild).
I had this problem just with other numbers as well using Visual studio 2015.
The problem was in one of the libraries that I linked to my project was build using VS2015 Update 3. The solution that worked for me - update Visual Studio to 2015 Update 3.
In my case, I just installed Microsoft Visual Studio 2008 Service Pack 1 (Installer) which resolved the problem. Service Pack can be downloaded from following link:
https://www.microsoft.com/en-us/download/confirmation.aspx?id=10986

Visual Studio 2008 Express MFC Support

As may be known by many, the Express versions of Visual Studio 2008 don't include support for MFC and a few other packages required to compile a lot of windows programs.
So, here's my problem:
I have the full version of Visual Studio 2005. I've been using this to compile a project that a friend of mine was working on, so that I could test it out for him and continue to track bugs and things. Recently, he upgraded that project to VS 2008, which I don't have. So, I downloaded the express version in the hopes that I could simply compile with that, but no luck, it complains about headers missing left and right.
It seems to me that since I already have the full version of VS 2005, I'm bound to have at least some (perhaps older) version of the files in question that his project needs to compile against.
Is there a way I can convince VS 2008 to also look in 2005's directories for include files and library files to compile against?
Furthermore, is this a bad idea? I would really prefer not to go out and purchase VS 2008 full, as I'll never use it myself. (2005 does the job fine for me at the moment, and I tend to prefer GCC anyway.)
Thanks
You can use the VC++ compiler directly from the command line, or just create a new project w/ the source in Visual Studio 2005. Unless he is using some functionality provided in the new versions of MFC/ATL in 2008/2008sp1, you should be able to compile the project just fine.
See ("Create Project from Existing Source") in Visual Studio 2005. It is unfortunate that they don't include these libraries with the Express Editions.
Use the vcvars*.bat script(s) from Visual Studio 2005. See this blogpost from VC++ Blog to see how. You will use the old compilers, but the build system from Visual Studio 2008.
You can go into Tools>Options>Projects and Solutions>VC++ Directories
and alter the Include, Library, and Source (and Reference maybe?) folders to use VC++ 2005's folders.
I'd guess you just replace $(VCInstallDir) with a hardcoded VS 2005 path. I'd record the original values before doing this.
However, have you just tried using the OLD 2005 sln and vcproj files? Keep using 2005 on your end and 2008 on his. Keep two sets of these files for each IDE. Any issues are going to be with the library mismatch - which you're not avoiding by using 2008's tools with 2005's libraries.
The simple way to deal with this would be to revert the solution and project files back to their visual studio 2005 state from source control(you are using source control right?). At this point you can compile the project as long as your friend does not use any of the mfc 9 only functions.
The first thing I would try is loading this up in VS 2005 by just modifying the version of the .sln and the .vcproj files. In the .vcproj change the version from 9.00 to 8.00 and in the .sln change the format version from 10.00 to 9.00.
If you don't have fancy stuff in the project you have a high chance of just being able to use it like this. Also this would avoid having to update 2 project and solution files.
On this website it is shown how MFC code can be compiled with the Visual Studio Express versions:
link
Just for the record, I've done that(by modifying the include directories and library directories from inside the IDE) and it's working pretty well, I have MFC, ATL, everything.
I've found this explanation. http://www.codeproject.com/Articles/30439/How-to-compile-MFC-code-in-Visual-C-Express