在 ARC 中禁止投射内存位置……那么如何获取对象的内容？

Question

I used to be able to do this in Objective-c. Now ARC disables this:

NSString *mice = @"dogs eat cats";
long dog = (long)mice; 
NSString *appled = (NSString *)dog;

Am I missing something. If I know the address of my object how can I get the contents of it?

Answer 1

And it uses less memory (in your own comment on your question)

It uses exactly the same amount of memory: storing an n-bit pointer as an n-bit integer takes n-bits!

You should carefully review why you are doing this and whether your code will remain safe under ARC.

Pre-ARC you could "hide" a reference to an object and that object would stay around until you issued an explicit release() .

Post-ARC there are bridge casts (multiple kinds exist) which enable you to explicitly take responsibility for object lifetime, and to later transfer the responsibility back.

To "hide" the reference as you do in your example therefore requires two bridge casts, one in each direction. Failure to do this correctly will result in objects being automatically released by ARC and memory faults/corruption when you attempt to use your recovered pointers.

The ARC documentation describes the various bridge casts and when to use them. However given your comment on memory use consider very carefully whether you should be doing this.

HTH

---

Addendum : Comment followup

You are misunderstanding how memory addresses, object lifetime, etc. work in (Objective-)C. I would strongly recommend you do not attempt to use any bridge casts until you have figured this out. Let's see if I can help you understand, with the help of an analogy or two.

Warning: Analogies always break down at some point, you should not push them too far and I'll try not to!

Let's look at your comment, it starts:

sizeof(long) = 8, sizeof(NSString)?-->"can't apply 'sizeof' to the class NSString".

You are correct that in Objective-C taking the sizeof of a class type is disallowed, but that is not what the issue is here. Look at the code in your question:

 NSString *mice = @"dogs eat cats"; long dog = (long)mice;

Here you are not operating on a value of type NSString but on one of type NSString * - these two are very different.

Instead of considering NSString which is an object type in Objective-C think of a real world analogy: a building. In this analogy what is the equivalent of an object reference, such as NSString * ? It is the address of the building.

Is a building address the same kind of thing as a building? No. Is it the same size as a building? No. You can write the address on a piece of paper and put it in your pocket. You can't put a building in your pocket (unless you are Gulliver ;-)). You can even put your piece of paper with an address on it inside a building, it fits easily.

What the address of a building does is enable to you locate the building, but it doesn't guarantee that there is a building at the address - it could have been demolished, and may have been replaced by a new building with a different purpose.

This is analogous to the address of an object, it enables you to locate the object, but is does not guarantee the object exists – it could have been destroyed, and its old location could now be part of some other object.

The comparison you were after is what is sizeof(long) compared to sizeof(NSString *) . On current 64-bit Objective-C you'll find both of these result on 8 .

Note: on the (rare) occasions you need to store an address in a integer you should not use the type long , rather you should use the type intptr_t which is a standard C integer type of the same size as an address. So your code should really have been:

 NSString *mice = @"dogs eat cats"; intptr_t dog = (intptr_t)mice;

