Re: Question about NSRange on the G5 and the future sizeof(int).
Re: Question about NSRange on the G5 and the future sizeof(int).
- Subject: Re: Question about NSRange on the G5 and the future sizeof(int).
- From: Sherm Pendley <email@hidden>
- Date: Sun, 13 Jul 2003 13:56:02 -0400
On Sunday, July 13, 2003, at 10:36, James Quick wrote:
In both Panther and Jaguar, the NSRange structure elements, 'location'
and 'length',
are of type unsigned int. I am considering the use of NSRange to
build a
database of locations in a runtime image of an executable. On G3 and
G4
architectures this will be correct. What about the G5? Will an
unsigned int
be able to handle sizeof(aPointer)?
I think both responses missed the point of the question.
A 64-bit system can allocate huge data structures. Take, for example, an
NSString that is 2^33 characters long. It would be impossible, using
32-bit ints, to construct an NSRange that encompasses the entire
string - the length element cannot hold a sufficiently large number.
Also, the location element cannot hold a number large enough to indicate
a starting location anywhere in the second half of the string.
It's worth remembering that the elements in NSRange and other such
structs are declared merely as "int" - not as "long int." Where a short,
long, or long long has a defined size, the size of a simple "int" is
left up to the compiler. I'm old enough to remember when most C
compilers defaulted to 16-bit ints, and if you wanted to use 32-bit
values, you had to explicitly declare them as "long int." (I can also
remember using near and far pointers, and having to choose the
appropriate memory model for an app, too - but that's a whole other
nightmare.)
From what I've read, I think Panther's 64-bit support will be somewhat
limited. The OS itself, of course, will be able to manage more than 4GB
of real RAM. GCC 3.3 will probably optimize operations on long longs to
make use of 64-bit registers, which could be of tremendous value to apps
that use them. But, each user-land process will run in a 32-bit virtual
address space.
Once 64-bit userland processes are supported, I expect that the size of
unadorned ints will stay consistent with the size of a pointer, as it
did over the transition from 16- to 32-bit environments. Applications
that made unwarranted assumptions about the size of such an int were
more difficult to port, of course - for example, serialization code that
assumed 2 bytes instead of using sizeof() when writing ints to disk. The
same will be true in the upcoming transition from 32- to 64-bit apps.
Of course, apps compiled to use 64-bit address spaces and 64-bit ints
will have to be linked against frameworks that were compiled the same
way - but that's what fat bundles are for. ;-)
sherm--
Welcome to Rivendell, Mr. Anderson.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.