| Author |
 Topic  |
|
Nox Metus
Senior Member
43 Posts |
 Posted - Nov 26 2014 : 2:03:17 PM
|
I have a C++ project where Visual Assist consistently not working properly: all refactoring items except �Find References� are grayed out, �Find References� issues errors that symbol is not recognized, Alt+G doesn't open files from include directives, when I press Alt+G on a method definition, it doesn't go to the declaration, syntax highlight doesn't highlight all methods in �VA Outline� view.
Is there a way to tell what goes wrong with VA? Some log, error messages, some diagnostic output? Or I have to guess blind?
Btw, all built-in VisualStudio means of code navigation work properly: it opens declarations, definitions, searches references, opens include files from include directives, highlights methods properly in the object browser, etc. |
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Nov 26 2014 : 4:03:56 PM
|
VA can produce logs, but that's not always the best place to start. Can you use Find References on a local variable in one of your functions? I am trying to put a scale on this, if it is all symbols, just functions, etc.
Does the Alt-M list work reliably?
Part of this sounds like a problem with the solution directory settings, so that VA does not know where to find all of the header files it needs to parse, but some refactoring commands should still work some of the time. So if this does not even work on local variables this suggests something more fundamental is confusing our parser, perhaps something in a common include file. |
zen is the art of being at one with the two'ness |
 |
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Nov 26 2014 : 4:24:31 PM
|
Doesn't work even for local variables. I cannot asses how Alt-M is reliable, but it shows the methods, though some of them are not colored.
How to find out what confuses the parser? Whatever it is, it doesn't confuse Visual Studio IntelliSense. |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Nov 26 2014 : 4:29:08 PM
|
| For what it's worth, I tried to remove Visual Studio IntelliSense DB and VA DB in order to let them being regenerated from scratch. Same story. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Nov 26 2014 : 5:10:11 PM
|
Well that's clear, if unexpected.
Can you please turn on:
VA Options -> Fonts and Colors -> Local symbols in Bold
and copy and paste the following simple test function into one of your cpp files, at the very top, before any #include or #define lines:
static void testFelineTopic12121LocalVar()
{
int nFelineLocal12121a, nFelineLocal12121b;
nFelineLocal12121a = 4;
nFelineLocal12121b = nFelineLocal12121a + 3;
}
nothing clever, but simply something that should not produce any duplicate symbols with anything in your current solution. Are the local variables shown in bold? What is shown in the VA context and definition fields when you place the caret into one of these local variables?
Does Alt-g or Find References work on the local variables?
What file extensions are you working in?
Can you please go to:
VA Options -> System Info -> Copy Info
and paste the details (from the clipboard) into your reply. This will give us the basic information about your setup. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Nov 26 2014 : 5:30:11 PM
|
Thank you for finding time to help me.
1. They are in bold.
2. Context and definition are either empty or show "the name of the source file"|"full path to the source file".
3. Alt+G works, i.e. it properly jumps to "int nFelineLocal12121a, nFelineLocal12121b" if I press Alt+G in the fourth or the fifth line.
4. Find References still shows a dialog �symbol is unrecognized�.
5. The extensions are .h and .cpp.
License: ************ (1-user license) Support ends 2015.11.19
VA_X.dll file version 10.9.2052.0 built 2014.11.05
DevEnv.exe version 12.0.31101.0 Ultimate
msenv.dll version 12.0.31101.0
Comctl32.dll version 6.10.7601.17514
Windows 7 6.1 Build 7601 Service Pack 1
8 processors (x86-64, WOW64)
Language info: 1251, 0x419
Platform: Project defined
Stable Includes:
C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\winrt;
C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\shared;
C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\um;
C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\atlmfc\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\include;
Other Includes:
Stable Source Directories:
C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\crt\\src;
C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\atlmfc\\src\\atl;
C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\atlmfc\\src\\mfc;
Though it was the same with a previous build of VA. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Nov 26 2014 : 11:07:27 PM
|
That is strange... very strange. I am not seeing anything odd in your about info, which is something.
First a, hopefully, quick and simple test. Can you please go into:
IDE Tools menu -> Extensions and Updates...
Disable Visual Assist, which will require an IDE restart. Then after the restart Enable VA, again another IDE restart, reload your solution, and see if this makes any difference? If the problems are because VA is somehow not correctly connected with the IDE this may well help.
If this makes no difference, what does your list of extensions look like? For VS2013 Update 4 with VA I have the following extensions listed:
Application Insights Tools for Visual Studio
Behaviors SDK (XAML)
Microsoft Advertising pubCenter Service for Visual Studio
Microsoft Advertising SDK for WIndows 8.1
Microsoft ASP.NET and Web Tools
Microsoft Visual Studio ASP.NET MVC 5 Scaffolding
NuGet Package Manager for Visual Studio 2013
Visual Assist
Visual F# 3.1
Visual Studio Extensions for Windows Library for JavaScript
Windows Phone 8.1 SDK Integration
Any obvious differences with your list?
If you have the time, can you please create a new, default C++ solution, copy and paste in the sample function and see if you still see the problem? Its possible this is somehow a solution specific problem, what ever it is. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Nov 27 2014 : 02:31:42 AM
|
Oh yes, it is a solution problem. I don't have this behavior in other projects. This why I asked about diagnostic means.
After disable/enable VA your sample function looks different. Now the local variables are not colored at all, Alt+G doesn't work in this function anymore.
In my list of extensions I have these extras compared to yours:
DPack
Microsoft Advertising SDK for WIndows 8.1 XAML
Microsoft Office 365 API Tools
Release Management for Visual Studio 2013
Workflow Manager Activities.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Nov 27 2014 : 3:48:42 PM
|
Are you seeing these problems in the test solution as well as your main solution, or just in your main solution?
In your main solution, can you please make a new, empty cpp file and the copy and paste the test code into it. Do you still see the problems even in this file, with just this code?
Is your main solution being opened from a local drive, a mapped drive, some form of network drive? I am looking for any clues as to what is different and confusing about your main solution. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Nov 28 2014 : 02:12:20 AM
|
I see these problems only in my main solution.
I made an empty file and copied there your test function testFelineTopic12121LocalVar. No changes.
It is a network drive. However I just tried to copy everything to a local drive. Same thing.
What is different about my solution is it is rather big: circa 900 .cpp files and roughly the same amount of .h files, not counting external includes. Also it is a makefile solution. But it worked before. Something changed and I don't know what. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Nov 28 2014 : 1:41:28 PM
|
Normally solution size should not matter, but just in case how many files do you have in your solution?
If you open VA's Open File in Solution dialog (Alt-Shift-O) the title bar contains two numbers. The first number is the number of files currently listed, which changes as you filter the list. The second number is the total number of files in the list, which is normally the number of files in your solution. What is this second number?
Ah, a makefile solution, what do you have:
Upon opening a file, parse all other unparsed files in the same directory:
VA Options -> Projects and Files -> if Solution is empty
VA Options -> Projects and Files -> if Solution is not empty
set to? Does turning these settings on make any difference? I am wondering if VA is having problems locating all of the files for your solution. Another possibility is that we are having problems understanding the include directory settings, so are missing key header files. I am not quite sure how this would produce all of these problems, but at least it is something we can look into. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Nov 28 2014 : 4:07:45 PM
|
quote:
Originally posted by feline
Normally solution size should not matter, but just in case how many files do you have in your solution?
It is in my previous message: around 900 of .cpp and around the same amount of .h.
quote:
Originally posted by feline
If you open VA's Open File in Solution dialog (Alt-Shift-O) the title bar contains two numbers. The first number is the number of files currently listed, which changes as you filter the list. The second number is the total number of files in the list, which is normally the number of files in your solution. What is this second number?
1778.
quote:
Originally posted by feline
Ah, a makefile solution, what do you have:
Upon opening a file, parse all other unparsed files in the same directory:
VA Options -> Projects and Files -> if Solution is empty
VA Options -> Projects and Files -> if Solution is not empty
set to?
�if Solution is empty� is checked, �if Solution is not empty� unchecked. I wouldn't like to check the second option. The amount of files will be really overwhelming.
quote:
Originally posted by feline
Does turning these settings on make any difference?
No.
quote:
Originally posted by feline
Another possibility is that we are having problems understanding the include directory settings, so are missing key header files.
That would be my assumption as well. Though it worked before. This is why I asked about log files or something. VS IntelliSense obviously finds everything alright, so I assume the project settings are correct. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Nov 29 2014 : 3:14:40 PM
|
I was just double checking the full solution size, trying to get a handle on what is happening here. This size should not normally be a problem, the only way it might be is if your code is very heavy on templates or macros, both of which have been known to cause problems occasionally.
Even with VA not finding some header files, a local variable in a simple function in an otherwise empty file should work correctly... Log files are starting to sound the way forward, but I like to have some idea of what to look for first.
You said that in the Alt-M list some functions are not coloured. Are these functions coloured in the cpp file its self, in the editor window?
Is Alt-g working anywhere, on anything? Or does this seem to have completely stopped working since you disabled and enabled VA? If you are seeing problems with alt-g, does rebuilding VA's symbol database:
VA Options -> Performance -> Rebuild symbol databases
make any difference? |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 01 2014 : 1:12:01 PM
|
Thank you for really analyzing the case.
quote:
Originally posted by feline
You said that in the Alt-M list some functions are not coloured. Are these functions coloured in the cpp file its self, in the editor window?
They are.
quote:
Originally posted by feline
Is Alt-g working anywhere, on anything?
It is not. It works correctly in that simple case of a local variable in a single simple function inside the otherwise empty file. Inside other files of the project sometimes it jumps correctly, sometimes it jumps to a wrong context, sometimes it suggests several locations to jump to with several absolutely wrong. Also Alg+G doesn't open header files from #include directives.
quote:
Originally posted by feline
If you are seeing problems with alt-g, does rebuilding VA's symbol database make any difference?
I have a subjective feeling that it started jumping more frequently to the right locations. All other problems remain unchanged.
Rebuilding symbol databases doesn't help. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Dec 01 2014 : 11:02:36 PM
|
I am not giving up easily on you, on this, I plan to get to the bottom of this and see if we can fix this!
OK, there is some "good" news here, just not much. The fact that alt-g is working correctly in the simple function in an otherwise empty file tells us that VA is actually attached to your IDE, and not totally disabled and broken by your main solution. I cannot imagine how a specific solution would "disable" VA, but something very strange is going on here.
Let's study the alt-g on #include lines part, this should be relatively easy to study, and try to understand.
Firstly, the problem #include lines, if you copy a couple of these lines into the nearly empty test file, do you still see the alt-g problem? Or does copying the problem line to a new file fix the problem?
I suspect you still see the problem, but if not, if the problem is file specific, then we could be looking at macros above the #include lines, invisible control characters in the file, mixed line endings in the file, or some confusing Unicode characters in the file. All long shots, but possible.
As a sanity check for this, can you make sure you have:
IDE tools menu -> Options -> Environment -> Documents -> Check for consistent line endings on load
turned On and keep an eye out for any warnings about mixed line endings in your files.
Assuming the problem is not file specific, does VA show anything helpful in its context and definition fields, normally at the top of the editor window, when you place the caret into the file name?
Making sure the header file in question is not currently open in the editor, is this file listed in VA's Open File dialog? I am just checking if it is part of the solution or not. I am assuming it is not, but lets double check.
If you right click the file name, does the IDE offer you "Open Document "file_name.h"" near the top of the context menu? If so, and you go to the file, is VA active in the file, and is the full path to the header file shown in the definition field?
Are you able to post the full path of the header file, and also the full path of the cpp file you started in? We can then compare these directories with your solution settings, to try and work out why VA does not know about this file. Probably a missing include directory setting, or possibly a setting that VA is unable to find and understand. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 02 2014 : 01:23:58 AM
|
- Alt-G doesn't work with include directives even in the test file.
- I have the line ending check always on.
- Context and definition don't work, even in the test file.
- VA's open file dialog lists all 1778 .cpp and .h files explicitly specified in the project file.
- Yes, as I said before, the IDE has no problem opening any files, finding symbols, references, everything. So, yes, it does show the correspondent open file item in the context menu, it can open any file in any include directive either from the context menu or from the keyboard shortcut.
quote:
Originally posted by feline
Are you able to post the full path of the header file, and also the full path of the cpp file you started in?
Sorry my English, I don't understand. What do you mean by �started in�? Anyway, I cannot publish anything without compromising my NDA.
quote:
Originally posted by feline
Probably a missing include directory setting, or possibly a setting that VA is unable to find and understand.
If I had missed an include directory setting, the IDE would have had problems as well, right? |
Edited by - Nox Metus on Dec 02 2014 01:29:29 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Dec 02 2014 : 1:24:05 PM
|
Sorry for not being more clear.
Can you look at the full path of the header file, the one that alt-g fails to open, and then look at your solution settings, and try to find the setting that lets the IDE work out where this file is?
Since the IDE can find the file, but VA cannot, there must be a setting somewhere VA is not finding. If you can tell me which settings VA might be having problems with, I can test them here, and we can try telling VA about the directories it does not know about, which should help. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 02 2014 : 1:58:46 PM
|
IDE takes its include directory settings from here:
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<ClCompile>
...
<AdditionalIncludeDirectories>...</AdditionalIncludeDirectories>
...
</ClCompile>
...
Or in GUI it is Project Property pages->Configuration Properties->NMake->Include Search Path
Though I doubt it is the right direction. VA fails to open any header file on Alt-G from any #include directive. Even those header files that don't require any include directory settings.
Consider for example a file aaa.cpp that has#include "aaa.h" aaa.h is located in the same directory. Alt-G doesn't work on this #include. For some reason Alt-O works though. |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 02 2014 : 2:11:06 PM
|
I checked file system activity on pressing Alt-G in an #include directive with procmon.
It doesn't even try at all to search any directories. So the assumption that something wrong with include directory settings is wrong.
It's you parser. I bet Alt-G simply doesn't recognize this is an #include directive. |
Edited by - Nox Metus on Dec 02 2014 2:12:09 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Dec 03 2014 : 12:58:21 AM
|
Thank you for the details. The NMake include path is working for me, and being picked up correctly by VA in a simple test here. Are you using an absolute path, a relative path, or a path using environment variables of some form?
For the problem with the line:
#include "aaa.h"
is the file "aaa.h" actually part of your solution? If you make sure this file is not open in any of the tabs, is it listed in VA's Open File dialog, or in the IDE solution explorer pane?
You have not told VA to parse all of the other files in the current directory, so this could be a factor, since we cannot assume VA knows about this file if it is not part of the solution.
Can you please add the line:
#include <stdio.h>
to both the nearly empty test file, and one of your normal files. Given your VA about information VA should know where this file is. Does alt-g on this file name work in either file? I am assuming you don't have a file called "stdio.h" in your solution, so VA will know which file this is.
Would you be able to share file paths, and other simple details privately, via email? Log files make sense, but will contain some solution details, so if you cannot share any details then they are not a good idea. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 03 2014 : 1:42:26 PM
|
We are moving in circles.
It doesn't matter whether aaa.h is a part of my project, it works the same. Besides, Alg-G is supposed to open any header file in #include directive, not only those that you explicitly added to the project.
The fact that I told VA not to parse other files in NO WAY can be a factor. There is a file aaa.cpp, IT IS a part of the project. It HAD TO be parsed properly, but it WASN'T.
quote:
Originally posted by feline
Can you please add the line:
#include <stdio.h>
Is it so difficult to believe what I said TWO TIMES already: VA FAILS TO OPEN ANY FILES FROM ANY #include DIRECTIVES?
IT'S NOT ABOUT VA KNOWS OR DOESN'T KNOW WHERE THE FILES ARE. IT DOESN'T EVEN TRY TO LOOK AT ANY DIRECTORIES AT ALL AND CHECK FOR INCLUDE FILES. CHECK MY PROCMON LOG.
Circles, circles, circles.
I'll consult with the legal department regarding what I can share privatively.
I'll try to analyze log files myself. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Dec 03 2014 : 5:15:06 PM
|
I realise we are going in circles, but this is a very strange situation, and I am trying to make some sense of it. I have never come across a problem before where VA does not understand that a #include line is a #include line. This either suggests something before the very first #include line is breaking our parser, or VA cannot find any files, anywhere.
Alt-g is supposed to open any file VA knows how to find. It will never open a file that is not in your solution, and not in any directory that VA has been told to search. Which is why I asked the questions I asked.
To try and check for something above the very first #include line I asked about the #include line in the nearly empty file, since things do seem to work in that file. Since things work in that file, VA is capable of parsing this single file, so something must make this file different to every other file in your solution.
Alt-g is going to be relying on VA's symbol database, but since other solutions work, and the nearly empty file works, it looks unlikely that your VA symbol database is always corrupt. The procmon trace was when Alt-g was looking things up in VA's symbol database, not when VA was building the symbol database.
Please see this FAQ for details of turning on VA's logging, and locating the log files, perhaps they will offer you some useful clues:
http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=5489
I am trying to help, but this is a difficult problem. Hopefully you can see why I am asking the questions I am asking now. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 04 2014 : 1:00:50 PM
|
quote:
Originally posted by feline
The procmon trace was when Alt-g was looking things up in VA's symbol database
I don't see any searches in the symbol database in the procmon trace. I see only checks (not even reads) on whether cpp.tpl exists, which is not a symbol database, but just autotext templates.
I am going to try to analyze the log files. |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 04 2014 : 3:13:45 PM
|
Another demonstration that Alt+G simply doesn't realize it's an include directive. Instead of trying to search the file under the cursor among known files or known directories, it suggests to find the symbol under the cursor.
|
Edited by - Nox Metus on Dec 04 2014 3:26:31 PM |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 04 2014 : 4:57:58 PM
|
| It seems like it is the amount of files that drives VA parser nuts. I removed almost all files from the project, the remaining files behave correctly. Refactoring options, find references, opening of files in include directives, etc everything works. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Dec 04 2014 : 4:58:01 PM
|
There is no need to re-read the cpp.tpl file if it has not changed. Re-reading a file that has not changed is not very efficient. The cpp.tpl file stores C++ VA Snippets, and is used for listboxes that appear as you type, you want that information in memory if possible. Similarly, a certain amount of the VA symbol database will live in memory, possibly all of it, since your project is not that large by some standards.
So you won't get any file reads for information that lives in memory. If you want to track the file reads, you will need to track them while the symbol database is being rebuilt, after pressing:
VA Options -> Performance -> Rebuild symbol databases
Looking at #include lines, can you please check to see if this is a solution specific problem? In a simple test project, does alt-g on a #include line ever work?
If this is a solution specific problem, then is it a file specific problem? In your screen shot the first two references are both to the SDK, directories that are part of your stable include directories. This is why I asked about:
#include <stdio.h>
in the nearly empty file. Since local variables are correctly understood by VA in that nearly empty file, with the simple test function, it seems to prove there is something in every other file in your solution that is breaking our parser, something that is even breaking #include lines, or that none of the file names you have tested are understood correctly by VA.
I don't know what is going on here, so all I can do is suggest tests that might give us clues. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Dec 04 2014 : 6:45:34 PM
|
The number of files alone does not make much sense as the problem here... You said your solution has 1,778 files. This is not a massive number of files, I have a solution with 25,153 files that I use for making sure the number of files on its own is not a problem.
I have just opened this solution, it takes a while for VA to parse everything, as you would expect, but once parsing has finished alt-g on #include lines works perfectly, I have tested this in several random files with different #include lines.
Are any, or even most of your files very large? I have a large cpp file that is 23,000 lines long, this is what I mean by a large file. |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 05 2014 : 01:39:22 AM
|
quote:
Originally posted by feline
So you won't get any file reads for information that lives in memory. If you want to track the file reads, you will need to track them while the symbol database is being rebuilt, after pressing:
VA Options -> Performance -> Rebuild symbol databases
It's irrelevant. When processing an include directive VA MUST query for the existence of the file inside the list of include directories. These events would have been seen in the procmon trace. No events => VA doesn't consider it as an #inlude directive => it's VA parser.
quote:
Originally posted by feline
Looking at #include lines, can you please check to see if this is a solution specific problem? In a simple test project, does alt-g on a #include line ever work?
I've already mentioned it is a solution specific. Yes, it works in other solutions. Circles detected.
quote:
Originally posted by feline
If this is a solution specific problem, then is it a file specific problem?
No. I've already mentioned that #include problem and all other problems persist throughout every file. Circles detected.
quote:
Originally posted by feline
I don't know what is going on here, so all I can do is suggest tests that might give us clues.
This is fine. Only you ignore the information I have already delivered, as if you cannot believe what I have already said. This miscommunication confuses. |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 05 2014 : 01:44:05 AM
|
quote:
Originally posted by feline
The number of files alone does not make much sense as the problem here... You said your solution has 1,778 files. This is not a massive number of files, I have a solution with 25,153 files that I use for making sure the number of files on its own is not a problem.
Well. Then there is only one possibility left: there is one very specific file or a combination of files in my solution that breaks VA parser completely. When I removed files from the solution, I got rid of this dangerous file or combination and everything started working.
quote:
Originally posted by feline
Are any, or even most of your files very large? I have a large cpp file that is 23,000 lines long, this is what I mean by a large file.
No. |
Edited by - Nox Metus on Dec 05 2014 01:44:26 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Dec 05 2014 : 4:21:24 PM
|
Can you try removing all .h files from your solution, while keeping all of the .cpp files? What happens with this set of files? Does this fix the problems?
I am guessing that one or more macros are the problem, and macros are mostly in .h files.
Do you know if your code uses a lot of complex macros? |
zen is the art of being at one with the two'ness |
|
|
|
Nox Metus
Senior Member
43 Posts |
Posted - Dec 05 2014 : 7:49:32 PM
|
I doesn't fix the problem. I would be surprised if it did, since my understanding is .h files are parsed anyway whether they are explicitly included in the project or not.
I'll try to hunt down the offensive file with the binary search.
What is a lot of macros and what is a complex macro? Where is a definite threshold? There is nothing special about macros in my project, this is for sure. |
|
|
|
Topic |
|
|
|
Troubleshooting refactoring
