Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC
sorry, yahoo mail will only let me top-post. I was the OP. personally, my preference is to write my code in as platform-independent and compiler-independent a way as possible. which usually means a 3-5 ifdefs per snippet of code. the older msvc6 (which is what I have as a default) does not recognize long long. so I usually end up making a types.h as a common base for number types, since DJGPP doesn't define DWORD, etc. I suppose I would have called it inttypes.h, but I suppose it's a good thing I didn't. but if I ever have to compile something from somebody else made for msvc, I would like to be able to compile it with mingw-w64 with as little modification as possible. usually *that* means several includes beyond the given windows.h because the mingw headers are not written in a way that includes the other headers automatically (such as winuser.h). I don't know how microsoft does it. with regards to inttypes.h vs basetsd.h, it would be nice if both mingw and mingw-w64 would BOTH support these, or at least a subset if 128-bit is not going to be supported. I suppose an __int128 VS2010 is in beta2 right now. it would be interesting to see if they have the __int128 or int128 type from C9X. I will also mention that in future versions of C++ (C9X?) is possibly coming garbage collection, and a lot of advanced stuff that is over my head. just take a look at some of the videos on the net. I think they are on youtube. some of them hosted by Bjarne Stroustrup. what is happening is C++ is gaining features that insulate it from pointer dangers, and also allow easier assignments for STL collections (concerning assigning an array or list or vector). So the STL is getting an overhaul in the future. Side issue: shame that the msvc (and subsequently mingw) does a #define MAXIMUM_PROCESSORS 32 it seems these days that limits are meant to be broken, and the compiler limit there is about to be broken sometime soon I should think... it's already up to 8 with the intel i7. :-) I'm watching to see what Microsoft does. I suppose they will fix it AFTER somebody comes out with such a processor. :-( If there's a limit, somebody is going to push it. From: Doug Semler dougsem...@gmail.com To: mingw-w64-public@lists.sourceforge.net Sent: Sun, March 7, 2010 12:26:46 PM Subject: Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC On Sun, 07 Mar 2010 14:59:50 Kai Tietz wrote: 2010/3/7 Doug Semler dougsem...@gmail.com: 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
Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC
shame that the msvc (and subsequently mingw) does a #define MAXIMUM_PROCESSORS 32 it seems these days that limits are meant to be broken, That #define certainly does not mean that code built with mingw (or msvc) would be limited to running threads on a maximum of 32 concurrent processors, if that is what you think... As far as I can see, that value is just a magic value to the SetThreadIdleProcessor() function, it has no other meaning. So the only thing it limits is that you can't set the preferred processor of a thread to be processor number 32, but you can set it to be any of processors 0..31 and 33..n . Hardly that significant. And actually, the docs for SetThreadIdealProcessor() says: On a system with more than 64 processors, this function sets the preferred processor to a logical processor in the processor group to which the calling thread is assigned. Use the SetThreadIdealProcessorEx function to specify a processor group and preferred processor. limit there is about to be broken sometime soon I should think... it's already up to 8 with the intel i7. :-) There has been (quite expensive and thus quite rare) machines running Windows with many more processors than 8 long before there were x86 *chips* with multiple *cores*. Don't confuse cores with processors. Multiple processors is a much older concept than multiple cores. --tml -- Download Intel#174; 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC
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) point 3: mingw does not utilize the i64 constant thingy (whatever it's called) that tells the compiler that this number is of __int64 type. I do not know if there is an i32 or i16 or i8 definition. That's another GCC, not mingw thing. GCC supports the suffix of LL and ULL for 64 bit wide numbers. MSVC from at least visual studio 2003 (maybe, but don't quote me, VC6) also supports these... BTW, 128-bit number type is in the C9X standard. the new integral data types in C++ will be something like int64, int32, int128, int16, int8. http://www.open-std.org/JTC1/sc22/wg14/www/docs/n615.htm C9X support in MSVC is flaky at best and nonexistent in several spots (see: stdint.h). I mean the standard has been ratified since what, 2004? even VS 2008 doesn't have it!) -- Download Intel#174; 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC
2010/3/7 Doug Semler dougsem...@gmail.com: 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. point 3: mingw does not utilize the i64 constant thingy (whatever it's called) that tells the compiler that this number is of __int64 type. I do not know if there is an i32 or i16 or i8 definition. That's another GCC, not mingw thing. GCC supports the suffix of LL and ULL for 64 bit wide numbers. MSVC from at least visual studio 2003 (maybe, but don't quote me, VC6) also supports these... BTW, 128-bit number type is in the C9X standard. the new integral data types in C++ will be something like int64, int32, int128, int16, int8. http://www.open-std.org/JTC1/sc22/wg14/www/docs/n615.htm C9X support in MSVC is flaky at best and nonexistent in several spots (see: stdint.h). I mean the standard has been ratified since what, 2004? even VS 2008 doesn't have it!) -- Download Intel#174; 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Download Intel#174; 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC
On Sun, 07 Mar 2010 14:59:50 Kai Tietz wrote: 2010/3/7 Doug Semler dougsem...@gmail.com: 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#174; 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] __int64 issue of compatibility with MSVC
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. point 3: mingw does not utilize the i64 constant thingy (whatever it's called) that tells the compiler that this number is of __int64 type. I do not know if there is an i32 or i16 or i8 definition. BTW, 128-bit number type is in the C9X standard. the new integral data types in C++ will be something like int64, int32, int128, int16, int8. http://www.open-std.org/JTC1/sc22/wg14/www/docs/n615.htm Jim Michaels jmich...@yahoo.com(main) JesusnJim.com (my site) DoLifeComputers.JesusnJim.com (Do Life Computers group site which I lead) while (stone != rolling) moss++; --- Computer memory/disk size measurements: [KB KiB] [MB MiB] [GB GiB] [TB TiB] [10^3B=1000B=1KB][10^6B=100B=1MB][10^9B=10B=1GB][10^12B=1B=1TB] [2^10B=1024B=1KiB][2^20B=1048576B=1MiB][2^30B=1073741824B=1GiB][2^40B=1099511627776B=1TiB] Note that with disks, a disk size is measured in GB or TB, not in GiB or TiB. computer memory (RAM) is measured in MiB and GiB. --- Robot dog food: Cables n' Bits --- adress=seg4+ofs; (ambiguity - a double-minded compiler is unstable in all its ways) biosdsk2.h:733: warning: suggest parentheses around '+' inside '' --- -- Download Intel#174; 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC
On Fri, Mar 5, 2010 at 12:20 AM, Jim Michaels jmich...@yahoo.com 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? It is enough, I guess.. Include windows.h if you want, why is that a problem? point 2: there are also __int32 __int16 and __int8 types. MinGW has them all of as macros, because : - gcc doesn't have native support for them - and for some compatibility issues. point 3: mingw does not utilize the i64 constant thingy (whatever it's called) that tells the compiler that this number is of __int64 type. I do not know if there is an i32 or i16 or i8 definition. Not mingw, but GCC doesn't support those suffixes. I suggest: #include stdint.h __int64 x=INT64_C(12345678901234567); Yeah, msvc doesn't have stdint.h, inttypes.h, but you can get msvc-compatible versions of them from http://msinttypes.googlecode.com/ BTW, 128-bit number type is in the C9X standard. the new integral data types in C++ will be something like int64, int32, int128, int16, int8. http://www.open-std.org/JTC1/sc22/wg14/www/docs/n615.htm Hmm, mingw-w64 has an __int128 as a typedef. If it goes as planned, gcc-4.6 will have that natively in future. Jim Michaels jmich...@yahoo.com(main) -- Ozkan -- Download Intel#174; 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
