Code:sprintf(val, "%llu", (long long)top << 32 | bottom);
Code:sprintf(val, "%llu", (long long)top << 32 | bottom);
A type cast does not allocate memory for any type of variable.Originally Posted by nonoob
Learn C++ (C++ Books, C Books, FAQ, Forum Search)
Code painter latest version on sourceforge DOWNLOAD NOW!
Download FSB Data Integrity Tester.
Siavosh K C
What are you getting at, exactly? The example should work according to what the OP wants.
What type of variable, do you think, will be put on the stack?
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
I didn't mean that (dynamic allocation). Stack memory is also allocated.What type of variable, do you think, will be put on the stack?
Learn C++ (C++ Books, C Books, FAQ, Forum Search)
Code painter latest version on sourceforge DOWNLOAD NOW!
Download FSB Data Integrity Tester.
Siavosh K C
it's MY point...
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
I don't understand your objection to my solution. I rarely post code snippets without actually testing it in a compiled and run program for correctness. The above cast is fine and does exactly what is needed.
Sorry, I think I was wrong.
Are you sure it will work with any compiler?
Learn C++ (C++ Books, C Books, FAQ, Forum Search)
Code painter latest version on sourceforge DOWNLOAD NOW!
Download FSB Data Integrity Tester.
Siavosh K C
I think it is safe to say that it is quite certain.
Yep! because behind-the-scenes, it uses a 64-bit scratch register/variable to save (long long) top before it's stringified and saved to char val[].
Last edited by itCbitC; 04-07-2010 at 11:22 AM.
Still not sure about what the concern is. If the compiler supports 64-bit integers, then it is allowable to push such a data type on the stack. sprintf's "%lld" will retrieve that sized value properly.
I expected more of an objection about neglecting to cast bottom as well. I figured the compiler promotes its type automatically to match the largest type so far - the one to the left of the binary 'or' operator. Else I would have seen a warning about incompatible types.
It will promote bottom.
If there are multiple sizes in an expression, the compiler will implicitly convert all of them to the biggest size in the expression.
