Printable View
Suppose I have mytype that could be defined as either signed (int, short, long) or unsigned. And I don't know what the type is passed in.Code:typedef int mytype;
//typedef unsigned int mytype;
bool isSigned(mytype x)
{
//how to tell if mytype is a signed type or not?
}
How do I tell if mytype is a signed type or not?
I guess you can use the knowledge that the minimum value an unsigned type can hold is 0. In addition the compiler knows what mytype is typedefed as, therefore:
(Although, it seems somewhat strange to determine this at run-time.)Code:#include <limits>
bool isSigned(mytype n)
{
return std::numeric_limits<mytype>::min() != 0;
}
Or:Code:return std::numeric_limits<mytype>::is_signed;
It does seem strange to use numeric_limits<T>::is_signed() for something other than a template, which is the only time I've ever used it.Quote:
Originally Posted by anon
It looks like it happens at runtime, but the compiler will probably optimize it out.Code:sometype test = 0;
if(test - 1 > test)
{
/* The type is unsigned */
}
That's undefined behavior.
How is it undefined behavior?
- test is a number set to zero.
- Subtracting one from test produces a value.
- If the value is larger than one (or underflows), then test is unsigned.
But as brewbuck pointed out, without being denoted as volatile or something, the block of code will most likely be removed by your optimized.
I've previously used:Code:if ((sometype)-1 < (sometype)0)
Code:template<typename T>
bool isSigned(const T)
{
return std::numeric_limits<T>::is_signed;
}
underflows are undefined behavior.Quote:
Originally Posted by master5001
this is probably the most simple (for both you and the compiler) to use as operations between constants are always optimised.Quote:
Originally Posted by iMalc
An integer must be negative, zero, or positive. Regardless of any undefined corners, this logical fact remains. It is clear that an unsigned type cannot hold a negative value. Thus the result, defined or not, must be either zero or some positive value.Quote:
Originally Posted by robwhit
So, change it slightly just to catch the bizarre corner case:
Whether the actual behavior of the underflow is defined or not doesn't enter into it. The only way this method could not work is if an unsigned variable could take on a negative value, which is a contradiction.Code:if(test - 1 >= test)
So you're just ignoring the fact that its ub? once it's ub, it doesn't matter what the laws of mathematics are. the program could do whatever it wanted.
Yes, I'm ignoring it.Quote:
Originally Posted by robwhit
EDIT: Here's why. Either the operation will result in a result, or it won't. In the first case, the result could not possibly be negative if the type is unsigned. In the second case, the program must have terminated abnormally (otherwise how could you not have gotten a result), which means the platform is ridiculous. So yes, I'm deliberately stepping into undefined territory, and I feel quite safe in doing so.
Does it still work when you're not on a platform using 2-complement??
It doesn't depend at all on how the integer is represented, just the fact that the subtraction will produce SOME result.Quote:
Originally Posted by KIBO
1) It's not UB. Underflow is defined for unsigned integers (wrap around), and there's no underflow for signed integers.
2) However, that doesn't mean you can ignore over/underflow for signed integers in general. There are platforms that trap on overflow. There may also be platforms that have an integer NaN they'd use for overflow results. And if that's the case, the claim that the subtraction will produce SOME result is, well, only half-true. Operations on NaNs usually have weird results.
can you give an example of a platform that will trap on overflowQuote:
Originally Posted by CornedBee
VAX with the IV status bit set.
http://h71000.www7.hp.com/doc/73fina...15pro_014.html
CLR in checked mode.
Short story:
It's impossible to truly determine that.
Wether singed or unsigned, the var is still meerly a specified amount of reserved memory. Being singed or unsigned only changes the behavior of the compiler's operations on that varible. That's all.
Can you direct me to the relevant section(s)? I'm having difficulty locating it.Quote:
Originally Posted by CornedBee
The behaviour is defined in in paragraph 2 of section 4.7 of the 2003 edition of the C++ Standard (ISO/IEC 14882:2003).Quote:
Can you direct me to the relevant section(s)? I'm having difficulty locating it.
Quote:
If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2 n where n is the number of bits used to represent the unsigned type). [Note: In a two's complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ]
Thanks laserlight.
Apologies, brewbuck.