You can use the following:
if (typeid(quantity) != typeid(int))
But here's a note....The only reason I use this is because I have a function that uses templates and at one point I need to check for a certain type. You won't run into this problem if you're just using a normal function definition because your input will be cast into the argument type. For example, if I have the following function:
void myfunction(int x)
{
//some definition
}
but when I call my function I do this......
double input = 4.2;
myfunction(input);
The value of input gets cast to an int (4.2 turns into 4...well...basically anyway...), which can lead to some unexpected results.
I think probably what your teacher expects is for you to check the input in an attempt to take preventative action against runtime errors.
For example. Take the following [unrealistically simple :) ] function:
void myNum(int * pInt)
{
int iNumber = *pInt;
}
This is fine as long as you made sure that pInt actually points to something...As follows....
int * p = (int *)malloc(sizeof(int));
*p = 37;
myNum(p);
But let's say you forgot to say what p was, intending to set it later somewhere else...
int * p = NULL;
//pretend there is other code here where you assume p is going to be made to point to something.
myNum(p);
The compiler won't complain about this. But you'll get an error at runtime because when you dereference the pointer inside myNum() you'll be trying to read a null pointer. You can get around this by adding a check inside your function definition.
void myNum(int * pInt)
{
int iNumber;
if (pInt == NULL)
{
printf("Null pointer!");
return;
}
else
{
iNumber = *pInt;
}
}
Now when you try to feed the function a null pointer, it catches it before it's too late and the function returns before trying to dereference the pointer. Believe me, this sort of check is invaluable and when you have 20,000 lines of code can help you identify a problem WEEKS sooner than a runtime error you get because you forgot to check for invalid input somewhere.