如何使用C ++中的深层嵌套数据结构避免析构函数堆栈溢出？

Question

int count;

class MyClass {
    std::shared_ptr<void> p;
public:
    MyClass(std::shared_ptr<void> f):p(f){
        ++count;
    }
    ~MyClass(){
        --count;
    }
};

void test(int n){
    std::shared_ptr<void> p;
    for(int i=0;i<n;++i){
        p = std::make_shared<MyClass>(p);
    }
    std::cout<<count<<std::endl;
}

int main(int argc, char* argv[])
{
    test(200000);
    std::cout<<count<<std::endl;
    return 0;
}

The above program causes stack overflow under "release" build in Visual Studio 2010 IDE.

The question is: if you do need to create some data structure like the above, how to avoid this problem.

UPDATE: Now I have seen one meaningful answer. However this is not good enough. Please consider I have updated MyClass to contain two (or more) shared_ptr s, and each of them can be an instance of MyClass or some other data.

UPDATE: Somebody updated the title for me and saying "deep ref-counted data structure", which is not necessary related to this question. Actually, shared_ptr is only a convenient example; you can easily change to other data types with the same problem. I also removed the C++11 tag because it is not C++11 only problem as well.

Answer 1

• Make the stack explicit (ie put it in a container on the heap).
• Have non-opaque pointers (non-void) so that you can walk your structure.
• Un-nest your deep recursive structure onto the heap container, making the structure non-recursive (by disconnecting it as you go along).
• Deallocate everything by iterating over the pointers collected above.

Something like this, with the type of p changed so we can inspect it.

std::shared_ptr<MyClass> p;

~MyClass() {
    std::stack<std::shared_ptr<MyClass>> ptrs;
    std::shared_ptr<MyClass> current = p;

    while(current) {
        ptrs.push_back(current);
        current = current->p;
        ptrs.back()->p.reset(); // does not call the dtor, since we have a copy in current
    }

    --count;
    // ptrs dtor deallocates every ptr here, and there's no recursion since the objects p member is null, and each object is destroyed by an iterative for-loop
}

Some final tips:

• If you want to untangle any structure, your types should provide an interface that returns and releases all internal shared_ptr's, ie something like: std::vector<shared_ptr<MyClass>> yieldSharedPtrs() , perhaps within a ISharedContainer interface or something if you can't restrict yourself to MyClass.
• For recursive structures, you should check that you don't add the same object to your ptr-container twice.

Answer 2

If you really have to work with such an odd code, you can increase the size of your stack. You should find this option in the project properties of Visual Studio.

As already suggested, I must tell you that this kind of code should be avoided when working with a large mole of data structures, and increasing the stack size is not a good solution if you plan to release your software. It may also terribly slow down your own computer if you abuse this feature, obviously.

Answer 3

Thanks to @Macke's tips, I have an improved solution like the following:

~MyClass(){
   DEFINE_THREAD_LOCAL(std::queue< std::shared<void> >, q)
   bool reentrant = !q.empty();
   q.emplace(std::move(p)); //IMPORTANT!
   if(reentrant) return;

   while(!q.empty()){
       auto pv = q.front();
       q.pop();
   }
}

DEFINE_THREAD_LOCAL is a macro that defines a variable (param 2) as specified type (param 1) with thread local storage type, which means there is no more than one instance for each running thread. Because thread_local keyword is still not available for mainstream compilers, I have to assume such a macro to make it work for compilers.

For single thread programs, DEFINE_THREAD_LOCAL(type, var) is simply

static type var;

The benefit of this solution is it do not require to change the class definition.

Unlike @Macke's solution, I use std::queue rather than std::stack in order to keep the destruction order.

In the given test case, q.size() will never be more than 1. However, it is just because this algorithm is breadth-first. If MyClass has more links to another instance of MyClass , q.size() will reach greater values.

NOTE: It is important to remember use std::move to pass p to the queue. You have not solved the problem if you forgotten to do so, you are just creating and destroying a new copy of p, and after the visible code the destruction will still be recursive.

UPDATE: the original posted code has a problem: q is going to be modified within pop() call. The solution is cache the value of q.front() for later destruction.