Is there a way to limit the MSVC to only support c++11 features but not anything from c++14 or 17?
I am using MSVC++ 14.1 _MSC_VER == 1910 (Visual Studio 2017 version 15.0)
Thanks!
It doesn't appear so. MSVC's C++ compiler does have a /std compiler option, but the documentation only says it can be used as /std:c++14, /std:c++17, or /std:c++latest (to include some features from C++20 drafts).
However, there are not a lot of huge changes between C++11 and C++14, and many of them can be considered "fixes" to things that were inconvenient or just missing from C++11. So maybe /std:c++14 could be close enough for your purposes?
I don't know what specific C++14/17 features are you trying to avoid but you can have a look at Microsoft's Support For C++11/14/17 Features (Modern C++) and select the version of Visual Studio whose feature set is closest to what you are seeking.
You can either use that version of Visual Studio or any later one since Visual Studio supports compilation with older toolsets provided you have them installed.
I need to remove unused variables and functions(Deadcode) in a c code. Can I use VisualStudio 2013 Pro code analysis to find unused c variables? Because in the rule set, Microsoft.Performance rules are not available for unmanaged code. is there any other tool I can use to find deadcode in c? Will ReSharper help?
Visual Studio 2015 offers _isnan and std::isnan to check if a double is NaN.
Following VS's 'Go to Definition' does not end up in the same place for both functions and assembly output from a simple program that checks for NaN is not the same.
How is _isnan different to std::isnan? Which should I use when writing C++?
_isnan is from Global Name Space which uses #include <float.h>
std::isnan is from Standard Name Space which uses #include <cmath>
You can use any one of them with Visual Studio 2015. Doesn't matter.
Refer this for more on this
From private communication with James McNellis of Microsoft (posted with approval):
"They were integrated into the C Runtime at different points in time. _isnan was integrated some time ago along with a handful of other IEEE recommended functions; isnan was added later as part of the C99 additions.
If you find a case where either produces an incorrect result, please do file a bug at https://connect.microsoft.com/visualstudio/."
I conclude from this that _isnan and std::isnan should do the same thing.
I'm using Visual C++ in Visual Studio 2010 Express, and in the past I remember when you use a string object and after the dot (eg: .) all the member functions will show in list, but that's not happening.
string myString = "hello world";
myString.
After typing the dot, all functions that are part of the string class don't show. Where in Visual C++ is the setting to make them show?
The functionality you refer to is called IntelliSense in Microsoft-speak, their version of autocompletion for variable names, functions, and methods.
IntelliSense is not supported in Visual Studio 2010 for C++/CLI projects. You will only get IntelliSense for projects written in native C++ code. This is explained in more detail here on the Visual C++ Team Blog. There is also a bug filed on Microsoft Connect; the official word is this:
Thanks for your feedback. Unfortunately in this release we had to cut the intellisense support for C++/CLI due to time constraints. If you want to get some intellisense like quick info and memberlist on the native classes you can get it by choosing no /clr support in the project properties.
Thank You!
Visual C++ Team
This is unfortunate news for many of us who work with C++/CLI projects, and we aren't left with many options. A question regarding those options has been asked here: What are people replacing the missing C++/CLI Intellisense in VS 2010 with? The summary is people are either going back to VS 2008
(I believe the Express Edition of 2008 is still available for download if you look around), or purchasing third-party software such as Visual Assist X that promises to bring back IntelliSense.
It's worth mentioning, however, that Microsoft does not regard C++/CLI as a "first-class" .NET language. There's little (if any) reason to start new projects using the language. It's designed for interop purposes between native C++ and managed C# applications. If you want to write C++, you should target the native Windows API (create a new Win32 project in VS). If you want to write managed .NET code, it is highly recommended that you use C# instead (that's a different version of Express that must be downloaded separately). The syntax is very similar between C++ and C#, but you will still have to learn the .NET Framework and idioms. Both native C++ projects and managed C# projects have very much improved IntelliSense support in Visual Studio 2010, so you're guaranteed to be much happier with either of those.
I've got an C++ application originally written with Visual Studio 6.0
The application is standard and raw Win32 API, no MFC(*Edit 2), no .NET, statically linked, multi-threaded executable.
I have migrated through all versions of Visual Studio up to 2010 (today) and never had any problems until now:
It compiles and runs perfectly with VS2010 BUT the generated executable size is four (4) times larger!
I've tried all the options I know (optimizations, remove debug info, etc..) with no results. Granted, I am new to VS2010, but not to Visual Studio.
Has anyone encountered this problem? Again: I am NOT using any frameworks, it is a raw, statically linked, Win32 application, no DLLs, no ODBC, no network, no .NET
Hoping to see my executables small once again, I thank you for any input.
Edit 1:
Original Size=626KB (VS6.0, VS2008)
Bloated size=2.013KB (VS2010)
Edit 2:
After some research and dumps, I discovered a hidden reference to MFC.
Originally I said it did NOT use MFC, but it does.
The increase in size may be caused by changes to the MFC. Here is an explanation, and here is a workaround by the same author that brings the executable's size back down into regions where it was with 2008. The workaround involves editing copies of MFC source files, though, a process not everybody may be happy with, and which needs to be repeated after every update, e.g. after installing a Visual Studio service pack.
Update:
It looks like the OP does not use MFC, so these might be two different issues. I have experienced the size increase myself but unfortunately cannot say whether caused by MFC or not since my project statically links to the MFC.
If you are using static linking, I suggest using the linker switches if you are compiling at the command line using the syntax:
cl /Ox [your C++ source file(s)] [libraries required if any] [resource files required if any] /link /FILEALIGN:512 /OPT:REF /OPT:ICF /INCREMENTAL:NO
If you are building within the Visual Studio IDE, you check the linker settings by selecting the project properties from the menu. In the configuration, select the Release and then click the linker settings found on the left pane, this will show you a list of configurations corresponding to the linker settings currently set by default.
In the Command Line under the linker, specify the option /FILEALIGN:512 in the Additional options entry then click the Apply button. In the General option under the linker, disable the incremental linking by selecting No(/INCREMENTAL:NO ). In the debugging option of the linker, select No for Generate Debug Info. For the linker optimization, you select the Eliminate Unreferenced Data(/OPT:REF) in the References and Remove Redundant COMDATs(/OPT:ICF) in the Enable COMDAT folding.
For the compiler optimization, make sure the Release configuration is selected, click the C/C++ tree view on the left pane and under that, click the Optimization, Select Full Optimization(/Ox). In the General setting under C/C++, Select Disabled for the Debug Information Format.
Don't forget to click the Apply button for every changes you make.
I hope everything I've mentioned here would be helpful to you and all of these applies to Visual C++ 2005 and 2008 but hopefully, it would also apply to Visual C++ 2010, if not, kindly check the documentation included with your Visual C++ 2010 installation.
Any chance you've left the default platform target at "Any CPU"? If so, change it to x86 for 32-bit only code. I'm guessing that will make up most of the difference. The remainder is likely in changes in compiler optimizations (more aggressive loop unrolling and whatnot where size has been traded for speed since RAM is cheap). I believe all the granular optimizations are still available from the command line, but many have been obscured in the UI options panels.
See Are there any tools for tracking down bloat in C++? - some techniques how to analyze what contributes to the executable size are described there. Once you perform analysis on both VC 6 and VS 2010 output, hopefully you will find something useful.
There is one particular gotcha which has hit me when porting from VC 6 to some Visual Studio edition: meaning of some optimization options has changed and the values I was using in the VC 6 project were no longer supported, and as a result the exe produced by VS was not optimized at all, causing both executable bloat and slow performance. Check your optimization settings in Properties/C/C++/Optimization and make sure optimization is on /Ox, /O2 or /O1.
This is because in VS2010 Microsoft added functionality allowing HTML components in a dialog windows so a bunch of stuff is pulled in and linked in even if you aren't using it and the optimizations and options and removing unreferenced code do not help. There is not a "good" way of removing the code, but there are some hacked up ways. We compile our size-critical stuff on VS2008 still because of this. Side note, our non-GUI code actually compiles smaller for what that's worth. Hoping MS comes up with an option for this in a fix/patch so I can do everything on VS2010 but I'm not holding my breath...