I've read over tons of questions about the cdt indexer, and none of them get to the point. I've configured all of the preprocessor include paths and providers and all that and I have it all working.
But there are some modules that the compiler is okay with that the indexer is not, and I'd like to be able to see the compile output (if that's what's going on) that the indexer is getting that is causing it to fail. If I saw what it sees as the syntax or semantic or whatever kind of failure, I can change the code to make the indexer happy, but I haven't found a way to get the output other than the "problems" view, which only tells you what it found, not WHY it found it as a problem.
Does such a view exist? Is there really a g++ compile going on or is there really a c++ parser that is compiler-like but not a compiler that is trying to parse the source code and getting errors that there is no compiler output for?
The indexer is not invoking the compiler to produce diagnostics. It has its own C++ parser.
Cases where the indexer gives an error where the compiler does not can be do to incorrect project configuration, or a bug in CDT's C++ parser. Note that CDT's C++ parser does not yet support all C++14 and C++17 features, so code using such features is likely to run into such issues.
If you have a reduced testcase which compiles but triggers an indexer error, I would encourage you to file a CDT bug report.
Related
so i created a c++ linux console application on my x64 bit win 10 pro 10.0.17134 with wsl.
the project compiles no problem, without showing any errors. and debugging basic variable assignments works as expected;
then when i try to include any stl library e.g. #include <iostream> i get the following errors
128-bit floating-point types are not supported in this configuration
i am using Debug configuration with x64 bit mode.
i also tried googling the error, but i can't seem to find any related answer
i also tried using different c++ versions (c++17,c++11,etc...) but i still get the same error.
but even though i get these compilation errors, the program still runs correctly.
The compiler and the standard library are different things.
What you are seeing is a compiler that doesn't support 128 bit integers trying to use a std library that requires support for 128 bit integers.
The problem could be an Intelisense one, where Intelisense doesn't know that your compiler supports 128 bit integers or fails to properly exclude it or something. Your image shows you are seeing both Build and Intelisense errors; if the build succeeds that means those are Intelisense errors.
Intelisense is the MSVC tool that tries to parse and determine if you have errors in your C++ code. It doesn't use your compiler; rather, it uses a fast 3rd party compiler.
Turning Intelisense off may be the easiest way to get rid of those problems. Training Intelisense to get "proper" headers it understands is possible but quite difficult, and might be a many programmer-year project.
A quick hack would be to take your stdafx.h precompiled header, and do
#ifdef __INTELLISENSE__
using __float128 = long double; // or some fake 128 bit floating point type
#endif
but this can be an endless spiral.
There may also be ways to tell intellisense to ignore errors in certain files.
If it does not conflict with the rest of your code, you can set
__CUDACC__
in
Project Properties | Configuration Properties > C/C++ > IntelliSense | Preprocessor Definitions
This is if you are using GCC headers. The switch may be different for other sources.
As a tip, you can set the error output to Build Only. It defaults to Build + Intellisense, which as the answer above shows, is not necessarily what you want.
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)
I am working with c++ code base which emits many warnings due to which its hard to catch or notice new warnings being introduce by code I am adding or changing.
this is painful as I am not going to spend time resolving all the warning coming due to other modules, but I certainly do not want to add code which emits warning.
I wonder if there is some tool in gcc or external which can help here.
I can think of a painful way of taking a diff of compiler output with and without my code , but it will make my coffee taste much bitter.
Any suggestion on this?
If the problem stems from third-party source files, you can build some files with warning flags on, and other files with warning flags off. GCC has a whole range of well-documented warning control options.
If the problem stems from third-party headers that you include in your code, you can use -isystem to have headers under that path treated as "system headers", whose warnings are typically ignored.
If the code is more entwined, you are out of luck.
I need to use the C++ osmium library and I program using Eclipse cdt.
To be sure my system is well configured, I managed to compile and link few of the examples by hand using the installed gcc 4.8.2 that is enough according to osmium documentation.
Osmium uses C++11 and it seems my Eclipse has a problem understanding it.
I followed the instruction in the not-really-duplicate answer, but does not help.
I added -std=c++11 to the project properties under C++ Build -> Settings -> C++ compiler -> Miscellaneous and under C++ Build -> Discovery Options.
I also tried adding the macro __GXX_EXPERIMENTAL_CXX0X__.
Strangely in my main file it seems the C++11 features are working, for example I can write
for (auto a : {1,2,3,4,5}) {}
but the osmium directory I copied in the project instead results filled of errors. It is not a missing include directory since the lines #include <osmium/so/and/so> show no errors.
Similarly, std::move even after including utility, gives the cannot be resolved error.
However, I noticed that the code actually builds, even if Eclipse shows multiple errors around the code.
I stuck, what can I do to set up Eclipse?
I believe Eclipse is not recognizing my gcc compiler, as I'm getting errors for things that are definitely not errors, such as Symbol cout could not be resolved
http://img94.imageshack.us/img94/1264/gcc.png
Did I edit the PATH file incorrectly?
There are a few different issues here:
First, #include <iostream> is a preprocessor directive, not a C / C++ statement, so it doesn't need a trailing semicolon.
Second, unresolved symbol errors within Eclipse don't necessarily have anything to do with your compiler and don't necessarily stop compilation. Eclipse can automatically use your GCC compiler to find include paths, etc., which it then uses to resolve symbols. In my experience, this feature of Eclipse is extremely nice when it works, somewhat brittle and opaque when it doesn't work, and completely magical at all times.
I'd recommend taking this one step at a time:
Fix your #include.
Figure out why gcc doesn't work from the command line. Maybe you need to restart cmd.exe after editing the path. Maybe your PATH variable is too long. Maybe a nicer environment editor would help as you're investigating this.
Build your project from within Eclipse. This will test if your basic compiler + IDE toolchain is working and will help Eclipse do its automagical symbol and header resolution.
If you're still having problems with Eclipse's symbol and header resolution at this point, then you can work on that specifically. (For example, you may need to manually set #include paths within Eclipse's project settings, or you may find that cleaning your Eclipse index helps.)