#include <string>
#include <map>
#include <boost/shared_ptr.hpp>
#include "log.h"
extern boost::shared_ptr<Logger> g_log;
//-----------------------------------------------------------------------------
// Resource Manager Class
//-----------------------------------------------------------------------------
template< class Type > class ResourceManager
{
public:
~ResourceManager()
{
if ( m_list.empty() )
g_log->SERVER( "Closing Empty ResourceManager\n");
else
{
g_log->SERVER( "Closing ResourceManager with %d unresolved resources :(\n", m_list.size() );
std::map< std::string, boost::shared_ptr< Type > >::iterator iter;// = m_list.begin();
for ( iter = m_list.begin(); iter != m_list.end(); ++iter )
{
g_log->SERVER( "Emergency removal of %s (%d references) !!!\n", iter->second.get()->GetName().c_str(), iter->second.use_count() - 1 ); // 1 reference is in ResourceManager itself
//delete iter->second.get();
iter->second.reset();
}
m_list.clear();
}
}
etc etc
Porting to Linux with code::blocks, niggle!
Author
Hi,
I have migrated to Ubuntu Linux, and am now using wonderful code::blocks with the g++ compiler.
Although I have one problem. This line of code worked in MSVC I am sure:
code blocks baulks at the iterator, saying:
error: expected `;' before ‘iter’
Please tell me it is something obvious and I have been staring at it too long!
Thanks
Si
Author
The error is in the line:
std::map< std::string, boost::shared_ptr< Type > >::iterator iter;
And the exact error is:
error: expected `;' before ‘iter’
ToohrVyk, could you elaborate on the use of typename in this example?
thanks
Si
std::map< std::string, boost::shared_ptr< Type > >::iterator iter;
And the exact error is:
error: expected `;' before ‘iter’
ToohrVyk, could you elaborate on the use of typename in this example?
thanks
Si
So is GCC at fault or is MSVC? Or are both compilers correct? I would have thought that there isn't any ambiguity as all the types are known when the function is instantiated.
It seems like it's not wanting a semicolon after the line but that dosn't make sense why it wouldn't because tht line dosn't start a loop...
typename std::map< std::string, boost::shared_ptr< Type > >::iterator iter;
Templates are odd.
Some of the stuff (template dependant types) towards the end of this page apply here.
Templates are odd.
Some of the stuff (template dependant types) towards the end of this page apply here.
Quote:Original post by Nitage
So is GCC at fault or is MSVC? Or are both compilers correct?
It is correct to complain.
Quote:I would have thought that there isn't any ambiguity as all the types are known when the function is instantiated.
That doesn't matter; templates are subject to a separate compilation pass to check syntax, before the types are checked. Before 'Type' is known, 'std::map< std::string, boost::shared_ptr< Type > >::iterator' doesn't have to be a type name (it could be a static data member, for example), because of template specialization.
Honestly, though, I'm much more worried about what the OP is trying to do with the shared_ptrs.
Is knowing how many references there are, or how many leaked resources, really going to help you find the problem? *Is* it a problem?
Resetting the resource manager's copy of the shared pointer doesn't accomplish anything. The destructor of the resource manager will destruct the list anyway, and the list will destruct its elements (the shared pointers), which will do the necessary stuff to reference counts. If other parts of the system refer to the resources at this point, then the active code won't get rid of them, and the commented-out deletion will crash the next time some other code tries to use its reference.
Similarly, clearing the list at the end of the destructor is totally useless.
What you should probably do is have the ResourceManager hand out weak_ptrs, and let its own shared_ptrs stay unique. Then you don't need a destructor at all (unless you want to inspect stuff for logging). You won't find out how many users are holding on to the now "dead" resources", but at least things will fail in a sane way.
Author
Thank you all for your enlightening contribution. I _think_ i see the distinction!
Big thanks (again) to Zahlman. The only reason for all that destructor output was to see how badly written the rest of the app was :)
This is a chunk of code of some age, when I was just grasping boost, so its very cranky. Its obvious to see how it has been hacked from a pre shared_ptr world!
I will take your weak_ptr advice. Thanks for the fresh outlook on it.
Is code really reusable? Maybe we can never bring ourselves to reuse something which is so far below our current skills (as long as we keep learning!)
Big thanks (again) to Zahlman. The only reason for all that destructor output was to see how badly written the rest of the app was :)
This is a chunk of code of some age, when I was just grasping boost, so its very cranky. Its obvious to see how it has been hacked from a pre shared_ptr world!
I will take your weak_ptr advice. Thanks for the fresh outlook on it.
Is code really reusable? Maybe we can never bring ourselves to reuse something which is so far below our current skills (as long as we keep learning!)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
