I'm using Visual Studio Code for c++ with MinGW and g++. My code uses a couple of g++ predefined macros. These work in the compiler without any problem, but Intellisense doesn't know about the macros and that causes some misdiagnosed errors (and other Intellisense problems) in the editor.
I can get all the predefined macros for my particular configuration of g++ with this command:
g++ -dM -E foo.cpp > defines.h
And this allows me insert them into the "defines" property of the c_cpp_properties.json file. This solution is a hack though, and if I'm not careful it could completely undermine the purpose of these macros. I want the compiler and Intellisense to cooperate across multiple development platforms, and that's looking like a pretty complicated setup.
Is there a better way to let Intellisense know about the g++ predefined macros?
From what I can tell, Intellisense's ability to properly handle preprocessor macros is still limited. If you are using CMake for Makefiles, it appears that you can tell Intellisense what macros you have, as seen here: auto-defined macros. I have not played with this personally, but it would be worth investigating.
If you can't get this to work, I found a feature to just turn off the macro-based highlighting. In settings, set"C_Cpp.dimInactiveRegions" to false. This isn't ideal, because it stops all graying out, including debug blocks like if(0) {...}, but it could be a temporary fix and you might find it less irritating.
Apart from that, look closely for added features in future updates. I'll try to update this post when I find any new discoveries on the matter.
The property in c_cpp_properties.json called compilerPath allows IntelliSense to query the compiler for default include paths and defines. It may be necessary to set intelliSenseMode to gcc-x64 for this to work, as that is not the default on Windows. (I currently do not have a Windows setup so I can't test this for the time being)
Related
I've been searching around for different custom pre-processor extensions and replacements, but all of them seem to come with 1 of 2 caveats:
Either 1), you generate the code as a separate build-system, them manually put the output into your real (CMake) build system, or 2) you end up losing the builtin preprocessor for GCC.
Is there really no tool that can, say, run each file it gets against some configured script, then through cpp, then pass the result to gcc?
I'd love to use something like Cog by just setting an environment variable for gcc, indicating a tool that runs Cog first and then the standard preprocessor.
Alternatively, is there a straightforward way to accomplish that in CMake, itself? I don't want to have to write a custom script for each file, especially if I have to then hard-code the compiler/preprocessor flags in each target.
edit: For clarity, I am aware of several partial/partially-applicable solutions. For example, how to tell GCC to use a different preprocessor. (Or really, to look in a different place for its own preprocessor, cc1. See: Custom gcc preprocessor) However, that leaves a lot of work to do, to modify files, and then correctly invoke the real cc1, with the correct original arguments.
Since that is effectively a constant/generic problem, I'm just surprised there is no drop in program.
Edit 2: After looking over several proposed solutions, I am not convinced there is an answer to this question. For example, if files are going to be generated by CMake, then they can't be included and browsed by the IDE - due to not yet existing.
As ridiculous as it sounds, I don't think there is any way to extend the preprocessor short of forking Gcc. Everything recommended so far, constitutes incomplete hacks.
The GCC (C++ compiler) is made for compiling C++ programs. As the C++ preprocessor is standardized within the C++ standard there is usually no need for anything like a "plugin" or "extension" there.
Don't listen to the comments, that suggest you using any exotic extension to CMake or change source code of GCC. Running source files through a different program (cog in your case) before compiling is a well known task and all major build systems support it right away.
In CMake you can use the add_custom_command function. If you need this for more than one file, you could use a CMake loop like e.g. suggested in this answer.
But I want to use it with "Warnings treated as errors" = Yes
There seems to be a lot of useful check in the compiler flag but it isn't compatible with the standard headers. I want to use this compiler flag to check my code, but not the std headers. Is there a way to do this?
Or just disable warnings for any code I didn't write?
Edit:
Added pictures of the settings in visual studio and an example of what happens when I try to build. With just including iostream!
Example when trying to compile a basic C++ program with these settings
You can disable the warnings in the headers (or change warning level for them) by changing the warning level before each inclusion, see here: How to suppress warnings in external headers in Visual C++. However that is not so handy because it needs to be done for every inclusion.
However if you'd use precompiled headers (which might be actually good for compilation speed), you can put all the system/STL headers you care about into the precompiled header file, and disable them via pragmas just there. Or you would need to create wrappers for the standard headers where you'll disable the warnings and include the wrapper headers instead.
And as discussed, the "/Wall" sometimes goes too far (e.g. the padding is quite usual thing you sometimes even can't do anything about), and even with the "/W4" the documentation mentions that it might be too detailed (however at the same time recommends it for new projects, so I generally use "/W4 /WX" for new projects). However some of the "/Wall" warnings still might find subtle bugs (like missing case in switch etc.). You might as well enable just some of the extra warnings selectively.
I've been working on adding functionality to a C++ library. The library is compiled by using CMake. It has a complex set of dependencies. I have a C++ test file that runs code relating to the library. Let the compiled file be test.cpp, its executable test.
So far, I've been debugging by adding "cout" statements to the library files. I frequently get segmentation faults, but can usually figure it out by inspection. Obviously, this is inefficient. I want to see where the code fails, by using gdb. Via this stackoverflow post, I tried adding debug flags to my cmake, but when I run gdb on test and do bt, I don't get comprehensive info. I simply get the name of the function in the library where the code fails, not the exact line.
Anyone know how to get the gdb information?
While adding the respective compiler flags manually will work, it is not the most convenient way of doing so. As suggested by #ruslo, you should use the following command line instead for getting debug support:
cmake -DCMAKE_BUILD_TYPE=Debug <path_to_source>
There are several reasons for this:
Compiler flags are not portable. -g -O0 will work on gcc, but what about other compilers? One of CMake's main strengths is to make portability easy, so you should not throw it out of the window easily.
Multi-configuration generators (like most IDE generators) allow to use multiple profiles at once. You would not want to force users of those IDEs to compile without optimizations even though they selected a Release profile, would you?
Changes to CMAKE_CXX_FLAGS are global. This becomes especially nasty once you have to compose multiple projects together. If you absolutely need to manually give compiler flags, use target_compile_options for this purpose.
Last but not least: Setting CMAKE_BUILD_TYPE is the idiomatic solution to this problem. It is the one right tool for solving it and people familiar with CMake (granted, there are not too many around of those...) will be surprised if you solve it using a non-idiomatic workaround.
I've figured it out. They key is to add the "-g" flag to
SET (CMAKE_C_FLAGS ...
and
SET(CMAKE_CXX_FLAGS ...
to the CMakeLists.txt file.
Yes, it's a noob question...
I have been using Dev-C++ for all my projects so far, but it is incredibly outdated, and so where the libraries. So I opened up my copy of Visual C++ and copied the code. When I compile, a million errors pop up, as if every second line of my code is shit. I would hate to start the project again from scratch.
Question: Why is it that Dev-C++ and VC++ compile differently??? I've heard they use different compilers, but its still C++. The first error I looked at was an invalid comparison between a const char* and a std::string.
Anyway, is there any way to make VC++ less strict on programming, as is Dev-C++. Or are there a few major differences between Dec-C++ and VC++ compilers that I should know about.
Most of the errors seem to be std::string related, or LPCWSTR (i can fix that myself).
Sorry about this very broad and useless topic, I'm knew.
-Alex
First, a few notes, because many Dev-C++ users are confused (I used to be)
Dev-C++ is not a compiler. The compiler is GCC (or, more precisely, a modified version of GCC so that it runs on Windows : MinGW). Dev-C++ is an IDE : a text editor with an additional button which calls MinGW with the appropriate parameters when clicked.
Nothing more.
Same thing for Visual Studio : Visual Studio is the IDE, which calls the Visual Compiler (vc.exe), which implements VC++, which is Microsoft's implementation of the C++ standard.
Second : It's not a noob question. You have discovered portability issues, which is a great area of frustration in C and in C++. A lot of questions on StackOverflow are due to portability problems (a code that works on Windows but not on Linux, etc).
The general rule of thumb is to 1) set your compiler's warning level to the maximum and 2) develop in parallel on all the platforms you're targetting.
Hope this helps.
This will not answer everything, but it might help.
By default, VC++ uses unicode while MinGW (on which DevCpp is based I believe) uses ansi.
This might explain your issues regarding strings: you're basically passing char* strings where most of the functions require something like wchar*.
I suggest that either you fix your code so it becomes unicode compliant, or that you undefine the UNICODE macro in your VC++ project, if unicode is not required.
As you stated, your old code was C++ and the code is C++ as well, so there shouldn't be that much work... as long as you don't rely on compiler specific behaviors.
Could you give us some samples of things that go terribly wrong ? We might be able to help more accurately.
Are the project settings the same? Perhaps you need to link in additional .libs or add similar preprocessor directives as you had in Dev-C++. If you just copy and paste the code to a project, you're effectively re-setting the project settings all to default, which for many projects, would break the build.
Apart from that - try adding one of the most common errors you receive to the question, with the line of code, and maybe we can comment.
Dev-cpp uses mingw as its compiler. Perhaps you will have more luck using an updated version of mingw, through another IDE. This will help with external dependencies (mingw uses gcc which uses *.a files to link to, VC++ uses *.lib files).
As you mentrion string and LPCWSTR, see ereOn's answer. Make sure you have UNICODE and _UNICODE properly defined (in build flags as -DUNICODE or in VC++ project options).
I'm trying to build a small code that works across multiple platforms and compilers. I use assertions, most of which can be turned off, but when compiling with PGI's pgicpp using -mp for OpenMP support, it automatically uses the --no_exceptions option: everywhere in my code with a "throw" statement generates a fatal compiler error. ("support for exception handling is disabled")
Is there a defined macro I can test to hide the throw statements on PGI? I usually work with gcc, which has GCC_VERSION and the like. I can't find any documentation describing these macros in PGI.
Take a look at the Pre-defined C/C++ Compiler Macros project on Sourceforge.
PGI's compiler has a __PGI macro.
Also, take a look at libnuwen's compiler.hh header for a decent way to 'normalize' compiler versioning macros.
You could try this to see what macros are predefined by the compiler:
pgcc -dM
Maybe that will reveal a suitable macro you can use.
Have you looked at the boost headers? Supposing they support PGI, they will have found a way to detect it. You could use that. I would start to search somewhere in boost/config.