Re: Is __int64 dead?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

On Mon, 27 Aug 2007 12:35:14 +0100, Daniel James
<wastebasket@xxxxxxxxxxxxxxxx> wrote:

If you use long long that's one reserved word (used twice), if you use
longlong you're adding a whole new reserved word to the language ... which
is generally regarded as a bad idea. Doubling up the long keyword is
simple, easy to understand, and has been around as an idea for almost forty
years (since Algol-68).

I never liked the idea of codifying a classic typo...

I just wish it was arbitrarily extensible ... if I actually wanted a
1024-bit integer I would really like to be able to write long long long
long long long int and have the compiler generate the right code to handle
it (optimally and efficiently).

I think it would be a lot better to use int<1024> or something like that. I
mean, do you really want to be asking yourself what the difference is
between "long long long long int" and "long long long long long int"?

Note also that while the compiler can implement native types efficiently,
it probably can't do much better than existing bignum libraries for
arbitrary precision. The main advantage I see to having the compiler do it
is defining a standard syntax for it.

And INT_PTR so called because it is the size of a pointer... I mean that
makes sense to the people who designed it, but not the users of it.

It makes very little sense to anyone on an architecture on which pointers
to different types of things have different sizes.

Well, all pointers are convertible to void*, so make INT_PTR an integer
type large enough to hold a void*, and you're done. (Of course, you need
such an integer type, and in the Windows LLP64 model, the compiler needs to
implement "long long", else it lacks a fundamental type for this or even to
implement size_t. I don't know what the 64-bit VC does... It probably
dodges the size_t issue by making it a native type, which is what the
32-bit VC does, and it may use __int64 for INT_PTR, which is fine.)

--
Doug Harrison
Visual C++ MVP
.

Relevant Pages

  • Re: Garbage collection
    ... void fn{ ... void* const buf1 = malloc; ... If compiler can detect that 'fne' does not cache a pointer somewhere, it can possibly detect that 'buf1' goes out of scope at 'L2'. ... Some GC implementations that will actually scan the stack of all application threads for pointers into its managed heaps, and attempt to follow all the links to NULL. ...
    (comp.lang.c)
  • Re: Scheme and libraries -- piggyback on Java?
    ... pointers to be assigned to other pointer types without casting. ... I suppose I did know at one time that void* was convertible without ... I also just realized that I haven't used an actual C compiler since ...
    (comp.lang.scheme)
  • Re: Is __int64 dead?
    ... portability after a year, and still suffered serious problems in the 32/36 bit world. ... Note also that while the compiler can implement native types efficiently, ... Well, all pointers are convertible to void*, so make INT_PTR an integer ...
    (microsoft.public.vc.mfc)
  • Re: Seeting malloc pointer to NULL [2] -Totally confused!!!!!
    ... Best regards ... So now that I have gotten it to work in the VC++ compiler, ... mayby my compiler doesn't support pointers to pointers! ... from void* to other pointer types. ...
    (microsoft.public.vc.language)
  • Re: /DELAYLOAD Linux counterpart for shared objects
    ... A big disadvantage is that the compiler, ... pointers and makes sure the library is there). ... void, ... ub2 charset, ub2 ncharset); ...
    (comp.os.linux.development.apps)