I would like to know, is there a MSVC(++) equivalent for the -Weffc++ flag? What number is it?
I didn't see anything like it in the list of compiler warnings/errors on the MS website.
There's not any equivalent.
Visual C++ doesn't have warning groups at all, only the warning level slider, and the ability to disable individual warnings. So none of the GCC/clang warning group options have an equivalent.
Beyond that, the Effective C++ book is rather old and some of its advice is no longer considered to be best practices. So enforcement has minimal value.
Some editions of Visual C++ come with code analysis, which has many more of these checks than the basic compiler. That's turned on using /analyze, documentation is here: https://learn.microsoft.com/en-us/visualstudio/code-quality/code-analysis-for-c-cpp-overview
Strictly equivalent probably not, but starting from Visual Studio 2015 there is C++ Core Guidelines checkers: https://learn.microsoft.com/en-us/visualstudio/code-quality/using-the-cpp-core-guidelines-checkers
Related
I'm working with a C++ library. The library's minimum requirements are C++03. I'm catching some warnings under Visual Studio 2015 regarding throwing destructors:
... algparam.h(271): warning C4297: 'AlgorithmParametersBase::~AlgorithmParametersBase':
function assumed not to throw an exception but does
... algparam.h(271): note: destructor or deallocator has
a (possibly implicit) non-throwing exception specification
The throw was by design in the 1990s when the code was written, but its showing its age now. We are kind of boxed in at the moment because we are not ready for a major version bump. (And its not as bad as it sounds prima fascia because it guards the throw based on uncaught_exception).
I want to remediate the issue by detecting C++ 11, and then adding noexcept(false). I was going to hide it in a macro so the code would compile under both C++03 and C++11.
The following does not work to detect C++11 under Visual Studio 2015. It does not produce the expected compiler error:
#if (__cpluplus >= 201103L)
# error Not C++11
#endif
Additionally, Microsoft does not appear to offer a Predefined Macros for detection of the language features.
How do I detect C++11 under Visual Studio 2015?
Related, I can detect the version of MSVC compiler via _MSC_VER. I think it will be _MSC_VER=1900 for VS2015. But it does not tell me anything about the language features.
Language features are important if the user enlists VS2015, but uses a downlevel C++ standard. Also, I don't have VS2013 to test, so I'm not sure a 1-off string like _MSC_VER=1700 is a good idea. I'd much rather learn if its C++11 or not.
I've run into similar issues on OS X and Linux with Clang and GCC compilers. See, for example, How to guard move constructors for C++03 and C++11? and What differences, if any, between C++03 and C++11 can be detected at run-time? But in this case, I want to detect it via the preprocessor.
Finally, this library does not use Autotools, Cmake or Boost. It has no external dependencies.
You can't detect the language version independently of the VS version, because VS does not offer language versioning switches- there's no such thing as VS2015 C++03 mode. The condition you're trying to detect (a downlevel standard with VS2015) does not exist, which handily explains why there is no feature macro to detect it.
Simply detect the VS version and switch off that.
Sometimes when I compile C++ projects, the build goes successful by saying "Build Succeeded". But, if you clicked on error list, it may show some errors such as "IntelliSense: incomplete type is not allowed".
My question is what is that "IntelliSense" errors and should I have concerns on output executable file?
Intellisense errors are not necessarily real compiler errors. Remember Intellisense is a separate partial compiler designed for speed over accuracy. It partially compiles your code to help generate IDE completions and also is used by the IDE underline possible errors in the Visual Studio IDE.
The IntelliSense parser, starting with VS2010, is a product of a different company. EDG, the Edison Design Group, pretty famous in the C++ world for being the only ones that ever wrote a front-end for C++03 that was 100% compliant with that standard.
But it isn't 100% compatible with the MSVC++ compiler. VS2010 were training wheels, they've been chipping away at the incompatibilities. Some differences are pretty fundamental, MSVC++ uses a uncommon way to perform macro substitutions in the pre-processor for example. A detail that was never specified in the language standard and Microsoft committed, early, to a choice that's different from everybody else's. Very hard to fix, way too many of their customers took a dependency on that.
You could look on the bright side of this problem. Your code is dodgy and likely to be troublesome if you ever port to g++ of clang. If you need help to get it undodged then just ask a question about it.
Alternative tokens are valid c++ keywords, yet in Visual Studio 2013 the following emits a compilation error (undeclared identifier):
int main(int argc, const char* argv[])
{
int k(1), l(2);
if (k and l) cout << "both non zero\n";
return 0;
}
Since and or not have been around for quite some time, is there a reason for not implementing them?
You ask about the rationale. Here's one possible reason, not necessarily the one that most influenced the Visual C++ team:
Those are valid identifiers in C.
Microsoft's recommendation has long been to use C++ mode for both C and C++ code, rather than maintaining a modern C compiler.
Valid C code using these as identifiers would gratuitously break if they were compiled as keywords.
People trying to write portable C++ are mostly using /permissive- or /Za for maximum conformance anyway, which will cause these to be treated as keywords.
The workaround to treat them as keywords in /Ze by including a header file is easy and portable. (G++'s workaround -fno-operator-names isn't bad either, but putting the option in the source code rather than the build system is somewhat nicer.)
VS is nonconforming. This is old news.
To use alternative tokens, include the <ciso646> header. According to the standard, including this header is supposed to have no effect in C++. However, you do need it in VS. So it's safe to just include it always, whenever there is any chance that you might be compiling with VS.
Formally, these keywords are implemented and are supported intrinsically by the compiler without including any headers. However, for that you have to compile your source code in "more standard" mode of that C++ compiler, which means using the /Za option.
By intent, the /Za option is supposed to "disable compiler extensions". Of course, not supporting something that is supposed to be there in a compliant compiler cannot be formally qualified as a "compiler extension". Yet, that just the way things currently are.
Modern Visual Studio (or rather, MSVC) does support alternative tokens; however, it does so only in standards conformance mode. This mode comes with lots of goodies, so it should always be used.
To enable it, pass /permissive- to the compiler.
The answer below is obsolete. This is now supported, see above!
Previously, Microsoft’s position was1 that
#include of <iso646.h> (or ciso646) is how we support these keywords
And because “nobody” (before me, in 2007) ever requested this.
1 link currently defunct; left here for archival purpose.
(contemporary update)
I made a small test: A New "Windows Desktop Application" Project. The IDE (Visual Studio 2017 15.7.5) sets, by default, the following C++ language conformance settings: /permissive- /Zc:wchar_t /Zc:forScope /Zc:inline. In addition, I set the C++ Language Standard to ISO C++ /Latest draft (currently up to C++17). In addition, I added, in the main(), the following 2 lines:
bool a, b, c;
a = b and c;
It compiles the text-forms of the logical operators successfully. But when I altered the IDE Conformance mode to No (=> without /permissive-) and re-compile, the compiler marks: "error C2065: 'and': undeclared identifier".
By default, the /permissive- compiler option is set in new projects created by Visual Studio 2017 version 15.5 (December 2017) and later versions. It is not set by default in earlier versions. So if someone created a project prior to version 15.5 and by the time update the IDE to the latest version, still it required to set in the project this compiler option manually.
The /Ze compiler option, which is on by default, enables Microsoft extensions. The /Ze option is deprecated because its behavior is on by default. MSDN recommends to use the /Zc (Conformance) compiler options to control specific language extension features.
I'm wondering how well writing software in C++11 works on Windows yet. It would be most comfortable (and propably most natural) to use one of the native compilers for Windows - I'm thinking about Visual Studio 2012 Express or Visual Studio 2013 Express here. Everything I could find so far on that matter is
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx
(Comparison of C++11 features of VC10 and VC11, which seems to be quite bad)
http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx (not really transparent, didn't give me a good idea how well it works)
Does anyone have any experience how well the current Visual Studio versions can handle C++11? I really want to start using auto, lambdas, variadic templates, template aliases, initializer lists and rvalue references (to name just a few) and all the other good stuff right now, but if Windows might be a problem I might have to use C++03 further.
Another possibility seems to be to install LLVM and Clang on Windows. My primary platform is OSX, and on that system Clang's support for C++11 is really good. But I read that the LLVM-version of the standard library for C++ (libc++) does not work well on Windows. So LLVM/clang might not be an option.
What are your opinions on C++11 development on Windows?
Thank you!
I can only give you my experience as a developer, as I've been building against the cutting edge of C++ on Windows using Visual C++ for just about everything, while also installing several other compilers and IDEs (including building Clang myself on Windows for Visual Studio 2012, 2012 CTP, and 2013 Preview). The following is my experience up until right now (August 13th, 2013), and is based on Herb Sutter's talk and working with the compiler every day.
The Quick
Run in the opposite direction of Visual Studio / VC++. Support for C++11 is slow, and they're currently being crushed in terms of compiler features versus Clang and GCC.
The Present
Visual C++'s C++11 (and C++14 support) is beyond abysmal right now. They lack powerful features that make template metaprogramming in C++ great (using expressions in particular).
Using doesn't exist right now. I have spent hours and hours porting great C++11 code with using to VC++, only to have it break it certain places, snap, or just become near damn unmaintainable.
Variadic support in the CTP was horrifically terrible, and while it got better for Visual Studio 2013 Preview's version of the compiler, it's still fairly bad at complex variadic and template expressions that obey the standard (and compile fine in GCC and Clang).
=delete and =default are pretty much gone from VC++ right now; in the hopeful near future, maybe it will work out (and it should come "soon-ish", according to the roadmap) (I had to implement r-value constructors explicitly for many simple classes all the way down a 8-class inheritance hierarchy once. It was the worst slap in the face, when I watched GCC and Clang users get all of my explicit hardcoded work for free with =default).
As a holdover (primarily because of Windows OS code and some binary compatabilities), Empty-Base-Class-Optomizations in VC++ don't work. Don't expect your class hierarchy sizes or member layout to be optimized in the least (watch your ordering in std::tuple when packing variable types).
This is about all the frustrations I've come into contact with so far. They're work-aroundable -- I have to work with them every day -- but if you want great C++ support, you should jump for GCC or Clang and somehow make it work on your machine.
The Future
If you really want C++11, you will need to wait about a year, and even then Visual Studio 2013's release of VC++ will still be missing a few features (and don't expect them to be bugless either). VC++ for 2013 will also still be critically missing std::move and explicit r-value support in many places, making it painful when you expect things to work.
The Caveat
If you're not a powerful Vim user, you're low on options when it comes to IDEs that you can work with (that play nice with GDB/GCC or Clang).
QtCreator is nice, works with MinGW, and is generally fully featured enough to get work done.
Sublime Text can be used, but you'll have to write your own building system or delegate that to something else.
Code::Blocks's autocomplete is wonky and behaves strangely, and the IDE itself feels clunky.
Eclipse is supposed to be good, but my experiences with it are clunky and strange, with odd input lags at time (despite a 8.00 GB i7 Haswell machine using an SSD).
Visual Studio, as an IDE, is pretty solid. Then stack Visual Assist X on top, and it works pretty damn well for C++ coding. It's really the only reason I continue to stick with it, but I've already made headway into learning Vim so I can mostly ditch Visual Studio altogether, when the time comes.
About Libraries
Library support in VC++ is pretty complete (for as much as their broken compiler lets them be complete). It has regex, while most other libraries have non-existent or broken regex support. But that doesn't mean that the VC++ library plays nice with some C++11 features that it says it does (picture by melak47).
And Lastly
If you want code that you know is going to work in Windows, 100%, for the rest of eternity, you'll probably want to program against VC++. The other "benefit" is that the code you write in VC++ is the smallest subset of C++/C++11 you can write with, so in the end it should compile everywhere. Of course, that goes against the very idea of using beautiful C++11 and enjoying it, so... pick your poison(s) wisely.
VC's C++11 support is far from complete, but it does include the most important user-facing features.
And here's the other thing. In my experience, it is fine to install MinGW or Clang on Windows, but you're going to have some inconvenience because hardly anybody precompiles binaries for those compilers for Windows (whereas lots of people precompile binaries for Visual Studio).
In addition, there are as far as I am aware no environments for Windows which are remotely as advanced as Visual Studio for things like graphical debugging, intellisense, and stuff like that. When I tried Code::Blocks it just didn't work, realistically.
You can see here for a comprehensive comparison of compiler support for C++11 language features. Here's some info on VS's C++11/14 roadmap.
MSVC is lagging behind the other major C++ compilers but it's still got support for many of the most important features.
auto, lambdas, and rvalue references are available from VS10. IIRC there's a caveat with rvalue references that the compiler doesn't generate move construction and move assignment operators.
variadic templates and initializer lists are available in the VS2013 preview, including library support.
type aliasing (i.e., typedefs with the using keyword) is expected to be available in VS 2013 RTM.
If you don't need to interoperate with binaries generated by VS then installing another compiler such as GCC is workable. I understand Clang can also work in a mingw environment, with libstdc++ rather than libc++.
http://nuwen.net/mingw.html
The nuwen distro is AWESOME! It is MinGW but it comes out much quicker than MinGW as new GCC releases come out. It also comes with all of boost and other useful libraries already compiled. It is all I use on windows anymore.
We are using C++11 for a few months already in production software across windows and linux in some here.com products without any problems. We use auto, lambdas, range for... Using Visual studio 2012 and gcc 4.7.
I have been using VS2012 and used C++11 features where possible. There are some bugs in the implementations and I have found it helpful to have another compiler to hand when I get errors from Visual Studio to compare against.
Clang and GCC to lead the way in terms of C++11 feature support and it appears to be a neck-and-neck race in terms of C++11 support between the two. MSVC is sadly panting trying to keep up and lagging behind. The Nuwen MingGW distro is, as Jake mentions, excellent and appears to be working well with Eclipse (Kepler release) and I didn't encounter too much pain using it with Netbeans 7.4 either. The Nuwen distro is currently at version 11.2 at the time of writing and, as you can see at Stephan's website, is now x64-native, featuring GCC 4.8.1 and Boost 1.54.0, with GCC's default mode also set to C++11.
I'm certainly beginning to use Eclipse Kepler and Nuwen MinGW in preference to MSVC 2012 more and more, but I'm largely a hobbyist C++ programmer still getting my feet wet and may not have hit the more obscure problems that those to whom C++ is their bread and butter may know about.
I find C++ is very controversial language in microsoft world. By default we have ISO C++ and then microsoft has Managed C++ and now C++ CLI.
I just know standard (ISO) C++. I don't know microsoft's version of C++.
I'm confused about interpretation of any c++ code by visual studio 2008 (or later). Thats why I'm using gnu tools for compiling my programs. But I do love Visual Studio.
What settings do I need to make if I only want to use
STRICTLY ISO C++
Managed C++ (its deprecated but I think they still support it for sake of backward compatibility)
C++ CLI (for .NET platform)
I want to build native assemblies using C++ not managed ones. So, is there anything else should I need to do?
Everything is in the build settings:
Common Language Runtime Support (/clr) - add or remove CLR support
Advance Compile as C++ Code (/TP) - to choose if c++ or c..
Language: Disable Language Extention - use this to force ANSI.
When you ask Visual Studio to make a C++ project, it makes a C++ project. C++/CLI is a different language.
VS2008 and earlier have implemented C++03 (or approximated it. Like almost every other compiler, there are bits of the standard that are not followed to the letter. A few features are not implemented (exception specifications, the export keyword or two-phase name lookup are the ones I can think of), and some proprietary extensions are added as well.
GCC, and most big compilers, do the exact same thing, so this isn't a case of Microsoft being "evil" as such. The extensions can be disabled, leaving you with a reasonably standards-compliant compiler.
VC2010 is adding a number of C++0x features (and at least in the beta, I haven't been able to find an option to disable these), so from a strict C++03 compliance point of view, it is going to be less compliant.
Dani's answer already tells you which settings to change to enable/disable different language dialects.