I'm really baffled by this. Have I managed to do something to cause this, or is it an unclosed namespace block in boost, or some bug in VS c++ 2008? I'm definitely sure I've closed all my own namespaces properly, all includes are outside of and above them, and all my header files got include guards.
alt text http://lowtown.se/stuffs/superboost.png
The boost/function.hpp is only included in this header. Two other headers in my library includes the boost/cstdint.hpp but they don't have this problem.
Visual C++'s intellisense is a bit quirky. Sometimes it screws up. That doesn't mean there is a problem in your code. Always take C++ intellisense with a grain of salt.
Sometimes intellisense does that. If you use Visual Assist X it will fix that, but it is a very expensive program :(
Usually deleting ncb-file solves most of Intellisense problems. If it doesn't help — buy VA.
Related
Say I have the below (very simple) code.
#include <iostream>
int main() {
std::cout << std::stoi("12");
}
This compiles fine on both g++ and clang; however, it fails to compile on MSVC with the following error:
error C2039: 'stoi': is not a member of 'std'
error C3861: 'stoi': identifier not found
I know that std::stoi is part of the <string> header, which presumably the two former compilers include as part of <iostream> and the latter does not. According to the C++ standard [res.on.headers]
A C++ header may include other C++ headers.
Which, to me, basically says that all three compilers are correct.
This issue arose when one of my students submitted work, which the TA marked as not compiling; I of course went and fixed it. However, I would like to prevent future incidents like this. So, is there a way to determine which header files should be included, short of compiling on three different compilers to check every time?
The only way I can think of is to ensure that for every std function call, an appropriate include exists; but if you have existing code which is thousands of lines long, this may be tedious to search through. Is there an easier/better way to ensure cross-compiler compatibility?
Example with the three compilers: https://godbolt.org/z/kJhS6U
Is there an easier/better way to ensure cross-compiler compatibility?
This is always going to be a bit of a chore if you have a huge codebase and haven't been doing this so far, but once you've gone through fixing your includes, you can stick to a simple procedure:
When you write new code that uses a standard feature, like std::stoi, plug that name into Google, go to the cppreference.com article for it, then look at the top to see which header it's defined in.
Then include that, if it's not already included. Job done!
(You could use the standard for this, but that's not as accessible.)
Do not be tempted to sack it all off in favour of cheap, unportable hacks like <bits/stdc++.h>!
tl;dr: documentation
Besides reviewing documentation and doing that manually (painful and time consuming) you can use some tools which can do that for you.
You can use ReSharper in Visual Studio which is capable to organize imports (in fact VS without ReSharper is not very usable). If include is missing it recommends to add it and if it is obsolete line with include is shown in more pale colors.
Or you can use CLion (available for all platforms) which also has this capability (in fact this is the same manufacture JetBrains).
There is also tool called include what you used, but its aim is take advantages of forward declaration, I never used that (personally - my team mate did that for our project).
I started working on the GUI aspect of a C++ application in Visual Studio 2015, after including <windows.h> I got extremely cryptic errors with other files having syntax problems. I discovered that including that header file was the source of the issues.
I looked around online and found out about NOMINMAX but defining that didn't resolve the problem. I was using numeric_limits<int>::min()/max(), and one for ::infinity() with floats, so NOMINMAX will solve that minor issue, but didn't solve the major issue of these syntax errors occurring as the min/max problem compiler errors were pretty specific.
Moving the header to the very bottom seems to have solved it temporarily, however I am not happy with this at all because it means I have a potential timebomb in my code and I'm not sure where. Right now its 5k LOC but I'd rather deal with it know than get to 50k and run into this issue in a way that forces me to deal with it.
What techniques do I have of finding out where the error is occurring? Can I possibly dump the files after pre-processing? Going through and commenting everything out would be particularly painful... but I don't know if I have a choice. I have a general idea of the location but its occurring sadly on very prominent set of includes, so the amount of commenting needed to attempt to isolate this isn't too pleasant.
Is there a tool or some method to aid me in this problem? Or am I stuck having to do it the long and dirty way?
NOTE: I have also tried WIN32_LEAN_AND_MEAN, NOMINMAX, and VC_EXTRALEAN in attempts to solve this but that does not work.
EDIT: I have tried commenting/trying to find out what is causing it from the indicated lines but there are so many files/LOC that the resulting mess (due to this unfortunately occurring on frequently used files) means that the amount of work in tracking this down quickly became a nightmare, and thus I'm posting here looking for any heuristics on how I could identify this problem. It also compiles fine and uses all the functions where these syntax errors are occurring when I don't include the header file, so the code itself cannot be broken since the applications literally uses them and runs great.
My solution came from deciding to manually include the windows.h include files one at a time to see what was causing it. This eventually led me to discovering wingdi.h was causing the issues, and #define NOGDI solved the problem. Further googling around yielded that a chunk of the names in there can collide with class names, which I confirmed at least one of did.
I'm somewhat new to C/C++, and I find myself spending exorbitant amounts of time searching through header files (one innocent include might actually bring dozens more header files with it). Even helpful IDEs like Visual Studio aren't always helpful; sometimes when I try to go to the definition of a function, it prompts me to choose from several--the very thing I was trying to avoid.
So...in a very large project with thousands of header files and many occurrences of functions that share the same name and parameters, what's the best way to determine, without question, which specific function is being called?
Try adding /showIncludes to the compiler command line (In the project settings, Configuration Properties, C/C++, Command Line). This outputs all the headers used in a given .cpp file compilation. This is not a fast way, but it is a sure way.
When Intellisense isn't working, I recommend Find in Files. It is easier to track down the definition in the header this way. I find I can usually tell which is the relevant declaration.
Keep in mind that you cannot find the source in the header, unless you are dealing with templates or inlined functions. So there is generally no reason to attempt to discriminate which declaration(s) are being applied. If the definition exists in a SOURCE file (.c,.cpp), then there can only be one function of that name and signature for it to compile. It is generally better to google the function name if it is a published API from Microsoft or another source.
Tools such as Visual Assist for Visual Studio improve the ability to locate such definitions, as well.
Also, you can massage Intellisense into working better. Try deleting the Intellisense Database and having it be rebuilt. You can see where it has trouble by the "errors" it shows in the error view. Often you need to improve the includes directories, especially if this is a makefile project. If it grays out code that shouldn't be grayed out, some preprocessor symbol is wrong. Maintaining the Intellisense is often worth it because it's great when it works.
Tools such as Visual Assist for Visual Studio have their own, often improved intellisense-like method of finding definitions.
Admittedly, I'm still new to C++ (and programming in general) as well. But, I think that the Visual Studio feature you describe in your question is the most help you'll get. It will narrow things down a little for you, but you'll still have to do some good ole sleuthing.
Ask the compiler. No, really! It's the only way to be sure.
Try using Microsoft visual studio 2005. You can easily jump onto the function definition, Function declaration also you can see the Function call and callers graph as well.
this is probably a dumb question, but I couldnt find the answer I was looking for. Also, I was unsure if this was a C++ question or a VS2010 question, but the answer I'm looking for is that of a technical POV, so I ended up here.
When you start a new Console Application project in VS2010, it automatically includes stdafx.h, which in turn includes stdio.h.
The answers I found regarding stdio.h vs. iostream was more or less:
stdio.h was used in C and iostream is
used in C++
I dont know if this is right or wrong, but...
My question is: Why is stdio.h still automatically included in C++ projects? Wouldnt iostream be sufficient?
IO streams in older C++ implementations were pretty slow, leading programmers to keep using stdio.h. Apparently, that got included in stdafx.h in the past and cannot be removed from that header anymore as removing it would break existing code.
Usually projects are created using Create Empty Project, so that you can customize your includes and precompiled headers yourself.
I have no idea why does this "default" include happens, but it's a good thing to setup your project from scratch as I've described before.
Even if you're using stream output, being able to do some formatting is nice. So, if nothing else, sprintf will sometimes be used. sprintf lives in stdio.h
Possibly because visual studio targets Mort programmers, who wouldn't be able to get 'my first c++' program done without printf, and they would decide that the product didn't work right.
Before down voting plea google visual studio mort persona.
While working within C++ libraries, I've noticed that I am not granted any intellisense while inside directive blocks like "#ifndef CLIENT_DLL ... #endif". This is obviously due to the fact that "CLIENT_DLL" has been defined. I realize that I can work around this by simply commenting out the directives.
Are there any intellisense options that will enable intellisense regardless of directive evaluation?
By getting what you want, you would lose a lot.
Visual C++ IntelliSense is based on a couple major presumptions
1. that you want good/usable results.
2. that your current IntelliSense compiland will present information related to the "configuration" you are currently in.
Because your current configuration has that preprocessor directive, you will not be able to get results from the #ifndef region.
The reason makes sense if you think it through. What if the IntelliSense compiler just tried to compile the region you were in, regardless of #ifdef regions? You would get nonsense and non-compilable code. It would not be able to make heads or tails of your compiland.
I can imagine a very complex solution where it runs a smaller (new) parse on the region you are in, with only that region being assumed to be part of the compiland. However, there are so many holes in this approach (like nothing in that region being declared/defined) that this possible approach would immediately frustrate you, except in very very simple scenarios.
Generally it's best to avoid logic in #ifdef regions, and instead to delegate the usage of parameterized compilation to entire functions, so that the front-end of the compiler is always compiling those modules, but the linker/optimizer will select the correct OBJ later on.
Hope that helps,
Will
Visual Studio 6.0 has a little better support for C++ in some arena's such as this. If you need the intellisense then just comment it out temporarily, build and then you should have intellisense. Just remember to recomment it when you're through if that was your intent.
I just wish Intellisense would work when it SHOULD in VS2008. MS "workarounds" don't work (deleting .ncb files) most of the time. Oooh,
here's another SO discussion..., let's see what IT has to say (I just love SO)
I'm often annoyed by that too ... but I wonder whether intellisense would actually be able to provide any useful information, in general, within a conditioned-out block?
The problem I see is that if the use of a variable or function changes depending on the value of a preprocessor directive then so may it's definition. If code-browsing features like "go to definition" were active within a conditioned-out block would you want them to lead to the currently-enabled definition or to one that was disabled by the same preprocessor conditions as the disabled code you're looking at?
I think the "princple of least surprise" dictates that the current behaviour is the safest, annoying though it is.
Why you want to do explicitly in the code?
There is already cofiguration setting in VS and the way you can enable and disble the intellisense.
see the link.
http://msdn.microsoft.com/en-us/library/ms173379(VS.80).aspx
http://msdn.microsoft.com/en-us/library/ks1ka3t6(v=VS.80).aspx
This link may help you.