Static functions and calling trees. :-P

[Mustang]

Hi!
Synopsis:
  Is there a way I can have SE recognize static functions when it determines the calling tree?


Long version.
  Background:  I inherited many many thousands of lines of complex code.  I've been using SE's ability to define #DEFINES to get around the problem of SE not seeing references and fully doing calling trees in code with #DEFINES.  For the most part, I've been able to find a decent working set of #DEFINES.  That's the good news.

  Now, I found another "issue" with SE and calling trees - static functions.  Yea, it's been a while since *I* have used a compiler that didn't puke if I didn't do a prototype define.  So, for local only functions (the reason why a function is defined to be "static"), I never worried or cared about using the keyword "static" in the function definition.  But, I guess it's a good idea.  Well, that is unless you use SE to give you the calling tree.   I looked and tried all of the options that I could find, and it didn't seem to make any difference.

  Basically, SE does not parse/handle static functions properly while doing a calling tree.  The code has many files.  Some files are huge.  A few files have many functions in a single file (hey, I didn't write the code initially , and the most of the functions are defined as static.  Yea, it's kinda OOP-like doing that way.  OOP - YUCK!   Back on track:  The functions call each other and the calling depth can go on for a number of levels.   If I just nuke "static" everywhere (I even nuked "static" on the variables - not good and unacceptable), then SE determined the calling tree just fine.  But, I now need to have a separate copy of the code just so I can get the calling tree for these functions in these rather large files - not good.  :-P

  Also, since I'm not the only one working in the code, and there's the chance that we may share updates with the other group/project (originators), I do not want to nuke the "static" definitions on functions.


  So...  Is there a way I can have SE recognize static functions when it determines the calling tree?

Thanks in advance!
Joe

[hs2]

Try this workaround (I'm still using):
- add #define static static to your C/C++ Preprocessor setup (@see Language setup).

In addition have a look at this little helper macro maybe useful when analyzing legacy code and using the calltree feature.

Good luck,
HS2

[Mustang]

hs2: 
Thanks!  I'll try it on Thursday.

Thanks again!
Joe

[Dennis]

I have tried to reproduce the problem you are describing and the call tree seems to work fine, both getting the call tree of a static function and getting the call tree of a function that calls a static function.  I also tried all combinations of static with prototype, prototype with static omitted on the definition, static without a prototype.

The short story.  Please post an example and also a screenshot of the call tree failing for that example.

I sympathize that you are seeing data that appears to be wrong; I just need a better definition of what wrong means.  Is data omitted from the call tree, or are you getting more hits than you expect (incorrect data in the call tree).

FWIW:  unless the code is doing *extremely* hackish things with static functions (which your example will reveal), you should not need Hartmut's workaround in order to get correct results.

Also, please verify that you do not have a filter set in your call tree.  Right click in the call tree window and select Quick Filters > Show All Tags.  If you are filtering out static functions, then well, yeah, they will be filtered out.

[Mustang]

Dennis,

  Thanks for looking into it.  I'm not at work today, I'm off from work getting other stuff done.  I'm pretty sure that I checked my filters.  I'll double check on Tuesday.  I'll let you know what I find.  It would be good if I didn't need a hack.  I'm trying to convince others to get slickedit.  For the price, I find it an invaluable tool!

  Thanks again!
_________
Joe

[hs2]

@Dennis: I'll test the (meanwhile finished) project with v13 asap. where I had the problems with static functions using v12 and I'll post a report. If there is still a problem I'll extract and submit a sample workspace.
@Mustang: The CPP thing is not a real hack - it's just a workaround.
And yes, SE is an invaluable tool - regardless of the price
HS2

[hs2]

@Dennis: Good news, I've tested the workspace mentioned before with v13 to verify that the reported problems in v12 are gone.
I can confirm that v13 handles static perfectly now - no more problems after removing the CPP workaround and retagging all src files.
Thanks, HS2