| Author |
 Topic  |
|
|
Erik Olofsson
Tomato Guru
111 Posts |
 Posted - Oct 05 2004 : 03:33:11 AM
|
These are the three features that I would have most use of in VA:
State aware completion:
The ability of VA to recognize what symbols are available from the file I'm typing in. It should look at what files are included from the current file and only show symbols from the included files. If you are in a header file VA should should keep a list of other files that includes this file and deduce the correct information.
Even better would be if va could look at the current selected configuration and deduce what defines and include paths are defined for this configuration. I understand that this would be a much more complicated feature, but would add to the robustness.
Working template parser:
It would be great if some time and effort is spent on the template parser to make more constructs work.
Parser plugins:
If the above features are unavailable it would be cool if we could write our own replacement parser :)
|
Cutting Edge Project Management
http://www.hansoft.se |
Edited by - Erik Olofsson on Oct 05 2004 03:33:46 AM |
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 05 2004 : 04:19:20 AM
|
| Strong support for the first two. Regular readers will know that these are both topics I've been on about. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
 |
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 05 2004 : 12:00:18 PM
|
quote:
The ability of VA to recognize what symbols are available from the file I'm typing in. It should look at what files are included from the current file and only show symbols from the included files.
This should be standard behavior, at least with respect to suggestions and completion listboxes.
In what case(s) does VA X show out-of-context symbols?
quote:
If you are in a header file VA should should keep a list of other files that includes this file...
Interesting suggestion, but not sure what we'd do with the list of "including" files. Offer suggested completions from other headers #included elsewhere, prior to the #including of the current header?
quote:
..deduce what defines and include paths are defined for this configuration.
Would be nice, but implementation is very, very difficult to get right. Preprocessor macros do not exist in newer languages, e.g. C# and Java, for several reasons, one being they make it impossible to implement certain editing tools.
quote:
...time and effort is spent on the template parser
We can't argue this one.
case=201
quote:
... it would be cool if we could write our own replacement parser.
Unlikely to happen with VA X. |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 05 2004 : 12:16:11 PM
|
quote:
Originally posted by support
This should be standard behavior, at least with respect to suggestions and completion listboxes.
In what case(s) does VA X show out-of-context symbols?
VAX includes all #defines from all files regardless of whether they are #included in the current file or not. I understand why it can't parse the #ifs and #ifdefs, but it should still follow the #includes. See threads 2390 and 2951. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
Erik Olofsson
Tomato Guru
111 Posts |
Posted - Oct 05 2004 : 3:02:59 PM
|
I will illustrate what I mean by state aware completion with an example from my project:
First some background info:
I'm in the file Ids_Debug.cpp
When I compile with /showIncludes :
..\\..\\PCH\\Ids_PCH.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/Platform/Ids_Platform_Platform.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\Ids_Platform_Defaults.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\Architechture/X86/Win32_MSVC.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\architechture\\x86\\../../Compiler/Win32_MSVC.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\compiler\\MSVC.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\compiler\\32.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\exception
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\xstddef
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\yvals.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\use_ansi.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\cstddef
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\stddef.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\eh.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\typeinfo
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\typeinfo.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\stdexcpt.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\Ids_Platform_CheckDefs.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/Math/Ids_Math_Float.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\math\\../General/Ids_General.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\math\\Ids_Math_MSVC_Windows_x86_32.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/Runtime/Ids_Runtime.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/Math/Ids_Include_Math.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/General/Ids_Include_General.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_General.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Debug.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_SystemSpecificInterface.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Memory.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Memory_Allocator_Virtual.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Memory_Allocator_Heap.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Stream.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_TypesDefines.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Types.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Exception.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_List_Linked_Simple.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_List_Linked_Simple_Single.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_List_Linked_Simple_Double.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_System_Thread.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_List_Vector.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Aggregate.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Tree.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Tree_AVL.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Memory_Pool.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Memory_Heap.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Memory_Heap_THeap.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_General.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_StrToInt.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_StrToFloat.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Data2Str.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_TStr.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Imp_VirtualStr.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Imp_DynamicStr.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Imp_FastStr.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Data2Str_String.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Data2Str_TStr.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Data2Str_Integer.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Data2Str_Float.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_FormatTypes.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Str_Mixed.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_System.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_System_RuntimeObject.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_SystemShared.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_System_Timer.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Memory_Allocator_Shared.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_List_Linked_Dynamic.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Misc.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Registry.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Stream_Memory.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\general\\Ids_Time.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/Data_Processing/Ids_Include_Data_Processing.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\data_processing\\../Platform/Ids_Platform_Platform.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\data_processing\\Ids_DP_MD5.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/File/Ids_File.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\file\\Ids_File_Interface.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\file\\Ids_File_VirtualFS.h
..\\..\\..\\..\\..\\Ids/Ids.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/Communication/Ids_Include_Communication.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\communication\\../Platform/Ids_Platform_Platform.h
First lets examine what happens in this particular file when I want to complete a word (Ctrl+Space):
Here I get symbols defined in winnt.h (As you can see above winnt.h hasn't been included from this file). It might be understandable because winnt.h is in the system includes. That said it optimally shouldn't show anything from winnt.h here. Even worse:
Here you can see classes defined in another project, and again not included from this file.
There is however a problem with my suggestion. Say I was editing
x:\\work\\source\\main\\projects\\ids\\Library/Core/Math/Ids_Math_Float.h
and that I hadn't done the hack #include <Ids/Ids.h> in this file to make VA parse all dependencies for this file while I'm editing in it.
If I was editing this file VA cannot directly deduce what symbols should be known in this file. Here the awareness of included files comes in. In this example VA would know that these files symbols should be available when editing this file:
x:\\work\\source\\main\\projects\\ids\\Library/Core/Platform/Ids_Platform_Platform.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\Ids_Platform_Defaults.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\Architechture/X86/Win32_MSVC.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\architechture\\x86\\../../Compiler/Win32_MSVC.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\compiler\\MSVC.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\compiler\\32.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\exception
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\xstddef
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\yvals.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\use_ansi.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\cstddef
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\stddef.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\eh.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\typeinfo
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\typeinfo.h
X:\\Apps\\Development\\VS.2003\\Vc7\\include\\stdexcpt.h
x:\\work\\source\\main\\projects\\ids\\library\\core\\platform\\Ids_Platform_CheckDefs.h
x:\\work\\source\\main\\projects\\ids\\Library/Core/Math/Ids_Math_Float.h
Optimally I should include all dependant header files from Ids_Math_Float.h but to be robust VA should support this type of including also.
Edit: Put images on http server instead |
Cutting Edge Project Management
http://www.hansoft.se |
Edited by - support on Oct 06 2004 11:17:57 AM |
|
|
|
ivan
Ketchup Master
Russia
75 Posts |
Posted - Oct 06 2004 : 09:45:17 AM
|
I'm not sure I have any problems with the first issue Erik mentioned (maybe I'm just used to the excessive suggestions), but the second one, frankly speaking, has been annoying the hell out of me for quite some time. Please, please, give template parser fixes some priority. I spend a lot of time programming with STL and there has been no progress on VAX template issues for well... quite some time. :/
I really hope that now (with the release of v10.1) you are going to polish the existing product before moving on to adding the next set of features. |
Edited by - ivan on Oct 06 2004 12:06:18 PM |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 06 2004 : 10:41:47 AM
|
Issue 1 is more serious than just getting too many suggestions. My example in 2390 was where it can't find a symbol because something of the same name is #define'd in an independent cpp file. Larry's example in 2951 (private beta forum) was where the tooltip led him to believe that the value of the #define was something different than what it actually was, because another #define of the same name was present in an independent cpp file.
My guess is that the reason VAX doesn't follow the #include path for #defines is that it's somehow quicker, and the developers thought, like you, that a few false positive suggestions didn't matter. Which is probably true. But it has more harmful side-effects as well.
I agree with everything else you say, ivan. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
ivan
Ketchup Master
Russia
75 Posts |
Posted - Oct 06 2004 : 12:48:26 PM
|
Stephen, I didn't say false suggestions didn't matter. Living the hard life of a perfectionist I wouldn't think of saying such a thing ;) They do matter and they must be eliminated.
What I was saying (well, trying to say, let's put it this way) was that the first issue doesn't seem to affect me in particular, but the second does, so I'd like to see some progress on the second one. If it sounded like I was trying to belittle the importance of other bugs - I wasn't. ;) |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 06 2004 : 2:37:51 PM
|
We spoke without qualifying. VA X should show project-specific symbols in proper context. Other symbols are known everywhere.
Symbols found using "Stable include files" in our Directories node are available in all contexts. As Stephen suggested, this is done for speed. Parsing every header, e.g. all of MFC, each time you open a file, with or without caching, is ridiculously slow. (Think 1/4 of your build time.)
We employed the "Stable known everywhere" policy when we first built Intellisense for VC++ 5.0. (We tried the other way first.) MS employed the same scheme when they introduced Intellisense in VC++ 6.0. We presume they opted for our technique for the same reason, i.e. speed. MS went one step further -- prebuilding symbol databases (but then not offering help for symbols they didn't know ahead of time.)
Symbols outside your project, i.e. in another project, but not part of the "stable" symbols, become known if you open a header or cpp from that project, open a file that includes a file from the other project, or open a file that includes a header VA X cannot find in your current project but finds in another project. VA X assumes you are working on two projects simultaneously, .e.g. modifying files in two projects to fix a common problem; VA X assumes you want to know about symbols in both projects.
If you re-open your project, VA X forgets about the symbols in the other project.
If you have a local symbol with the same name as a #define, i.e. a "stable" symbol, VA X should know the definitions of both symbols. Our Definition field at the top of your source window becomes a dropdown with both definitions.
We will update the information on our site accordingly. |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 06 2004 : 2:45:12 PM
|
One more thing... the problem with context and the "set of known symbols" does not exist in C# for several reasons. First, C# does not allow preprocessor macros which slow parsing (to a relative crawl, particularly parsing while-you-edit). Second, C# does not have separate header files -- namespaces are built with a nice, neat, easy-to-read sets of symbol definitions. Open a namespace, i.e. a library, and grab the list of all symbols in the namespace. Very little CPU time necessary.
For C#, only symbols valid in the current context, stable or not, are ever suggested or listed in a completion listbox. This is the case with and without VA X. The simplicity of the language makes this possible. |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 06 2004 : 5:31:10 PM
|
| OK, I understand the explanation about stable symbols being visible everywhere. That seems perfectly reasonable for MFC headers etc. But neither of the examples I cited above (2390 and 2951) is in that category. In both cases, the #define that caused problems was within the current project but not #include'd in the file being edited. If I've understood you correctly, that really shouldn't be leaking into the file being edited, and hiding another symbol in scope, should it? Or am I still missing something? |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
Erik Olofsson
Tomato Guru
111 Posts |
Posted - Oct 06 2004 : 7:42:45 PM
|
I cannot see how it could slow you down so much if you tagged every symbol with the file it's defined in, then when you show the completion box you show only the symbols of the include tree for the file you are editing in.
The problem for me here is that i'm working on several projects at a time and some are platform independent, and does not use anything Windows. When I'm completing things the global namespace is crowded with junk I have no interest in whatsoever.
Also I cannot remove windows includes from stable includes, because then VA cannot find those headers.
I have removed MFC headers from stable includes, and it finishes parsing when I open the project in about 15 seconds, which I'm more then happy to wait.
The fact that I have two projects open at the same time almost never means that they share the same symbols.
|
Cutting Edge Project Management
http://www.hansoft.se |
Edited by - Erik Olofsson on Oct 06 2004 7:43:46 PM |
|
|
|
schoenherr
Tomato Guru
Germany
160 Posts |
Posted - Oct 07 2004 : 12:31:46 AM
|
i remember that support stated a long time ago, that showing symbols from not included files or not valid for current config isn't only a problem of realization but also a design decision. Because you often code such things like
#ifdef XYZ
...
#else
...
#endif
which would cause visual assist leaving you nearly alone in one of those two code blocks.
the thing with not included header files is:
i often code from memory, not worrying about the needed header file is already included or not (the compiler finaly reminds me to include the needed files), and i would be very annoyed if visual assist didn't help me in such situations. |
|
|
|
Erik Olofsson
Tomato Guru
111 Posts |
Posted - Oct 07 2004 : 09:14:55 AM
|
So make it an option and provide different keyboard shortcuts for different completion boxes.
The defines isn't the most important features if two includes are available through different #ifdef branches use both. |
Cutting Edge Project Management
http://www.hansoft.se |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 07 2004 : 10:01:41 AM
|
Stephen:Your observation is correct. #defines are available in an entire project, whether they are #included by the current file, or not.
Three of the reasons, mentioned in this thread, for our behavior:
1. Speed (by far, the biggest reason)
2. Need to accommodate #includes inside #ifdef/#else.
3. Give assistance before #includes are written.
As for tagging, one would need to list the file that defines the symbol, the header(s) in which it is declared, every file that includes its header(s), every file that includes a header that includes its header(s), every source file that includes....
#ifdefs around headers make the tagging more complicated.
The number of symbols in MFC alone is staggering.
When you press 'a', our suggestion list does little good if it does not appear immediately. And if we made your IDE sluggish (a topic for a different thread), we'd have a bigger problem on our hands.
It's all a trade-off. |
|
|
|
Erik Olofsson
Tomato Guru
111 Posts |
Posted - Oct 07 2004 : 11:20:58 PM
|
quote:
Originally posted by support
As for tagging, one would need to list the file that defines the symbol, the header(s) in which it is declared, every file that includes its header(s), every file that includes a header that includes its header(s), every source file that includes....
I see you and raise you 0.3 milli seconds 
I did what my feature request called for in my first case and it took an additional 0.3 ms to filter out the wanted symbols with a list of includes (that can be cached for the opened file). All symbols taken from the static VA database and the largest dynamic file in cache directory.
The technique I'm using has the complexity
log2(NumIncludes)*NumSymbolsToFilter
In this case the number of symbols in the listbox decreased from about a thousand (these figures does not remove duplicates due to symbol defined in many files) to about 20 symbols.
971 Files and 184117 Symbols was read and 98636 global symbols was indexed in 0.580 seconds
Got 1 symbols starting with CDC in 23.045 micro seconds
Got 22 symbols starting with N in 17.262 micro seconds
Got 1090 symbols starting with n in 374.260 micro seconds
78 Include Files was read and indexed in 0.001 seconds
Filtered symbols starting with n and N with include tree (1005 symbols was removed) in 291.284 micro seconds
Same thing but with an include tree from a file that use MFC and xerces
Filtered symbols starting with n and N with include tree (221 symbols was removed) in 266.628 micro seconds
|
Cutting Edge Project Management
http://www.hansoft.se |
|
|
|
Cezariusz
Tomato Guru
Poland
244 Posts |
Posted - Oct 08 2004 : 03:01:59 AM
|
Nice job Eric! Maybe you will contribute to VA X  |
Cezariusz Marek
https://midicat.net/ |
|
|
| |
Topic |
|
Topic Locked
