I am new to this platform, and I am trying to resolve an issue with existing code that was developed by a contractor many years ago.
In Resource.h, I have something that looks like this, where the last two items I have added.
#define IDC_HOSPITAL_NAME_LABEL 1069
#define IDC_REASON_LABEL 1070
#define IDC_HOSPITAL_NAME_EDIT 1071
#define IDC_COMMENTS_EDIT 1072
#define IDC_COMMENTS_LABEL 1073
I have compiled and deployed several times, I am using the constants in code and it doesn't complain on compile, however, while it might be unrelated to an issue I am trying to resolve, I do notice that in the IDE, if I right click and "Goto" definition of my new added items, it says "The symbol 'IDC_COMMENTS_LABEL' is undefined."
In fact, it will happen even if I do this at the definition, where as it works as expected with the other non-new definitons.
Sounds to me like its just "one of those things". You will notice plenty. Try not to get too wound up by them. In the end ... if it compiles ... don't worry about it :)
Do you have a newline on the last line? A missing one may confuse the IDE's symbol parser
Have you tried rebuilding? You might also try quitting VS, deleting the intellisense file (*.ncb), and rebuilding.
This is because, the symbol is probably not added to the Browse Information file of VC++.
In VC++, under Project->Settings->Browse Info ,enable the radio button "Build Browse Info file". Also clean (build->clean) the temporary files.
Now, exit visual studio IDE, delete the (*.ncb) file.
Relaunch VC6++ & rebuild all. That should do.
Related
TL;DR: Debuigging into MFC (CString) header code does not work on both my machines and as far as I can tell this is due to the peculiar way these headers are compiled.
Stepping through MFC header code when entered via disassembly works, but setting brealpoints does not work.
I'm looking for a workaround or at least acknowledgement of my analysis.
System:
Visual Studio 2019 Professional 16.9.6
Windows 10 / 1809 Enterprise LTSC
Setup: (I do apologize for this being rather long.)
Create a Visual Studio 2019 Example MFC Application Project (SDI App)
Make sure Enable Just My Codeis off under Options -> Debugging -> General.
Set the build configuration to Debug/x64 (does not make a difference, but let's all stay on the same page)
Navigate to MFCApplication1.cpp -> CMFCApplication1App::InitInstance()
Insert a CString init like this:
...
InitCommonControlsEx(&InitCtrls);
CWinAppEx::InitInstance(); // please put breakpoint 1 here
// Add this line and set breakpoints
CString this_is_text(L"Debugging into CString Header does not work!"); // breakpoint 2 here
Now, you can start the program under the debugger, and you should stop at the first breakpoint:
Now, make sure all symbols are loaded, easiest done via the Call Stack:
Just select all lines in the call stack window and hit Load Symbols in the context menu. Afterwards the call stack should look roughly like this:
> MFCApplication1.exe!CMFCApplication1App::InitInstance() Line 75 C++
mfc140ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 37 C++
MFCApplication1.exe!wWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 26 C++
MFCApplication1.exe!invoke_main() Line 123 C++
MFCApplication1.exe!__scrt_common_main_seh() Line 288 C++
MFCApplication1.exe!__scrt_common_main() Line 331 C++
MFCApplication1.exe!wWinMainCRTStartup(void * __formal=0x000000c2b7084000) Line 17 C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
Now, you can try stepping-into (possibly F11) the CWinAppEx::InitInstance() function, which should work without a problem, landing you in mfc140ud.dll!CWinApp::InitInstance() Line 394 - this is OK.
Step out again, and then then try to step-into the CString ctor:
This DOES NOT work on my machine(s)!
What I can do however, is (from the point above) switch to disassembly view, step into the calls there and get into the header code this way:
I can then successfully step through (but never into) the MFC header code. Trying to set a breakpoint will result in the error:
The breakpoint will not currently be hit. No executable code of the debugger's code type is associated with this line.
Possible causes include ...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
And this is where I'm at.
Analysis:
What we can see from the MFC code is that we can step into "regular" cpp code, but as soon as we try to step into (or set breakpoint) code that is inside this CStringt.h it breaks.
Peculiar here: This is template header code, and still the executed code (as shown by the disassembly) is not in the user module but in the mfc###.dll! I think they do some clever tricks with the preprocessor (see defined(_MFC_DLL_BLD) and somesuch) which enables this multi use of the header file, and maybe, possibly this is also what breaks the debugger.
Question:
Is this a known problem, does this happen with all VS2019 installs, is there something peculiar to my setup?
Maybe fixed in a newer VS version?
Iff this is actually broken, what would be a useable workaround, other than constantly switching to disassembly view when into the MFC headers.
The most interesting answer here would actually be as to WHY this breaks - where does the debugger get confused? Is this a general problem with re-define-ing code when debugging library code?
The source shipped with MSVC does not match.
I think this happen, as DLLs got updated with Windows Update or a new vcredist, but Visual Studio includes are not updated. If you build with /MT or /MTd and link MFC statically, the problem does not persist.
Probably this can be reported to http://developercommunity.visualstudio.com if you care.
Workaround 1
Do steps described by #selbie:
Set a breakpoint on the line of code I want to step into.
When
the breakpoint is reached, right click in the editor window and select
"Go To Disassemly".
In disassembly mode, step over until you get to
a call statement. [...] You
can flip out of disassembly mode by right-clicking again and selecting
"go to source code".
(skipped the part not relevant to this issue)
Then pick up the location of the header manually, the debugger will tell that it does not match. The difference seem to be insignificant though, so the header is usable.
Workaround 2
Link MFC statically, compile with /MT or /MTd
Workaround 3
ATL has a similar CString that does not suffer from the issue:
#include <atlbase.h>
#include <atlstr.h>
int main() {
ATL::CString this_is_text("Debugging into CString header works");
}
Analysis went sideways at some point, but we finally found one part of the problem here:
The Require source files to exactly match the original version option:
was the problem, but in a very peculiar way:
When you do NOT require source files to match (that is, disable this default option), then the erroneous behavior of the OP occurs: The debugger can no longer match the symbols to the cstringt.h file.
Unfortunately, I had this disabled on both machines. Pulling in a third machine showed that we could set breakpoints (though F11 still does not work) and by comparing the xml export of the VS settings we found that this was different.
So, long story short: For us, to be able to set breakpoints in the (unmodified!) MFC header, requires us to enable the Require source files to exactly match .. option.
If the option is disabled, which would imply a more lenient behavior by the debugger, it no longer works.
And, yes, we double checked it's always the same source file at C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
The mystery with step-into/F11 persists, but I guess this would better be taken to a separate question.
Uncheck the Enable Just My Code option in Tools->Options->Debugging
I know that works for c++ std:: library code debugging. The other technique I do, when I forget to uncheck this option, is similar to what you describe above.
Set a breakpoint on the line of code I want to step into.
When the breakpoint is reached, right click in the editor window and select "Go To Disassemly".
In disassembly mode, step over until you get to a call statement. That's typically the std library. Eventually, you'll navigate into a mix of assembly and system code sources. You can flip out of disassembly mode by right-clicking again and selecting "go to source code".
Please leave the window-installer tag in - this Q/A is not for
C++ experts, but for people like me, who use C++ when they have to.
They may face this potential time-waster, and need a quick fix to get
msi.h or other includes operational quickly. VS2017 templates must
have changed quite a bit - I didn't see this issue before.
Visual Studio 2017 Community Edition with all available C++ components installed (perhaps this problem does not exist in the professional edition?).
File => New => Project... => Visual C++\Windows Desktop\Windows Console Application => OK.
Do a quick test build to verify there are no errors. Right click solution => Build. As stated no errors should show up.
Now add this include for msi.h directly below #include stdafx.h right above the main() function in the console appliation's CPP file:
#include <msi.h>
// And just to make things link:
#pragma comment(lib, "msi.lib")
A red error chevron should show up in the top left corner at the start of the first line comment saying on hover: "There are too many errors for the IntelliSense engine to function correctly, some of which may not be visible in the editor. PCH warning: an unknown error occurred. An IntelliSense PCH file was not generated."
Doing a build now should reveal numerous errors. In my case from wincrypt.h - and it got me thinking about WIN32_LEAN_AND_MEAN - see answer below. I thought such basics would already be included.
I keep seeing this problem in all new C++ Windows Console Application projects, but when I try in an older project created with Visual Studio 2013 it compiles correctly with msi.h included along with the link pragma.
Judging from the error message there must be something wrong with the precompiled header (PCH). This is what threw me off.
UPDATE: Others have asked about the same error message for other include files (not MSI related). I guess this is a generic problem that strikes every now and then - probably with classes that are in little use (or include Windows.h - perhaps)?
As a general suggestion this might be a hidden dependency problem (an include that is missing), or an incorrect order of the include files (you need to change the order of your includes for some technical reason that is not immediately obvious) or a incorrect or missing define (like seen in the answer below the line underneath). My take on it: get on github.com and search for similar sample code.
These issues can be quite clunky to work out for those of us who need C++ occasionally, and otherwise be "well known" for the C++ pros (who fix it in seconds as second nature). C++ pros: please keep in mind that issues such as these can kill a whole day's worth of productivity for those of us forced to clunk around with C++ when we need to - and have no C++ pros around to ask - terrible situation that! :-) - I hereby declare a "be nice to your C++ guru - if you got them - day!").
In stdafx.h, try adding this after #pragma once and before other includes:
#define WIN32_LEAN_AND_MEAN
// Windows Header Files:
#include <windows.h>
Now try to rebuild your solution and see if the problem has disappeared.
Though simple, the strangeness of the error message (seen in the question above) can throw people off course trying to figure out what is wrong. Also, this behavior seems new in VS2017 - template change.
It looks like including <atlstr.h> will also work, so that probably makes my problem more obscure. Could have sworn I tried this though - maybe after I made project settings changes that made it fail still (exactly what I hope to help others avoid).
If only these basic includes could be present in the file but commented out so they could be enabled quickly in sequence for testing - without any fuss.
I just started programming, but I keep on getting problems with headers and stuff.
So, whenever I try and run the code
// ConsoleApplication4.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include "std_lib_facilities.h"
int main()
{
return 0;
}
I get this warning saying
Unable to start program 'C:\Users\Gebruiker\documents\visual studio 2015\Projects\ConsoleApplication4\Debug\ConsoleApplication4.exe'.
The system cannot find file specified.
Additionally, the Build outputs:
1>------ Build started: Project: ConsoleApplication4, Configuration: Debug Win32 ------
1>ConsoleApplication4.cpp
1>c:\program files (x86)\microsoft visual studio 14.0\vc\include\hash_map(17): error C2338: <hash_map> is deprecated and will be REMOVED. Please use <unordered_map>. You can define _SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS to acknowledge that you have received this warning.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========_
As you might've noticed, I'm following Bjarne Stroustrup's book on this, and he doesn't specify how to deal with this at all.
Anyways, the std_lib_facilities.h header is in the same folder as ConsoleApplication.cpp, just as he tells me to do.
I don't actually think this has anything to do with this program in particular, since I face this problem with all the projects I make.
Oh yes, I have to say that I've checked multiple related questions to this, but the questions didn't match mine.
I also tried to #include "../std_lib_facilities.h" and #include "../../std_lib_facilities.h", with no results.(Same with stdafx.h) I've tried "building" the program, but I don't actually know what that does, and if I should build the solution or the cpp, and when to debug....
The answer surely isn't in the book, since I've continued on to chapter 8, not doing the exercises because I cannot get the thing to work.
(Please also tell me if I messed something up in this question, i.e. that I need to talk less, give more details or something)
Here is how to remove a deprecation error:
How to fix "<hash_map> is deprecated and will be REMOVED. Please use <unordered_map>"?
If it still does not run, just go to the project directory and remove all Debug\Release folders Visual Studio creates after you run with Debug\Release configuration. Usually works for me.
Try creating "new project" / C++ console application; with your code and without any include statements. - Peter K
This fixed the problem for me, and I basically just copy-pasted the code and it worked.
I also had the hash_map error, because it is no longer supported in MSVS 2017.
This especially happens since one often still finds the old header off of Bjarne Stroustrup's website. Here is the link to the new header provided by Baum Mit Augen (Stroustrup's updated version)
If you're not using the header provided by Bjarne Stroustrup but one you made yourself, one you found on the internet or also one provided by a book, follow this tutorial from a previous answer by WindyFields. (Thanks a lot for that) (Be sure to check their answer out if this doesn't fix it)
If you encountered this problem, you probably messed with the settings when making a new project (like me).
This is a condensation of the comments provided by the community, none of these answers are mine.
My program compiles fine, but Netbeans tells me "Unable to resolve identifier to_string."
I tried everything in "Netbeans 7.2 shows "Unable to resolve identifier" , although build is successful" and I set the "C++ standard" to "C++11" in the code assistance options.
This is the only function giving this problem so far. It is however also the first C++11 feature I am using, which leads me to believe it has something to do with Netbeans not understanding that I am using C++11, although I specify it explicitly in the code assistance menu.
Minimal example:
#include <string>
int main() {
std::to_string(1);
}
EDIT: the same problem arises where using nullptr
EDIT2: I suddenly realized it might be important to mention that I do not use a generated Makefile, but SCons.
I know this question is seven months old but since it came up as the second result to a google search I'll tell the answer I came up with. For Netbeans at least. Go to your project properties and make sure you have you "C Compiler"->"C Standard" set to C11, and your "C++ compiler"->"C++ Standard" set to C++11. You have to set BOTH or it will still give false errors!
This will solve the problem:
Right click on "Project".
Select "Code Assistance".
Clean C/C++ cache.
Restart IDE.
Autocomplete and sometimes even syntax highlighting are always faulty with C++. The more you go in depth with C++ and C++11, the more Eclipse and Netbeans will start underlining everything with a red wavy line. Some of my (correct and perfectly compiling) programs are a huge red wavy line. I suggest you disable error markers altogether and you keep autocomplete, but in many cases it just won't work and you have to make the best of it.
I had the same situation. This was occurred because I used .c file instead of .cpp
for Netbeans 8.2 (on Linux) only the following worked for me: Tools -> Options -> Code Assistance -> Macro Definitions:
change:__cplusplus=199711L
to:__cplusplus=201402L
for C++14
or to __cplusplus=201103L
for C++11
I did all the above but what did the trick for me was recognizing that the Makefile had g++ rather than g++ -std=c++11.
To resolve c++17 related 'Unable to resolve identifier' in latest netbeans 8.2 or 9 version, one may need to set the macro definition __cplusplus=201703L as the default C++14 standard macro definition unable to resolve those unexpected error messages appeared in the editor.
I hope this is an interesting question. I'm trying to find the source of an unresolved external symbol. I have debug code that uses a global file pointer if debugging is turned on. All of this debugging code is supposed to be protected by #ifdef, like:
#ifdef DO_XLL_DEBUG
fprintf(debugPointer, "hello\n);
...
#endif
When I define DO_XLL_DEBUG, all is well. If I undef DO_XLL_DEBUG, everything compiles (I do a rebuild all just in case), but it fails at the link step, not finding debugPointer.
So, the question is, is there an easy way to find where I failed to #ifdef around the debug code? I can think of several not so easy ways.
I'm using Visual Studio 2005. This is a C++ project.
Thanks!
[EDIT]
Thanks for all the suggestions. Turns out the problem was in someone else's code that is not part the corresponding project I'm working on in Linux (where I do most of my work), so no wonder I didn't find it right away.
Just define some incompatible debugPointer and let the compiler point you at all the places where it's accidentially used or redefined. Maybe like this:
#ifndef DO_XLL_DEBUG
#define debugPointer static_assert(false,"damn it!");
#endif
(given that you don't have other variables, parameters, etc. which are called debugPointer)