Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
if(number == 0) {
//do something
}
Since zero evaluates to false in C++, if a number is zero it will be false in if condition.
how can I check if it is really a number zero?
There is a misconception, here: the if statement is not about the 0 constant or the value of number, but about the returned value of operator==.
The point is not if number or 0 are themselves equivalent to "false", but if == returns true or not. And it returns true if the operands have the same value.
As far integral types promotions work, the above assertion works for whatever pair of integral types.
If number is something else, then all relates to the convertibility towards a common type between number and int (since 0 is a n int) and to the "precision" the number value may have, or in the way operator== is implemented between the two types.
You can experience some trouble if number is a floating point. If this is your case, just compare with a reasonable small around of zero. Have a look at this article http://floating-point-gui.de/errors/comparison/ I'm sure you can better understand the problem.
Trivial example:
#define epsilon 0.0001;
if( fabs(number) < epsilon ){
....
}
choosing the correct epsilon could be tricky, depending on the application.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Found that logic on a code and don't get the reason behind that; why use it instead of assign normal int?
(its a character controller in a 3D environment)
// assumes we're not blocked
int blocked = 0x00;
if ( its_a_floor )
blocked |= 0x01;
if ( its_a_wall )
blocked |= 0x02;
0x00 is a "normal int". We are used to base 10 representations, but other than having 10 fingers in total, base 10 is not special. When you use an integer literal in code you can choose between decimal, octal, hexadecimal and binary representation (see here). Don't confuse the value with its representation. 0b01 is the same integers as 1. There is literally no difference in the value.
As a fun fact and to illustrate the above, consider that 0 is actually not a decimal literal. It is an octal literal. It doesn't really matter, because 0 has the same representation in any base.
As the code is using bit-wise operators it would be most convenient to use a binary literals. For example you can see easily that 0b0101 | 0b10101 equals 0b1111 and that 0b0101 & 0b1010 equals 0b0000. This isn't that obvious when using base 10 representations.
However, the code you posted does not use binary literals, but rather hexadecimal literals. This might be due to the fact that binary literals are only standard C++ since C++14, or because programmers used to bit wise operators are so used to hexadecmials, that they still use them rather than the binary.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
Consider the code:
#define LITERAL 1.0
int main()
{
double x = LITERAL;
if (x == LITERAL) return 1;
else return 0;
}
Is this guaranteed to return 1 for any numerical double value we set LITERAL (not just 1.0 but any other double literal)?
EDIT: Why was the question closed because of "missing details"? It is a well defined C/C++ question and got a very good answer. There are no more details required, it is a general question about how these languages work.
First, you have to assume an implementation that's (attempting to be) conforming to Annex F, since otherwise all bets are off; without Annex F (IEEE floating point) C allows all floating point results to be arbitrarily bogus.
Then, according to the language spec, depending on your C implementation's definition of FLT_EVAL_METHOD, yes or no.
If the value is 0 or 1, then yes. The literal is interpreted as double, and the double object stores that value faithfully, and the equality operator yields 1 (true), reflecting that.
If the value is 2, then only if the literal is the eact decimal representation of a representable double or is expressed with sufficient precision that it differs from one only past the precision of long double. Otherwise (for example if it's something like 0.1), since the literal is interpreted with excess precision in long double format the initialization/assignment to a double object truncates the precision to the nominal double precision. Then the equality comparison is guaranteed to result in 0 (false). You can see this in action on Compiler Explorer (note: remove the volatile and you can see it optimized to return a constant 0).
To make matters more complicated, GCC does this wrong by default unless you use -std=c.. or -fexcess-precision=standard, and always does it wrong in C++ mode, and clang/LLVM always do it wrong. So on a target with excess precision (32-bit x86 or m68k, the only real-world-relevant targets with FLT_EVAL_METHOD not 0 or 1) horrible things happen. For a peek into how bad they get, see GCC issue 93806 and (recursively) all of the "See Also" related issues.
So for practical purposes, yes, for everything but 32-bit x86 and m68k, and in a correct C implementation no (but maybe yes, because your compiler is probably broken) for them.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
My WIN32 (C++) code has a UINT lets call it number.
The value of this UINT (or INT doesn't matter) start with a 0 and is recognized as an octal value. It's possible to use the standart operators and the value will keep the octal-system. The same is possible with hex (with foregoing 0x).
The problem is I have to use the Value of number in a buffer to calculate with it without changing the value of number. I can assign a value like 07777 to buffer on declaration line but if use an operation like buffer = number the value in buffer is recognized on decimal base.
Anybody has a solution for me?
There's no such thing in C as an "octal value". Integers are stored in binary.
For example, these three constants:
10
012
0xA
all have exactly the same type and value. They're just different notations -- and the difference exists only in your source code, not at run time. Assigning an octal constant to a variable doesn't make the variable octal.
For example, this:
int n = 012;
stores the value ten in n. You can print that value in any of several formats:
printf("%d\n", n);
printf("0%o\n", n);
printf("0x%x\n", n);
In all three cases, the stored value is converted to a human-readable sequence of characters, in decimal, octal, or hexadecimal.
Anybody has a solution for me?
No, because there is no actual problem.
(Credit goes to juanchopanza for mentioning this in a comment.)
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
How can I add a scientific and a float number ? I have something like
var1 0.99999899 var2 3.5008552e-05 sum 3.5008552e-05
but what I dont understand is why in the first place var2 is shown as scientific while in the first place I declared
double var1, var2;
so, actually their sum is just var2...
thanks
a
The way a floating-point value is displayed is down to the mechanism by which you display it. It is not a property of the value itself, nor is it in any way stored within the variable:
A number is a number is a number. What you call "scientific" is not a class of numbers. It's a class of representations of numbers. The same way that "twelve" and "12" and "XII" and "a dozen" and "IIIIIIIIIIII" all represent the same number. This "scientific" thing only exists when you decide to represent the number in some specific way (i.e. when you output it). Calculations don't "turn numbers into scientific" the same way that saying that "2 * 6 is twelve" doesn't turn numbers into English words. The variables always store the numbers not the representations. — R. Martinho Fernandes
Your display mechanism — std::cout? — is choosing the best way to output the value. You can override this with IO manipulators such as std::fixed, though it's pretty fiddly sometimes to get it just how you want it, due to library limitations.
If you have <stdio.h> available then you may use int printf ( const char * format, ... ); the format specifier would look something like this: printf("%.5f", your_double) where 5 is the number of digits you want after the decimal point, the default is 6.
(printf docs)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions must demonstrate a minimal understanding of the problem being solved. Tell us what you've tried to do, why it didn't work, and how it should work. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
This is what I tried:
int i=-1,size=1;
while (i>>1)
size++;
printf("%d",size);
The goal is to determine the size of int without using the sizeof operator.
The above loop turns out to be infinite. Is there a way to fix it so it does what it is intended to do?
Just use unsigned for i, rather than int. They are
guaranteed to have the same size, and right shift of a signed integer is implementation defined (but will usually shift in the sign bit). And don't forget to divide
the results by CHAR_BIT (which is not guaranteed to be 8).
You have chosen a negative number for right-shifting.
Right shifting a negative number, it gets filled with the sign bit 1 (or not, depending on implementation), so your value can never be 0 (=false), which means you get precisely the infinite loop you are complaining about.
your loop is indeed infinite.
start from i = 1 and shift it left till you reach i =0 and stop. you have the bits.
-edit---
this will work for signed as well as unsigned integer alike.