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 <[email protected]>
To: [email protected]
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 <[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
------------------------------------------------------------------------------
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
