The shared pointer is a red herring. All you're doing is placing regular pointers (actually the same pointer value) inside the vector and calling Render(). Also, is this your entire code?
It is no different than this:
Code:
std::vector<CObjects*> objects;
CWarehouse* wh = new CWarehouse();
objects.push_back(wh);
for (int i = 0; i < objects.size(); i++)
objects[i]->Render();
So is it the Render() function that is causing the issue? If so, what is Render()? What does it do? Where is the code?
Code Snippet updated, thanks Paul... I create 2 separate shared_ptrs for each object
I've got to tell you that why I use shared_ptrs, because I have a direct3d app, I pass m_pd3dDevice of CD3DApplication
around to other objects, in these objects, I have to build hierarchies, sometimes I have to addref and releaseCOM to these pointers. But at the end of the application, i get m_pd3dDevice not completed cleaned up (non-zero reference counting problem). That's why.
Last edited by lucky6969b; August 12th, 2012 at 03:29 AM.
Code Snippet updated, thanks Paul... I create 2 separate shared_ptrs for each object
Your new code doesn't change anything I stated. The boost shared pointer usage is a red herring and you're being led down the wrong path in fixing the problem. The issue is somewhere else.
Get rid of the shared pointer, and you should get the same issue.
Code:
std::vector<CObjects*> m_pRenderObjects;
CWarehouse* sobj = new CWarehouse();
m_Warehouse.Load(m_pd3dDevice, _effect, _T("Data\\DemoWarehouse.x"));
sobj->Create(&m_Warehouse);
CCB * sccb = new CCB();
m_CCB.Load(m_pd3dDevice, _effect, _T("Data\\cb.x"));
sccb->Create(&m_CCB);
m_pRenderObjects.push_back(sobj);
m_pRenderObjects.push_back(sccb);
for (int i = 0; i < objects.size(); i++)
objects[i]->Render();
Same code, no shared pointer. Does this give an error?
But in general, if a program crashes, there is no one here that can help you unless we have the entire program and run it ourselves.
I really don't get why so many posters believe we have extraordinary powers to debug programs where we have little to no source code, we don't know what data or values are used to run the program, we don't know how the program flows, but are supposed to figure out why a program crashes.
Maybe the problem starts way before that line where you say crashes. Maybe the entire object is invalid (seeing that it is a member function of a class). All we have are maybe's, unless we have the code, run it, and duplicate the error. Otherwise, program crashes can only be solved by the persons with the program in front of them, running it and duplicating the problem.
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan
Looking at your first post, I can see a problem with your use of shared_ptr.
A shared_ptr will delete the object once the last shared_ptr that points to an object goes out of scope. Since you are not storing the shared_ptr in m_pRenderObjects, the variables sobj and sccb will delete the pointer that they hold when they leave scope. Depending on the scope of these objects, this can occur before the loop where you call objects[i]->Render() - for instance if you initialize these in a routine.
Why is m_pRenderObjects a vector of simple pointers to CObjects? By changing this to a vector containing shared_ptr<CObjects>, the shared_ptr can then keep alive when you add it to the vector. If you can't change m_pRenderObjects, then you shouldn't be using shared_ptr for these objects.
Reply With Quote
Originally Posted by lucky6969b
Bookmarks