Re: Moving from C++ to VC++

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Thu, 16 Jun 2005 13:54:32 +0200, Hendrik Schober wrote:

> Doug Harrison [MVP] <dsh@xxxxxxxx> wrote:
>> On Wed, 15 Jun 2005 16:56:24 +0200, Hendrik Schober wrote:
>>> Doug Harrison [MVP] <dsh@xxxxxxxx> wrote:
>>>> On Tue, 14 Jun 2005 12:06:19 +0200, Hendrik Schober wrote:
>>>>> So which type would you suggest using for
>>>>> "longest integer"?
>>>>> (May I suggest 'long int'? <g> )
>>>>
>>>> So on IA8192, all programs that use long would use 8,192 bit integers?
>>>
>>> Why not? If it is the longest integer.
>>
>> Because it imposes insane storage requirements on people who used long back
>> in the day when it made at least some sense to use it, i.e. when ints were
>> only 16 bits, and long was its guaranteed minimum 32 bits.
>
> I have no idea what you're trying to say.

It's pretty simple. Reading ahead to the next sentence I wrote, which you
did quote below, I mentioned fseek. Even with 16 bit machines, it would
have been bad to constrain fseek to 16 bit int offsets, so they used long,
which guarantees at least 32 bits. Unfortunately, in avoiding one mistake,
they made another by hijacking long for the purpose of defining an integer
file offset that should have been a typedef dedicated to that purpose. You
can be assured that if the people who wrote the C Standard misused long in
this way, there are many others who did, too. For that matter, there's a
ton of code that assumes an int can index any array, or hold a pointer,
etc. These are all manifestations of the same fundamental mistake. FWIW, I
think it's more controversial to leave int 32 bits on a 64 bit platform,
but that's the way most 64 bit Unixes have gone, as well as Win64.

Now, using 8192 bits to store file positions is clearly nuts, but that and
more nutty situations are what you would get were you to mindlessly make
long the "longest integer". What I think you don't recognize is that an
8192 bit integer type is a very special type that is mind-boggling overkill
for a standard type like long, that carries with it undesirable
side-effects, one of which I talked about later in my previous message.
Even a 256 bit long strains the limits of physical reality as it relates to
things like file positions.

> If I want the longest integer type on the
> platform, I want the longest integer type
> on the platform. f course, that would very
> rarely help me to save space. Such is the
> tradeoff.

So, "longest integer type on the platform" is a virtue in and of itself?
Explain that. In addition, it might help me to understand what your
criteria are for choosing long vs int.

>> Would you really
>> like to see fseek take an offset value that's 8,192 bits?
>
> How else would I be able to access files
> 2^8192 bytes big?

Visit a different universe? (It may sound like it, but that's not sarcasm.)

>> Suppose int were to remain 32 bits on IA8192, and pointers were 64 bits,
>> and size_t were 64 bits, and so forth. (Maybe the fictional IA8192 has
>> super-wide registers to speed up certain algorithms, but its address space
>> remains mired in reality.) Why would you want to make "long" so insanely
>> large?
>
> Now /I/ would like to have 'int' being the
> native integer type on the machine (64bit,
> I assume), and long being at least as big.

This is all very inconsistent. Throughout this thread, you've been equating
"long" with "longest possible integer", yet in another message, you were
ready to accept "long long" as the new "long", relegating poor old "long"
to just a somewhat longish integer. In this message, after saying the 8192
bit long is what you want on IA8192 by virtue of it being the longest
possible integer, now you're ready to accept a long that's merely at least
as big as int, the latter of course being what long means already (plus
long has 32 bit minimum size).

In my very first message here, I said, "The main argument for int
reflecting the "native" word size has been efficiency. Anyone know how well
these 64 bit CPUs implement 32 bit data types?" Bo Persson replied, "On the
x64 hardware, 32 bit int *is* the natural size. You need a size override
code to operate on 64 bit data." So, shouldn't you be happy with the Win64
model? It does satisfy the conditions you laid out above.

>> Consider these two programs:
>>
>> 1. Developed for 16 bit ints, 32 bit longs, portably does 32-bit stuff on
>> longs.
>>
>> 2. Developed for 32 bit ints, 32 bit longs, non-portably does 32-bit stuff
>> on ints and doesn't use long at all. (Practically speaking, it's portable
>> to 32 bits and beyond.)
>> [...]

I wrote (1) and (2) above to set something up, so let me restore the part
you clipped:

>> Now (2) can't be affected very much if long changes, because it doesn't use
>> it, but (1) is held hostage to your ever-increasing sizeof(long). Consider
>> arrays of long allocated by (1) vs arrays of int allocated by (2).
>> Everything else held constant, (1) finds itself using 256 times the amount
>> of memory it was using on the old machine, and 256 times the amount of
>> memory (2) is using on the new machine, all for no good reason.
>
> I see 'short', 'int', and 'long' as "small
> integer", "fast integer", and "big integer",
> respectively.

