SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: mike_pentney on July 10, 2006, 10:35:41 PM
-
Does anyone else have problems with tagging and browsing C++ source? I'm working on a fairly large app (about 500 kloc) configured as a number of Visual Studio 2005 projects grouped into a single solution. The code uses namespaces quite extensively, and unfortunately I've had to stop using SlickEdit because it can't parse the code (though Visual Studio has no problems...)
I've also found that I can't get SlickEdit to use the VS2005 C++ compiler, even when I explicitly choose it in the options dialog. And finally, is there is a really annoying feature in the code browser tree: when I expand a namespace containing a large number of classes and functions, it pops up a dialog box warning me that the tree node contains a lot of elements, and asking if I *really* want to expand it....this gets to be unbelievably annoying after a few thousand repititions. Is there some way of turning this dialog off? Please?
I'm (no longer) using SlickEdit v11.0 on a Windows XP system.
Mike.
-
On the second question, getting rid of the annoying pop-up dialog.
I have bumped up against it a while ago. The solution was to modify a slickedit internal variable (Macro->Set Macro Variable...) I am fairly (though not 100%) sure that it was the "def_cb_flood_refresh" variable. Just set it so some very large number.
-
In addition to def_cb_flood_refresh, I have also set def_cb_high_refresh to 50000. That took care of the pop-up.
-
We've got a large project that's at least that size, but hosted on a Unix box (compiled w/ g++) and no namespaces at all and VSE chews it up just fine.. It's not uncommon to have multiple tag files open and no problems so far..
-
sdayts: many thanks - I'll try changing the variables you mention next time I use SlickEdit.
osx-addict: thanks for your comment. I'm not sure if the problems I have are because my app consists of lots of Visual Studio (sub-) projects, or because it uses namespaces a lot. But although SlickEdit is a *much* better editor than VS, once you lose source tagging it ceases to be an advantage. (Like most people, I spend far more time reading code than I do writing it, and good navigation tools are vital.)
Visual Studio 2005 is far from ideal - every once in a while it updates the source browser database, and when it does it stops responding to input. So you're typing away and suddenly realise that your keystrokes are not doing anything, and you have to stop mid-flow to wait for the darned program to finish the update and pay attention once again...
-
To address your first issue with C++ tagging. The most common problem people have is preprocessing. If you use namespaces with the typical idiom:
#if __cplusplus
#define MY_NAMESPACE_BEGIN(x) namespace x {
#define MY_NAMESPACE_END }
#define MY_USING(x) using namespace x;
#else
#define MY_NAMESPACE_BEGIN(x)
#define MY_NAMESPACE_END
#define MY_USING(x)
#endif
Then the parser will be lost when it sees:
MY_NAMESPACE_BEGIN(mike)
...
MY_NAMESPACE_END
The solution is to define your idiomatic preprocessing to SlickEdit using the C/C++ Preprocessing configuration dialog. Tools > Options> Tagging Options > C Processing...
The second problem people commonly have with namespaces is side-effecting header files. By this, I mean, they will put "using" statements in a header file. Since, for performance, the tagging engine does not recursively parse header files, the context tagging engine may not be able to resolve references to symbols since it is not aware of the using statement that was introduced through a side-effecting header file.
-
Dennis,
Thanks for the post.
The app I'm working on does not use preprocessor macros for namespaces as in your example, so I don't think this is the problem. On the other hand, there are some "using" statements in header files. (Out of about 620 "using" statements in total, 29 are in header files.)
Is there a way to get the tagging engine to parse these header files? Or does it slow the whole process down too much?
-
Unfortunately, preprocessing is a slippery slope, even if you discount the serious performance issues. For example, when you start recursively parsing header files, well, first you have to be able to find them, so that means the user really has to set up his include file path correctly. As we have learned from our C++ refactoring engine, which absolutely has to do full preprocessing and parsing in order to build a correct DOM, just setting up include paths is a heavy burden for most users who just want to spin it up and go.
Now, back to the original question. If you find problems with C++ tagging apart from the aforementioned limitation with respect "using" in header files, please put together a small, but complete, example and report the problem to support@slickedit.com. We are determined to be the best editor available for C/C++.
-
I'll try to create a small example that breaks the tagging, but I suspect that part of the problem stems from the size of the app I'm working on. Unfortunately, I'm just a contractor on this app so I can't send you the source code....
-
Dennis.
I just read your comment about the Boost library in reply to the thread about Refactoring, and (you guessed it) the app I'm working on uses some of the Boost libraries, so perhaps this is the source of the tagging problems I've been experiencing.
Having said that, Visual Studio 2005 is able to decipher the code and present the namespaces, classes, methods and data members correctly, using exactly the same source files. So there is definitely a problem with SlickEdit's parsing/tagging routines. I gues I'll just have to battle on with Visual Studio and only use SlickEdit on smaller, less complex projects...
-
My current workspace has over 14000 files in it and tagging works beautifully. So I would disagree with your suggestion that SlickEdit can only handle small projects.
-
We've had a similar problem with tagging and namespaces. It all started with v9.0.4; v9.0 worked great. We are now on v11.0.1 which works better than 9.0.4 as far as tagging in general, but still has issues which I have narrowed down to be namespace related as well. I have provided SlickEdit support a very simple example (2 classes in the same namespace, each with one method, and one with a pointer to an object of the other) of this issue back in June, but based on this discussion, perhaps that has gotten lost.
-
If it helps any, I work on a similar project to the one in question. Although it is currently all VS2003, not VS2005. about 30 project files and thousands of source files. Slickedit has never given me any troubles with tagging (normal refactoring is completely useless though. Quick refactoring works quite well with the occasional blunders). We have only occasional use of namespaces, and no using statements that I'm aware of.
-
I have a tagging problem; also the solution. Using SE 11.0.2 w/ VS 2005. My project uses several DLL's that are also under development and that are in separate workspaces. The header files exist in those workspaces (I don't want multiple copies of header files that are in flux). My project includes those header files. As I said, they are not in the current workspace or the system path. However, the #includes specify fully qualified paths. VC++ 8 has no trouble finding the classes contained in those header files. SE doesn't find them. The solution is to add those header files individually in the tagging dialog. This works but is annoying and, since the fully qualified path is specified in the #include, it should be unnecessary.
-
To avoid the fully qualified path for each #include have a look at 'Project->Project Properties->Directories'. There you can specify the paths to add. 'system'/'project global'/'3rd party lib' headers to lookup on errors or when a 'goto tag' (Ctrl-.).
What's the problem w/ using a workspace which includes all related projects while working on the 'active' project ? This should eliminate the need of manual (cross-)referencing headers in each project.
HS2
-
I know there are multiple solutions to the problem, such as the ones you've mentioned. I guess I'm just venting. The information is there in the fully qualified name. It seems strange to me that an elegant piece of work like SE can't do what MS VS can do easily.
-
(alank) The umbrella workspace solution isn't great when you are using Visual Studio because then you must manually maintain your own workspace. This is very inconvenient when working on a large multi-person project. A better solution is to add workspace specific "Auto-Update Tag Files" (a feature I'm not sure anyone has found).
Let's say you have A.sln which needs stuff built from B.sln and C.sln. Open each of the workspaces in SlickEdit. This will create the tag file. Now open solution A.sln in SlickEdit. Then go to Tool>"Tag Files...", click on "Add Tag File...". Click on "Auto-Update Tag Files". Now select the B.vtg tag file which will be located in the same directory as B.sln. Repeat these previous two steps to add C.vtg. Now when you open solution A.sln in SlickEdit, you'll see symbols from B.sln and C.sln. When files are added to B.sln or C.sln, you'll need to open either B.sln or C.sln in SlickEdit for the tag file to be updated :-(. This is not perfect but it's a lot better than adding files twice or maintaining a separate SlickEdit workspace and project files.
Currently, symbols from workspace specific tag files ARE NOT updated when you edit files in those tag files. For example, lets say you edit B.cpp contained in B.sln when the solution A.sln is open in SlickEdit. The symbols for B.cpp will not be updated in B.vtg until you open B.sln in SlickEdit. This seemly odd limitation is intentional and took more work. The workspace specific "Auto-Update Tag Files" feature was actually designed to solve a very different problem. It assumes that another process is updating the tag file because it is supposedly HUGE (maybe 100 megabytes). It would be nice if this feature tweaked to handle simple workspace specific tag files and the current external auto-updating feature. Or even better for Visual Studio users...workspace specific solution files.
-
It should be possible to manually update the (auto-updated) tag file in the 'Tag File' dialog.
The issue remains that it still requires manual interaction, but you don't need to switch workspaces.
Thanks Clark for the hint that the Auto-update tag file is WORKSPACE specific !
I wasn't aware of it.
This solves my old problem of having diff. (cross-)cross-compiler tagfiles per workspace.
BTW: 'cross-cross' means that I use a cross-compiler hosted by a cygwin environment.
Slick detects the host cygwin compiler properly but has obviously no idea about the hosted one.
I used to create global C-tag files for them, but they were present in all workspaces leading to conflicts.
So I had to 'manually' add/remove the proper tagfile...
HS2