Problems with tagging C++ source

[mike_pentney]

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.

[sdayts]

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.

[sdayts]

In addition to def_cb_flood_refresh, I have also set def_cb_high_refresh to 50000.  That took care of the pop-up.

[osx-addict]

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..

[mike_pentney]

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...

[Dennis]

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.

[mike_pentney]

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?

[Dennis]

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++.

[mike_pentney]

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....

[mike_pentney]

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...

[sdayts]

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.

[tsegura]

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.

[shadowbane]

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.

[allank]

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.

[hs2]

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