The point was, it makes no sense to mindlessly grow long to be the "longest
possible integer type". It is far from certain this will be a beneficial
change.

As for your characterization, when I think about those types, int is the
default integer type. When I've determined int is inadequate for my
intended use, I think sizeof(short) <= sizeof(int) <= sizeof(long), with
the emphasis on the == parts. In fact, the vast majority of systems today
have sizeof(int) == sizeof(long). So unless you write all your code as if
int were 16 bits, what you think about long is incorrect.

> If anyone really needed a 32bit
> integer, they should define one and hunt for
> that define when porting. Or lobby for an
> 'int32_t'.
> What's wrong about this?

Nothing. If you need an exact size, you should write a typedef for it. If
you need a stronger guarantee than "at least 32 bits, at least as big as
int", then you shouldn't use long directly, unless you want your code to be
even more non-portable.

Note also that if you're writing for a 32 bit or greater machine, and I
think you are, since you said earlier you don't know or care if your code
runs on 16 bit machines, int provides all the guarantees long provides! So
what good is long? You could only take advantage of it if you knew it were
bigger than int, but to do so would heap more non-portability on top of
your assumptions about int. So the best approach is not to use long
directly, but only as a basis for typedefs that make stronger, useful
guarantees. And since a compiler for a 64 bit machine is certain to provide
a 64 bit integer type of some sort, why do you care if it's spelled "long"?
It just doesn't seem like that big a deal to me, but then again, I don't
use long except in the limited ways I've already talked about.

>> Concerning int, my view is that unless told otherwise, it's at least 32
>> bits. [...]
>
> And AFIK that's not ocrrect according to the
> C and C++ standards.

Please... See my reply to Alexander.

>>> If it has to be as long as possible, I use
>>> 'long'. For many things, this is good enough.
>>
>> Unfortunately, that's not what long means, at least not anymore.
>
> So you agree that what's done now, breaks the
> traditional meaning of 'long'?
> I don't think I have a problem with
> 'sizeof(long) < sizeof(size_t)'.

Oh well, that's the thing C99 allows to be violated. It was with this in
mind that I responded to your "as long as possible" notion. That unsigned
long can hold size_t is what I consider part of the "traditional meaning of
long". It's mildly disturbing that this no longer holds.

>If I need a 'size_t', I don't use 'long'.

In the very first message I posted here, I gave an example of a common
idiom involving an interface that supports long but not size_t. Here's the
start of another discussion about this:

http://groups-beta.google.com/group/comp.std.c/msg/43d3480ef815f22c?hl=en

>> Things
>> like intptr_t, int64_t, int_least64_t, etc make for a far firmer foundation
>> that the short/long mess inherited from a portable assembly language
>> designed 35 years ago, when hardware was weirder, scarcer, less capable,
>> and more expensive. [...]
>
> They have a different meaning that 'long'.

Yes, they do, from both the perspective of the standards and your own
personal definition of long.

> Frankly, I have no idea what 'intptr_t' should
> be used for, so I assume it's for storing
> pointers in an 'int'. (I assume this because
> it correlates with the fact that I have no
> idea why one would want to do that.)

Storing pointers in an integer is common enough that the C++ Standard
formalized it with reinterpret_cast, and C99 introduced a type that
guarantees such an integer type exists. (C++ doesn't make that guarantee,
but I don't know of any implementation that doesn't provide some integer
type, possibly non-standard, that can hold a pointer.) An example would be
an OS-level data structure that can store a pointer-sized piece of data for
your later use, say, in a callback. It's somewhat conventional to use an
integer type for this purpose, because often the user wants to store
integers, not pointers, and why not cater to the more common usage?

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

Relevant Pages

  • Re: Bit-fields and integral promotion
    ... >> The standard very clearly intends to specify the behaviour. ... > whether declared as int or unsigned int, ... "A bit-field is interpreted as a signed or unsigned integer type ... any signed integer type with less precision." ...
    (comp.lang.c)
  • Re: Learning C with Older books ?.
    ... So the widest integer type supported by the implementation works. ... Alternatively you can cast to a type such as int. ... other parts of the code (e.g. index variables) require that the size ... than the positive range of the corresponding signed type (not just approx. ...
    (comp.lang.c)
  • Re: Learning C with Older books ?.
    ... So the widest integer type supported by the implementation works. ... Alternatively you can cast to a type such as int. ... other parts of the code (e.g. index variables) require that the size ... than the positive range of the corresponding signed type (not just approx. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Implicit int
    ... a wider standard type due size of data objects.to the ever-increasing ... If a 64 bit integer type is desired we can have as int64_t as exact ... in this case where we don't have long long int. ... C99 has two parallel sets of integer types. ...
    (comp.std.c)
  • Re: printf() behavior
    ... Any pointer type may be converted to an integer type. ... b is an int and therefore does not hold any ... Only pointers hold addresses. ... Since the conversion from ...
    (comp.lang.c)