Getting the name of a function, and the function that called it.

[m4ster r0shi]

Guys, I don't disagree that using macros is a good idea. But that's not what the OP wants.

Ideally, for any given problem code area, I want to be able to cout the immediate function, and ANY AND ALL functions that lead to the function in question being called.

Of course, if you insert print lines inside every function of your program, the above will be achieved, but you see, if the program has like 20 or more functions the output is going to be a mess. The decent solution is to store the names of the functions called so far (just store, not print them) and only print them when you want to. Now, this is something that you simply can't do with just a macro.

[helios]

It the program has 100 functions or more, I pity you, because you'll be copying that code at the beginning of each and every one of them.

[m4ster r0shi]

What's your point here? I'm afraid I failed to get it... You'll also have to do the typing if you choose to use macros. Also, like Galik's suggestion, which I found interesting in the way that it doesn't have to put many things inside his functions, you can make a class which pushes the function name in its constructor and pops it in its destructor. Then the only thing you have to do inside a function is declare a temporary instance of that class giving it the function name as a param. This way, you also don't have to worry that the name won't be popped if the function doesn't terminate normally.

[helios]

The point is that the solution is unwieldy for complex enough programs. In these situations it's better to use the debugging facilities provided by the OS rather than roll your own buggy solution (for example, what happens if you miss a function that's in the stack trace at that particular moment?).
I just found this by Googling "windows print stack trace": http://www.codeproject.com/kb/threads/StackWalker.aspx I'm sure there's a lot more for more platforms.

[m4ster r0shi]

helios wrote:

No. Function names don't exist at run time. Some compilers might have some extension that lets you get the stack trace.

helios wrote:

The point is that the solution is unwieldy for complex enough programs. In these situations it's better to use the debugging facilities provided by the OS rather than roll your own buggy solution (for example, what happens if you miss a function that's in the stack trace at that particular moment?).
I just found this by Googling "windows print stack trace": http://www.codeproject.com/kb/threads/StackWalker.aspx I'm sure there's a lot more for more platforms.

See, you can actually be useful if you try hard! :D

EDIT: Also...

helios wrote:

In these situations it's better to use the debugging facilities provided by the OS rather than roll your own buggy solution

That is correct only if the OS is not some version of windows, since in that case the OS's code is probably buggier than mine ;)

[helios]

I just did what OP should have done to begin with.
My second post doesn't contradict the first one, by the way. That solution relies on debugging symbols being available.

[m4ster r0shi]

helios wrote:

My second post doesn't contradict the first one, by the way.

I never said it does. The only thing I implied is that the second answer was a whole lot more useful than the first one.

I also wanted to note that the solution you provide is OS dependent but if the OP doesn't plan on changing OSs during the development of his project then I guess it's ok.