Hello,
When i was playing with ULLONG_MAX, i wrote following code.
Since the sizeof produces 8, i think the 1st printf statement should produce 2^64-1 instead of 2^32-1(I'm using Dev-Cpp on win32). Could anyone hint on this?Code:#include <stdio.h> #include <limits.h> int main() { unsigned long long a = ULLONG_MAX; printf("%llu\n",a); //outputs 4294967295 printf("%d",sizeof(unsigned long long)); //outputs 8 return 0; }
Thanks in advance.
My guess is that the code you fed to your compiler differs from what you've shown (in practice, although bugs exist with compilers and standard headers, it is better to look for errors by programmers before blaming the implementation). If you used a format specifier that doesn't match the type of the value of your variable a, then truncation of the value (to 32 bits) is one possible result.
Thank you grumpy for your reply.
I just copied the code from the editor to the board and added the comments. I think they are the same.
For the format specifier i used %llu for unsigned long long, do you think there is some problem?
Is this on Windows? If so, use %I64u to print long long. If it's Unix, I'd expect your header files aren't matching the compiler for some reason.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Thanks a lot matsp.
Your method %I64u produces correct result. But i just don't get it why %llu doesn't work. I've actually seen this usage somewhere...
%llu is the C99 standard way of doing it. Unfortunately, gcc-mingw uses the MS Libraries, which aren't C99-compliant (but gcc itself is). To work around that problem, mingw would either have to modify th existing libraries - hard and probably illegal, or provide their own libriaries - harder, but definitely legal. Both solutions also provide a distribution problem - you'd have to distribute the produced C library.Originally Posted by vincent01910
It's just one of those things you have to get used to.
Although there is a macro you can use, see post 8:
http://www.linuxquestions.org/questi...ng-int-274423/
--
Mats
Last edited by matsp; 05-05-2009 at 06:12 AM.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
vincent01910, along with the excellent responses I'd like to point out, too, that this is one good reason to reevaluate our long love/hate relationship with the printf family.
The Boost library has a very good alternative to printf which solves this problem, and after some initial resistance I've come to agree with their solution.
This may not help a student who should learn printf's many irksome faults, but I think it's worth an extracurricular study.
One of those things...
Now i totally understand. Thank you indeed for your detailed explanation, Mats, really helpful.
Although i don't quite get the picture of the Boost library you're talking about, but i will give it a try when i’m no longer a newbie...
Does that work in C? I'm not very familiar with Boost, but I always considered it a C++ only tool...
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Boost is very much a C++ only tool. I am curious to know how one would implement Boost.Format in C. If the format specifier does not include type information, how can you know what to format it as, given the lack of function (and operator) overloading?
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Lots of macros and some function pointers?[No, not a serious comment - I have no intention of even trying that - printf is good enough for most things, and if you want to do it differently, then there are plenty better ways than trying to implement Boost format in C].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
