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.
Related
I am very new to coding C++ and to using the Netbeans IDE. Worse yet, I'm on a Mac (but I can't imagine that's the source of the issue this time).
The IDE is giving me countless nonsense "hints" as in red exclamation mark symbols, most of which say "Unexpected token" for things like ';' at the end of a statement or '=' in a statement. These are of course ridiculous because, as I understand c++ so far, they are necessary for even the most basic statements!
screenshot here
What could possibly be causing this and how do I get rid of the hints or, preferably, fix something if there is an error somewhere?
Delete your Netbeans cache. In my case the problem when away when I did this. I think I initially ended up in this state because my C++ project was under a Java project. After separating the two the error was still present even with a clean/build. Deleting the Netbeans cache got rid of the problem. Even if your situation is different you should try this. Clearing the Netbeans cache once in a while fixes a lot of issues.
Tyler,
I'm going to go out on a limb and guess that you've got your Net beans ide setup to use another language other than C++. Remake the project and make sure your using c++
I had the same issue.
The issue was, I wrote C++14 code, in the C++ project.
To resolve this:
- Create a C++14 project (Select from the drop down, while creating the project)
- Add existing C++ files to it
Hope that helps.
I'm trying to learn how to use Eclipse for C++ development (using MinGW) and have run into an interesting problem.
While writing a simple test program I get the following error:
However simply saving the file resolves the error... Why does this happen?
After saving:
I would really like simple bugs like this to be caught without having to go and manually save the file...
I know it's really simple to just click "Save" but I know myself and I will forget and I will spend hours trying to track down a bug that isn't actually a bug. (I'm sure this will probably also happen with things other than using namespace std;.)
Eclipse's CODAN tool runs as you type, unfortunately it only parses dependencies on demand, usually with a save.
Why? Eclipse's CODAN tool isn't exactly a gazelle, so having to track through all of the file's dependencies while the user is typing is probably a system killer. This may improve with time. In the meantime, save regularly.
And, to be honest, this is probably a dodge. It should only have to search dependencies when a dependency is added. But there are a lot of buts. What about when a dependency is added to a dependency? Or a new dependency is hidden in a macro (don't do this) and hard to parse without digging through the dependencies? Or exposed by adding a define that triggers conditional compilation (I prefer different implementation files and letting the linker sort it out to conditional compilation)? What about...?
Blah. If people want to write garbage code, that's their problem. A static analyzer should focus on the needs of people who aren't trying to trick it and circumvent good style. That said, I don't know the CODAN code, and I don't know how deep one would have to go to change it to catch and handle the easy cases at a tolerable real-time rate.
But at the end of the day, the only analyzer you should pay attention to is the compiler--with the warning levels turned up to 11, of course. CODAN is not perfect. It misses and misinterprets stuff, and you may find yourself hunting a bug that's not a bug in your code. If the compiler has a bug, that's a different case, but a lot less likely. Definitely take CODAN's help, but before you spend time on an odd error, make sure it really is an error by saving and building the program.
CODAN configuring stuff:
Most of CODAN's options can be found by visiting Project->Properties on the menu and navigate the Properties dialogue to C/C++ General->Code Analysis
To turn configure CODAN's run options, to turn off updating as you type for example, go one step further to C/C++ General->Code Analysis->Launching
You will also find that if you are editing included headers in another project, you will have to force an index rebuild to to catch the modifications. Select Project->C/C++ Index->Rebuild from the menu for the project doing the including.
Unfortunately I am not working with open code right now, so please consider this a question of pure theoretical nature.
The C++ project I am working with seems to be definitely crippled by the following options and at least GCC 4.3 - 4.8 are causing the same problems, didn't notice any trouble with 3.x series (these options might have not been existed or worked differently there), affected are the platforms Linux x86 and Linux ARM. The options itself are automatically set with O1 or O2 level, so I had to find out first what options are causing it:
tree-dominator-opts
tree-dse
tree-fre
tree-pre
gcse
cse-follow-jumps
Its not my own code, but I have to maintain it, so how could I possibly find the sources of the trouble these options are making. Once I disabled the optimizations above with "-fno" the code works.
On a side note, the project does work flawlessly with Visual Studio 2008,2010 and 2013 without any noticeable problems or specific compiler options. Granted, the code is not 100% cross platform, so some parts are Windows/Linux specific but even then I'd like to know what's happening here.
It's no vital question, since I can make the code run flawlessly, but I am still interested how to track down such problems.
So to make it short: How to identify and find the affected code?
I doubt it's a giant GCC bug and maybe there is not even a real fix for the code I am working with, but it's of real interest for me.
I take it that most of these options are eliminations of some kind and I also read the explanations for these, still I have no idea how I would start here.
First of all: try using debugger. If the program crashes, check the backtrace for places to look for the faulty function. If the program misbehaves (wrong outputs), you should be able to tell where it occurs by carefully placing breakpoints.
If it didn't help and the project is small, you could try compiling a subset of your project with the "-fno" options that stop your program from misbehaving. You could brute-force your way to finding the smallest subset of faulty .cpp files and work your way from there. Note: finding a search algorithm with good complexity could save you a lot of time.
If, by any chance, there is a single faulty .cpp file, then you could further factor its contents into several .cpp files to see which functions are the cause of misbehavior.
I have a gigantic C++ Builder 6 solution, when I try to compile it I get the following error when the linker starts its work:
It translates to:
---------------------------
Fehler
---------------------------
Access violation at address 0660EE22 in module 'ilink32.dll'. Reading from address 00000000.
---------------------------
OK
---------------------------
Does anyone have an idea how this comes and how I can fix it?
EDIT 1
Important note, the code sometimes compiles, mostly then, when I reset the working copy and then just modify the stuff in sublime text and use C++ Builder only for compiling. Including, I don't open a single file.
EDIT 2
Some more details, the project has about 80.000.000 lines of code (according to C++ Builder). The largest file is about 70.000 lines, but you cannot say clearly, because there are a lot of
#ifdef XY
#endif
Things.
The code itself is copy-paste from an existing part and got reviewed by some coworkers. So I think it is a bug in C++ Builder, because it actually works if I just use Sublime Text or Notepad++ to edit the stuff and then use C++ Builder to build it, it works (at least sometimes).
To be honest, I myself don't think there is a real solution. But I hope someone knows this bug. According to Google, the ilink32.dll is a C++ Builder library that is linked automatically.
Maybe someone has a solution.
The ilink32 has always had a lot of bugs. There's no chance of getting anything fixed in non-current versions , so your options are:
Look for workarounds on QC
Find your own workaround
Here are some QC searches that may or may not be useful to you.
AFAIK it is not possible to use a different linker. However you can turn on (or turn off) Incremental Linking via the project options and see if that makes a difference. Incremental linking is a speed optimization, it makes no difference to the semantics of linking.
the project has about 80.000.000 lines of code (according to C++ Builder).
Well, that number counts all lines in precompiled headers for each source file so maybe it doesn't mean much.
70K LOC is large for one source file; perhaps you could try refactoring code to have smaller object files, especially if it does seem that adding to a big file does trigger the problem.
It might be possible to identify which change you are making that is triggering the bug. For example it might be increasing a particular thing past some limit (e.g. size of one object file , number of object files, size of static data, etc.)
You could delete the precompiled header files (that is vclNN.csm, vclNN.#00, vclNN.#01, etc.) that are built and saved by default in the BCB6 lib directory. Perhaps they got corrupted or could be rebuilt better. PCH management is difficult in BCB6 anyway. (I ended up defining my own "all.h" and having every source file do #include "all.h" #pragma hdrstop). Later versions of CBB XE allow PCH injection making this process a lot tidier.
Have a look at the actual link command being passed to ilink32 and see if there are any unnecessary object files or libraries in it. You could delete and re-create the project files as they can build up crud over time as a project is developed. Actually that is probably a good idea anyway.
Another possibility might be to group some of the code into static libraries .
In all cases make sure you are using good source control so you can reverse out any failed options that might make things worse
I have been stumbling through some different steps to do this. I ran the qt3to4.exe on the files with compile errors and got though a lot of conversion steps, however now I am getting this error:
1>c:\qt\4.7.0\src\qt3support\widgets\q3toolbar.h(64) : error C2039: 'ToolBarDock' : is not a
member of 'Qt'
and 55 other similar errors. This confuses me since it is in qt's own q3support library. I also saw on a QT help page (http://doc.trolltech.com/4.2/qt-qt3.html) that ToolBarDock is deprecated and Qt::Dock should be used instead.
I haven't found much help on this out there. I'm using the library inside Visual Studio 2008. Any QT/visual studio experts out there?
If this helps, here is the code it is failing on in q3toolbar.h:
Q3ToolBar(const QString &label,
Q3MainWindow *, Qt::ToolBarDock = Qt::DockTop,
bool newLine = false, const char* name=0);
Actually qt34qt4 doesn't do all things right. There are many methods, enums etc, which are not converted. It is more or less simple find-replace tool which replace following instructions from qt\tools\porting\q3porting.xml
In many cases there is a replacement definition for a class, but not for a method of this class. In some cases qt3to4 replaces enums and methods in code which doesn't belong to Qt-classes at all. So be carefull. In any case, I would suggest getting a list of all Qt classes in you code, read carefully porting notes (http://doc.qt.nokia.com/4.5/porting4.html) for each class you use.
Another issue are return types, qt3to4 doesn't check how the returned value is used. Fortunate qt3to4 makes a good job, so fixing the rest is often a trivial, repetitive task.
If you have to port UIs, take a look at undocumented argument -wrap of uic3.
P.S.: Some figures for your effort estimation, may be usefull: I've ported (got compiled) once 600TLOCs + 150 UIs in 2,5 Months, currently I am porting about 150 TLOCs project and got pretty far in 2 weeks.
I had these errors as well after importing a project into VC++. Adding QT3_SUPPORT to the preprocessor definitions fixed it.
I ended up going a different route on this problem. I found the implementations I needed from the "qt3 library" somewhere else. Just before I found that out, I got some advice from some coworkers here. The consensus was that I'd need to rebuild Qt specifying to include qt3 support. Although I didn't follow through with this, here are some helpful links.
http://www.qtcentre.org/wiki/index.php?title=Qt4_with_Visual_Studio
http://lists.trolltech.com/qt-interest/2006-11/thread00177-0.html
If anyone comes across this and gets through this problem, please post your solution! Thanks.