Getting and overview of who calls who

I have a gazillion C++ (6.0) and VB (6) projects, many of them creating COM+ objects. How do I get an overview of who calls who? Anyone knows of a tool which can do that?
The code is not mine, and those who made it several years ago have all left the company...so it's not easy (and documentation as to who calls who and why is of course non-existent).

I hope someone can give me an idea. It's difficult to change things and make sure that everything is tested and nothing is broken without overview.

Quote:

---

Originally Posted by Lars_V_J

How do I get an overview of who calls who?

---

The way is reading design documentation.

Quote:

---

It's difficult to change things and make sure that everything is tested and nothing is broken without overview.

---

And again, the way is reading test documentation.

Oh, the "Say whuuh?" and the "Nonexistent"? This is code from around 2000, and those who made it are long gone. The documentation is very general and mostly made for non-technicals. That's why I hoped there was a tool which could go through all the code and make a map of who calls who. I have several DB layer projects, each handling one or at the most two tables. Then several business logic modules to call them, and a number of programs that in turn uses the business logic modules. All nice and layered...but not that easy when there's no map of who calls who.

There aren't any tools that come with the compiler that will do this.

VS has a "caller list" on a function by function basis (and it takes a while to chew through it), but if you want an entire project/wide who calls who. then you will need to look to outside tooling.

There are tools that do this, but the only ones I know of are all commercial and aren't cheap.
There may be open source/freeware tools for this, you'll have to do some digging yourself.

In the absense of available tools, there is the 'cheap' way to do it.


to know the callers of a function.
rename the function in the header. Compile. everywhere you get errors are callers
class wide you can do the same, rename a class, compile, all the errors about the class not being found are callers.

revert and rince/repeat for other functions/classes.

It can take a while, but you can at least get some compiler assistance to work through it all to make the caller map manually. It's a lot faster than trying to find callers yourself.

Quote:

---

Originally Posted by Lars_V_J

That's why I hoped there was a tool which could go through all the code and make a map of who calls who.

---

Yeah, the name of the tool is: Software Developer.

Seriously, you really hoped that some tool is able to go through the code and understand the cross module interaction, especially for COM+ components that are executed in their own context, message queue or surrogate? I even don't dare to say out loud how much it would cost to develop such a universal tool with some decent quality. And what would be market size for the tool? Less than a dozen of deals a year? How often teams abandon their products? How often such products get revived?

I think it happens more often than one might think. Something is made, and people say "it works, let's not mess with it". Then one day they want to change a minor thing, or something stops working due to a windows update or whatever. And then too much time has passed, the people who made it is long gone and documentation were never made due to a combination of laziness and the fact that nobody wants to pay for documentation that will probably never be read. Professional? Heck, no, but I've seen it so many times now. Especially where some management suit wants to cut expenses and "saves" on documentation...

I think it could be possible to make such a tool. Analyse what interfaces are exposed and find those who try to use them. It would be a difficult task, but not an impossible one, I think. We already have tools that analyse a single program (okay, much easier!) and monitors program use to make suggestions based upon what code is called most.