In these cases, thread-safety would have to be implemented in the RecursionCounter itself.

void f(int recursionDepth = 0)
{
++recursionDepth;

printf( “Recursion depth is: %dn”, recursionDepth );
// Lots of code here; for each return path, don’t forget
// to decrement recursionDepth!

}

class RecursionCounter
{
public:
inline RecursionCounter(string funcname) { counter[funcname]++; }
…
private:
static std::map counter;
};

#define RECURSION_COUNTER RecursionCounter _counter(__func__)

void f()
{
RECURSION_COUNTER;
…
}

struct algo
{
int rcount;
algo() : rcount(0) {}
// Recursive alorithm entrypoint
// Assures algoriithm isn’t started yet.
f() {
assert( rcount == 0 );
f_intern();
assert( rcount == 0 );
}
private:
struct reclvl {
reclvl(int& _r) : r(++_r) {}
~reclvl() { –r; }
int level() const { return r; }
private:
int& r;
};
f_intern()
{
reclvl( a_rcount );

do_stuff().

}
};

class incrementor {
public:
incrementor(int& i) : m_i(i) {m_i++;}
~incrementor() {m_i–;}
int& m_i;
}

and the function is

void f() {
static int recursionDepth=0;
incrementor incr(recursionDepth);

printf( “Recursion depth: %d\n”, recursionDepth );
}

class MY_F_COUNTER;
class MY_G_COUNTER;
…

as keys to get at the run-time counters.

The article says: “I’ve been touching this function which happens to call itself recursively and found that in order to add some feature, I needed to know how deeply I recursed into the function already.”

I assumed the features were application features and therefore this was not a debug only discussion.

I was thinking more of speed cost than memory cost. That’s why I used alpha-beta serach as my example.

It would perhaps be interesting to know why the OP thinks he needs to know where he is in the call stack in order to add his feature.

PS. I hate the captcha. It takes me about 3 tries to post.

“The problem with the map based solutions is that you have to lookup your void* at each call, that could get expensive depending on the size of the task and how many functions you are counting.”
if this isn’t used in an embedded system, you will never get so many recursive functions, that memory size could get a problem. we are talking about less than 10bytes per function. you will need more memory to save all your breakpoints…
the execution-time isn’t that worse, since the function-pointer is known at compiletime, so there is no lookup needed. it will only pass an int as ctor argument.

But your point about member functions is lost on me. It seems to me that no matter where you hide your static variable, you are only going to have one of them per member function. But this would only matter if you had recursive objects, i.e a.f() calls b.f() calls a.f()…. I think this would be a rare case.

If this rare case matters to you then you need some sort of support for reflection. then you could look up the object and the member function (and context?) and update that specific counter.