On Sun, 07 Mar 2010 14:59:50 Kai Tietz wrote: > 2010/3/7 Doug Semler <[email protected]>: > > On Thu, 04 Mar 2010 17:20:07 Jim Michaels wrote: > >> in MSVC, > >> __int64 x=12345678901234567i64; > >> > >> point 1: this type __int64 doesn't require me to #include <windows> to > >> define it. in mingw and mingw-w64, one must #include <basetsd.h>. why? > >> > >> point 2: there are also __int32 __int16 and __int8 types. > > > > If I remember correctly, anything that starts with two underscores is > > implementation defined, which means that __int64 is MS compiler specific, > > so including a separate header would make sense to pick it up in mingw > > > > Since this is a compiler specific (not really mingw but gcc), it makes > > sense to me, in fact IIRC, MSDN specifically states "Microsoft Visual C > > Specific" for those types. If you need to be able to compile under > > multiple compilers, I would say grab a MS version of stdint.h (since > > MSVC doesn't have that) and #include that, and use the types from there > > (such as int64_t, int32_t, etc). If you just need a type that is at > > least 64 bits I believe MSVC from 6.0 on supports "long long" and > > "unsigned long long" (at least 64 but could be longer) > > Right, keywords/symbols with two leading underscores are extensions. > The support of '__int8, __int16, __int32, __int64, and __int128' are > builtin types. As the are combinable by 'signed/unsigned' they can be > handled by typedefs. So we use for them at the moment defines in our > headers, but of course this is just a work-a-round. The type __int128 > will be added to gcc's version 4.6 (a patch for it is already posted > but needs review). I would like to have those other extension types > supported by VC, too, but well, as those types aren't part of any > C-specification, it is a bit hard to put them into gcc. > > The digit post-fixes 'i32,i64,i128, etc' are alse MS specific > extensions (AFAIR long long type was introduced by MS beginning from > VC 2005). It would be possible to add these to gcc (in fact it is > mainly preprocessor feature), but again here is again the question, if > this fits into any specific standards gcc wants to support. >
You're probably right - I can't keep track of them all :) In addition I think that the 64 bit long long may not be available unless compiling the code as C++ under 2005. Personally I think MS should "fix" their compiler to be more compliant to C9X (inttypes.h comes to mind) than adding MS extensions to GCC... The main question I have is to the original poster: if you are compiling under gcc/mingw, why the concern about MS specific extensions; since you would no longer be using them unless you need to be able to continue to compile under the MS compiler as well? I mean, if you have to change the code anyway (to include the mingw specific headers to grab these definitions), why not change the code to be portable anyway? ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
