Sign in to follow this  

Trying to clear up warnings, not sure how to proceed:

This topic is 3596 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

All my code compiles fine, and runs fine in practice, but my compiler is warning me about a few things, I'll paste them here:
warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss of data

warning C4715: 'Resource_Manager<Player>::get_resource' : not all control paths return a value
The first warning is due to this function here: int get_size, sometimes I will need to know the size of a hand before I proceed with game logic, that's what this is for, but that warning is annoying, is there a right way to do what I'm doing that doesn't cause this warning?
int get_size()
{
	return m_card_list.size();
}

For the second warning: In my resource manager when I request a resource, if the resource does not exist it won't return anything, but just output that the resource does not exist, should I really return a null resource pointer ever?
	Resource_Observer get_resource(const std::string & name)
	{
		Resource_Map::iterator  it = mResources.find(name);

		if (it == mResources.end())
		{
			std::cout << "This resource does not exist!";
		}
		else
		{
			return Resource_Observer(it->second);
		}
	}

Any suggestions? EDIT: I fixed one warning by doing this, is this an acceptable fix?
	std::vector<Card>::size_type get_size()
	{
		return m_card_list.size();
	}

Share this post


Link to post
Share on other sites
Quote:
Original post by kerilynne

The first warning is due to this function here: int get_size, sometimes I will need to know the size of a hand before I proceed with game logic, that's what this is for, but that warning is annoying, is there a right way to do what I'm doing that doesn't cause this warning?


If you want to be precise, use your container's size_type type as return value:


typedef std::list<Card> CardList;

// size cannot be negative
CardList::size_type get_size()
{
return m_card_list.size();
}



Quote:
For the second warning: In my resource manager when I request a resource, if the resource does not exist it won't return anything, but just output that the resource does not exist, should I really return a null resource pointer ever?


If you're returning by value, and using this design, there's exceptions:
Resource_Observer get_resource(const std::string & name)
{
Resource_Map::iterator it = mResources.find(name);

if (it == mResources.end())
{
throw std::exception("This resource does not exist!");
}
else
{
return Resource_Observer(it->second);
}
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Zao
What would it mean for a hand to have a negative size? An unsigned integral type is the correct return type for a member function that returns the size of a hand. size_t is unsigned, by the way.


If we're talking about kosher use of SC++L types, then each container provides the types it uses. A quick overview can be found under typedefs

Consider this:


template < class T, class A >
void foo( std::vector<T,A> & list )
{
typedef std::vector<T,A> VecType;

VecType::size_type l = list.size();
if (l > 0) {
VecType::value_type val = list[0];
}
}



This allows you to write a completely generic code. size_type might be different depending on platform and possibly allocator. And since type information is provided in a standardized manner, why not use it?

This holds true even for std::string.

And using ::iterator of any container does exactly the same. So why not use the same facility for all other types?

Also - names for these types are identical across all containers, so most of the functionality from any container can be accessed in a completely generic manner.

Share this post


Link to post
Share on other sites

This topic is 3596 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this