# if ::iterator == 0 causes error:

## Recommended Posts

gimp    142
I have a handle class. The handle class hold an iterator in to a map.
typename typedef std::map<std::string, std::pair<ResourceType*, size_t> >::iterator ResourceItr;

ResourceItr	m_Resource;

On construction my code sets the Resource handle to 0. Later I test for the validity of the handle :
template <class ResourceType, typename IOType>
inline bool CHandle<ResourceType, IOType>::IsNull(void) const
{
return (m_Resource == 0); <<<<<<<<<<<<<<<<<<<<<
}

For some reason since upgrading to VS 2005 this test of wether a iterator is null is no longer valid. Can anyone think of why this may no longer be valid?

##### Share on other sites
smart_idiot    1298
I don't think you're allowed to do that with iterators.

##### Share on other sites
Assassin    246
don't test for null, test
if (it == container.end())

##### Share on other sites
gimp    142
hmmmm... I guess I could just add a bool to the hanlde class to track it that way. I can't use .end as the handle is hel by object that exist before the container exists and needs to be assigned later.

I'm quite suprised that I shouln't do that. I wonder where I picked that up from...

##### Share on other sites
Guest Anonymous Poster
you want to test if the ResourceType* is NULL right?

well the map stores its data as a std::pair,
so to test for ResourceType*==0 you would have to do:

inline bool CHandle::IsNull(void) const
{
return (m_Resource->second.first == 0); <<<<
}

i have no idea what the overloaded == operator does in the map::iterator though... but it should never have worked...

##### Share on other sites
petewood    819
If the iterator is actually just a pointer (which is quite possible) then it could evaluate correctly. I wonder whether the newer STL libraries have debug behaviour which detects misuse. Just a thought, no factual basis.