Re: Moving from C++ to VC++

On Fri, 10 Jun 2005 10:20:34 +0200, Hendrik Schober wrote:

>> Portable code can't assume long is larger than 32 bits. If you care about
>> anything beyond the minimum sizes, you have no business using the native
>> types.
>
> By the same resoning, it can't assume 'long' to
> be 32bits. Yet this was named as the reason for
> 'long' being 32bits on a 64bits platform.

The 32 bit long choice for Win64 was a consideration for backward
compatibility, not some abstract notion of portability. My comment was
directed to purists who don't care about invalidating existing code.
Clearly, such a person shouldn't care what size long is, as long as it
satisfies the requirements for long. In the message I replied to, you
pretty much conceded that 32 bits were OK, but then you went on to say that
you "don't see any excuse for not making 'long' 64bit on a 64bit platform."
When I put on my purist cap, if I accept 32 bit ints, I don't see any
particular reason to _make_ long 64 bits on a 64 bit platform, because a 32
bit long is all that's required.

> I don't think I have ever assumed anything about
> any of the integer type except for small (100LOC)
> toy programs. (I might have accidently done this,
> but then I'd be happy to have my nose pointed at
> it.)
>
> I haven't done any of those either.
>
> Maybe that's because I started to work for a
> company where all code gets ported to a couple
> of platform shortly after starting to work in
> this field at all. That teaches a lot about
> what you can assume and what you can't.

I guess you're more a purist than the rest of us. Or at least you think you
are. :) Statements like this one from your last post make me wonder:

>>> (Even though I would prefer 'int' to be the
>>> native integer type of the platform. If you need
>>> less than that, use 'short' or 'int32_t' or
>>> whatever.)

There's no guarantee short is smaller than int, and we're back to what I
said about portable code and minimum sizes. Not to mention, your "no
excuse" comment about 64 bit longs suggests you might use it non-portably
if it were available to you. I mean, if you're such a portable guy, why
would you even care about this?

There are many subtle ways non-portable assumptions creep into code. Here's
one. In your 32 bit programming, if you've ever used int to represent a
size, index, or anything having to do with capacity in a data structure,
loop index, etc, and your users can reasonably expect to work with data
sets containing more than 32,767 items, you might have been non-portable.
Here's another. If you've ever written code that cannot work in a 16 bit
(non-VM) address space, perhaps due to large auxiliary data structures it
needs to function, you might have been non-portable.

--
Doug Harrison
Microsoft MVP - Visual C++
.

Relevant Pages

  • Re: Moving from C++ to VC++
    ... If you care about ... not some abstract notion of portability. ... probably still sit on 8bit 'int'. ... > size, index, or anything having to do with capacity in a data structure, ...
    (microsoft.public.vc.language)
  • Re: somebody dropped a (warning) bomb
    ... But THE CALLER CANNOT AND MUST NOT CARE! ... warning sounds obviously insane. ... because with another compiler, or with the *same* compiler on another ... Make even "int" arguments (which ...
    (Linux-Kernel)
  • Re: somebody dropped a (warning) bomb
    ... But THE CALLER CANNOT AND MUST NOT CARE! ... Because the sign of "char" is ... warning sounds obviously insane. ... Make even "int" arguments (which ...
    (Linux-Kernel)
  • Re: Alternative COBOL "telco" source program
    ... >> like anyone can't duplicate this code if you've got a conformant ... >> compiler. ... >> int main{ ... >> Anyone care to try this in SNOBOL? ...
    (comp.lang.cobol)
  • Re: Delay Routine: Fully-portable C89 if possible
    ... Perhaps you were on about "long long unsigned int"? ... If the compiler doesn't accept ... then it isn't a C89 compiler. ... Since the OP was asking for portable code in an embedded newsgroup, there's no way he can make assumptions about the size of "int". ...
    (comp.arch.embedded)