(That said, you probably shouldn't have written this code at all.)

Back to your comment, you continue:

But in it's place as an example, if I were to create a structure of 4 longs... the sizeof(struct4longs) = 32. Lets say you have a structure that takes 1mb of ram. Under ARC using their rules, to keep the reference, I would allocate 1mb to keep the reference to the 1mb... because the old way of referencing(keeping only addresses) is no longer allowed-->NSString *appled = (NSString *)dog;

No, no, no. An address is the same size regardless of what it references.

In our analogy of buildings the addresses "330 5th Ave, New York" and "350 5th Ave, New York" are exactly the same size. The first is a Panera Bread cafe, the second is the Empire State Building – the buildings are not the same size!

Converting an object address to an integer does not save any space at all.

The difference between pre-ARC and post-ARC

Sticking with our analogy: In pre-ARC times buildings were built ( alloc / init , new , etc.), marked as in use ( retain ), marked as no longer required ( release ), and eventually demolished (object destruction) manually .

A building could be left empty and unused and it just stood there, using up space, unless the builder (programmer) came along and demolished it (the programmer matches a release for every retain ).

You could write the address of a building in your address book (store its address in a pointer-typed variable such as NSString * ), it did not have any effect on the lifetime of the building.

You could keep an obscured copy of the building address, say write it in code and put it in your calendar (the equivalent of you placing an object address in an integer typed variable), it still had no effect on the lifetime of the building.

So in the pre-ARC days your scheme "worked" – in that you could hide and recover object addresses – but it had no real purpose, it didn't save any space, just made your code harder to understand and more error prone. You had to use manual calls ( retain , release ) to control the lifetime of your objects.

The post-ARC world changes all this.

In the post-ARC world building demolition was taken over by an automatic robotic system, buildings no longer in use are demolished. No action required by humans (programmers).

So how does the robotic system know when a building can be demolished?

Coloured paper! (I do not joke, but remember this is an analogy)

The rule is simple: write down the address of a building on a piece of yellow paper and the robot demolition crew will not demolish the building.

Get an eraser and rub out the buildings name from every piece of yellow paper it is on and the robot crew will, at some time of their choosing , move in and demolish it.

Same thing happens if you throw away or burn the piece of yellow paper. Only yellow paper owned by someone is considered by the robot demolition crew. (This includes yellow paper found inside buildings provided the address of that building is written down on a piece of yellow paper, and if that piece of yellow paper is in a building then that building's address is written on another piece of yellow paper... etc., and provided at some point there is a piece of yellow paper not in a building which starts the chain off.)

Write the address on a piece of white paper and the robots just ignore the piece of paper. Only owned yellow paper prevents the building being destroyed.

What your old pre-ARC code does in the the new post-ARC world is transfer the address of a building from a yellow piece of paper to a white piece, and then throws aways the yellow piece. Not good when there is an eager robot demolition crew looking to demolish buildings out there.

Later you try to copy the address from your white piece of paper back onto a yellow piece in the hope that the robots haven't found the building yet... hopes get dashed, that's life. Left something important in the building? A priceless work of art maybe left hanging on the wall? Tough.

Enough analogy, back to Objective-C:

The yellow pieces of paper are technically called strong references , a variable of object type (eg NSString * ) in the post-ARC world is (usually, the few exceptions can be ignored at this point) implicitly marked as strong (eg __strong NSString * ).

The white pieces of paper are all non-object pointer typed variables (eg long , intptr_t , and even int * etc.) and object pointer typed variables explicitly marked as __unsafe_unretained – that name should tell you everything, storing an address only in any such variable is unsafe as the object will not be retained , the automatic object reclamation will destroy it.

Conclusion:

Do not do what you were doing in the pre-ARC days.

• In those days it saved no memory and had no useful purpose, however it wasn't unsafe.

• In the post-ARC days it not only has no useful purpose, it is unsafe.

Just store your addresses as addresses.

You might wonder why bridging casts exist. Well there are special cases where they are needed, they are not for general use. When, and if, you get to those cases you'll read about them and how to use them safely.

I hope the above helps you sort this out!

Answer 2

You need to cast it to void * first:

NSString *appled = (__bridge NSString *)((void *)dog);

Updated. Because of down votes on this post I need to add a warning: Obj-C is flexible enough to let you fix such kind of compiler errors, but if you tying to do so - you need to be completely sure what you are doing and why.

Storing object pointer in non-object type will act like __unsafe_unretained variable.

__unsafe_unretained specifies a reference that does not keep the referenced object alive and is not set to nil when there are no strong references to the object. If the object it references is deallocated, the pointer is left dangling. (source)

So even if you need to make such type casts (for any reason), and you want your object to be valid - you need to ensure that this object has at least one strong reference.

And in case if you don't want to keep strong references to original object, you can count references by yourself using __bridge_retained and __bridge_transfer

NSString *mice = @"dogs eat cats";
long dog = (long)(__bridge_retained CFTypeRef)mice;
// here original mice object has retain count +1

NSString *appled = (__bridge_transfer NSString *)((void *)dog);
// here __bridge_transfer decreased previously gained retain count by 1