Re: Moving from C++ to VC++

Doug Harrison [MVP] <dsh@xxxxxxxx> wrote:
> 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. [...]

'long' being 32bits wasn't guaranteed earlier,
so it isn't needed for backwards compatibility.

> 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.

Of course, it's not required to be 64bit.
However, I would expect that at least the
biggest of the std integer type would use the
native integer size of the underlying hardware.
(Actually, I would even expect 'int' to be
this.)

> [...]
> I guess you're more a purist than the rest of us. [...]

Why? Because I raised the question how long
we're going to sit on 32bit because of
compatibility with code that should have
never been written to need this?
If compiler writers would always have
taken broken code into account, we would
probably still sit on 8bit 'int'.

> >>> (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, [...]

No, there isnt'. If I need "rather small
integers" only, I'll still use it for
certain definitions of "rather small".
(Like in the range -100 < x < 100.) If I
need 32bits, I can use 'int32_t'.

> [...] 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?

Because now I have to use '__int64'?

> 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.

Right. That's why I don'T use it for this.

> 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.


I don't know if our code runs on 16bit. (And
I don't care. I don't think any of our code
will ever be ported to a 16bit platform.) If
this should ever become a problem, I expect
the usual amount of work necessary for porting
to a platform with uncommon characteristics:
It dips your nose right into the places where
you've made stupid assumptions. Usually, the
code is better after you ported it.

Schobi

--
SpamTrap@xxxxxx is never read
I'm Schobi at suespammers dot org

"Coming back to where you started is not the same as never leaving"
Terry Pratchett


.

Relevant Pages

  • Re: Puzzling program
    ... platform, and don't care about portability". ... ', use 'int main', use unsigned int rather than int, ...
    (comp.lang.c)
  • Re: Boost process and C
    ... Using size_t is also not any more *portable* than using int. ... of portability is merely a reflection of the lack of the intrinsic ... I've gotten plenty of feedback over its lifetime which has ... "Cursed with non-portabilities" indeed ... ...
    (comp.lang.c)
  • Re: Basic questions
    ... The compiler is allowed to insert padding bits wherever it likes ... > As 16 is an int, what you wrote is equivalent to ... if the OP uses 'unsigned short' only to store 16-bit numbers (writing ... values, so they're not a panacea for portability, and they might trick ...
    (alt.comp.lang.learn.c-cpp)
  • Re: C99 exact width integers usage - informal survey
    ... so you can write perfectly portable code (assuming ANSI ... yes and no on the portability issue. ... types int and unsigned int. ... That's why the exact sized int types are not required in C99 unless ...
    (comp.arch.embedded)
  • 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)