c++11 - unable to rid recursive parsing code of shared_ptr leaks -

i using shared_ptrs extensively in production code reduce complexity , maintenance , working fine. have, however, written parser complex meta-grammar leaves shared objects upon exit. 1 of culprits caused recursivity. since parsing code complex in itself, want re-use each time descend next level. consequently, save off current element in parent's element while doing descendent parsing. causes problem of many remaining strong refs. have experimented bit weak vs strong storing , treevect uses weak_ptrs, parent assignment problem persists. question is, how can rid of second strong ref gets added on assignment parent statement below? here code illustrates problem:

#include "stdafx.h" #include <memory> #include <vector>  struct tree; typedef std::weak_ptr< tree > treewptr; typedef std::shared_ptr< tree > treesptr; typedef std::vector< treewptr > treevect;  struct tree {   treevect treevect;   //treesptr parent;   treewptr parent; // changed strong weak ptr };  struct element1 : public tree { };  struct element2 : public tree { };   int main() {   treesptr element1 = std::make_shared< element1 >();   treesptr element2 = std::make_shared< element2 >();   //element2->parent = element1; // illustrates recursive case.  error: adds strong ref element1   //element2->parent->treevect.push_back( element2 );   element2->parent = element1; // no longer adds strong ref element1   element2->parent.lock()->treevect.push_back( element2 );      return 0; } 

note: solved example program's problem changing parent member shared_ptr weak_ptr.

no 1 has substantively weighed in on doing, applied know far smart pointers: never go out of scope more 1 strong ref object or won't destruct. seems obvious now.

result implementing recursive parser using shared_ptr

success! fyi, here practices used in solving problem:

1) start out programming project in general not considering using weak ptrs. make shared ptr. need attention squarely fixed on solving project @ hand without distractions. is, don't try optimize until done. keeps engineering code-weirdness in due ptr logic. btw, next time make better estimate @ ownership properties each of objects should have @ outset.

2) use memory leak detector program. write in c++ mfc automatically reports leaks , memory blocks on each run easy track down culprits.

3) when satisfied program, rid of leaks, re-think ownership of objects there 1 strong reference top object want automatically destroyed @ end of execution path.

one side-effect of using shared_ptr code got simpler. promised c++11 designers , it's true. error messages forced me think through @ compiler-time ownership of each object. gone days when i, in destructor, test see if pointer non null , delete , hope other threads finished.

one caveat: have not implemented try/catch around weak_ptrs have expired. need production code. i'll report here when do.