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: James Quick <email@hidden>
- Date: Sun, 13 Jul 2003 16:42:22 -0400
Many thanks to all who have responded to this thread.
My course is now clear.
My initial implementation will rely on NSRange, but with a tiny layer
of support code which will include:
1. A typedef declaration to make later replacement of NSRange easier.
2. Compile time guards to alert me if any types which are used as input
to the system violate the integrity of the data model.
This way I can make my dependencies an integral part of the code
without either re-inventing the wheel or adding undue risk of breaking
something if the underlying implementation must someday change.
.
On Sunday, July 13, 2003, at 03:29 PM, Greg Titus wrote:
On Sunday, July 13, 2003, at 10:56 AM, Sherm Pendley wrote:
I think both responses missed the point of the question.
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.
Exactly. Compiling with -mpowerpc64 will turn on the G5 instructions
for 64-bit registers when using long longs. See Apple's technote:
http://developer.apple.com/technotes/tn/tn2086.html
(Is it TN2064 as shown in the page title, or TN2086 as shown in the
URL? You decide...)
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.
You didn't quite finish this thought to make the answer to the
original question obvious:
If this turns out to be true then the original questioner will be
able to just go ahead and continue to use NSRange, since its structure
members and macros/functions all work on and return ints, and those
will automatically be 64-bits wide when pointers are 64-bits wide.
In short: nothing to worry about for the moment. To say anything more
than that we'll have to wait to see what Apple's 64-bit programming
model actually turns out to be.
Hope this helps,
- Greg
_______________________________________________
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.