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)
Related
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've recently started diving into the code of an open source project, which is largely written in C++. I'm using Eclipse 3.8 in Ubuntu 12.10.
THE PROBLEM:
Eclipses is incorrectly flagging fields as unresolved because of a particularly elaborate convention used to separate field declarations out of the header files.
someclass.h
class SomeClass
{
public:
#define MACRO_CLASS_PARAM(Name) SomeType m_##Name;
#include "fields.h"
#undef MACRO_CLASS_PARAM
};
fields.h
MACRO_CLASS_PARAM(Field1)
MACRO_CLASS_PARAM(Field2)
...
Now in the cpp file, if I want to do something like instanceOfSomeClass.Field1 Eclipse will flag it as an error with "Field 'Field1' could not be resolved".
THE QUESTION: Is there any way to get Eclipse to correctly handle this situation?
The inability to correctly process #include statements that are not at global scope is a long-standing deficiency in Eclipse's indexer.
Things you could do about it:
Revise your code to avoid this pattern. Once the textual header inclusion model is superseded by C++ Modules, it's going to be invalid anyways.
Contribute a fix for this deficiency to Eclipse CDT.
Use a different IDE that can parse this pattern. (I don't know of one off the top of my head, but I also haven't spent a lot of time looking.)
I'm using C++, and compiling & linking to OpenCV2 using "g++". One thing that bothers me is that all of the old cv-prefixed functions are still available and "pollute" my application.
Is it possible to make the OpenCV1 C cv-prefixed functions unavailable in the scope of my application and just keep the OpenCV2 cv:: namespaced ones?
Note: I haven't written C in a while, so please let me know if this is a silly question.
It depends on what do you really need. If you just want to make this code:
CvArr *arr;
cvAvg(arr);
cvAcc(arr, arr);
"not working" - you can just add this:
#define cvAvg nothing_interesting_cvAvg
#define cvAcc nothing_interesting_cvAcc
//you can change nothing_interesting_... to anything, but you can't use the same text more than once
//you include files
//...
//after your include files
#undef cvAvg
#undef cvAcc
before including any OpenCV file. If you now try to compile code you will see:
error C3861: 'cvAvg': identifier not found
If you change you code to use nothing_interesting_cvAvg(arr); instead of cvAvg(arr);, it will compile fine, but linker will fail, because:
: error LNK2019: unresolved external symbol _nothing_interesting_cvAvg referenced in function _main
Note that this will work only for this 2 functions, so you will have to find all functions which you want to "disable" and write similar code manually.
Functions which use "deactivated" functions will work fine, because they are already compiled, linked, etc - you will just call them from some files without changing anything in this files.
eMbedded Visual C++ 3 project, that is building for PocketPC 2000. On the ARM build, the linker throws the following error:
fatal error LNK1223: invalid or corrupt file: file contains invalid pdata contributions
On SH3, the project compiles, links, and works. The project also works when built for ARM on Visual C++ 2005, but I need to test builds specifically from eVC3.
Any ideas, please? What's a pdata contribution and how do I affect (or disable) those? It's something to do with exception handling; I've tried disabling SEH by specifying /EHsc, to no effect.
Very weird. I tried commenting out everything in the file. The error went away when I commented out a function that was extern "C" void __declspec(naked) with no body (body #ifdef'fed away). I have similar functions in the project, but they did not throw any errors like this. Maybe a compiler bug...
No idea from me, but the Google-mind dredged up this thread which might give you a clue how to fix/workaround the problem... maybe:
http://www.pocketpcjunkies.com/Uwe/Forum.aspx/wince-pb/7477/Link-error-during-DEBUG-build
After looking at the error more closely, I finally figured out that this is
a side-effect of my hijacking of SC_SetDaylightTime() in the kernel with my
own version. Apparently, something that I'm doing in my code there is
causing the compiler to generate pdata entries that are wrong in some way.
A strategically-placed #ifndef worked around it.
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.