Question

I’m in the process of learning Objective-C. And I have such an “academical” question which is addressed to Objective-C experts with good knowledge of modern C++ (C++11).

In C++11 I often used move semantics (using references to temporary objects we can avoid unnecessary copies):
What are move semantics?
http://www.cprogramming.com/c++11/rvalue-references-and-move-semantics-in-c++11.html

these links for objective-c coders not familiar with move semantics concept, and I’m interested does Objective-C has something similar or may be there are some ways to implement/emulate this?

Answer 1

does Objective-C has something similar or may be there are some ways to implement/emulate this?

Nope. That’s not a huge issue, once you have digested the abstraction layer you are working at with Objective-C. Understand that objects are reference counted and are heap allocations.

Now there are two ways you can take this:

a) Use Objective-C++ — Just mix and match the language features to your content.

b) Use idiomatic Objective-C. This goes back a long time. Once you accept that objects are reference counted heap allocations and there is no way around that (with clang), then you learn to approach programs differently. Sure, reference counting everything and putting it on the heap has costs, but you can take advantage of those traits in some scenarios. The most notable uses are the use of immutable objects and shallow copying. Copying a std::string as object is going to result in SSO copy or a heap allocation. Copying an NSString could simply return itself (after incrementing the reference count or not, depending on the type of string it is, it may also need to create a concrete copy at that point). As well, these objects are all just pointers, so you don’t need to actively be concerned with how to pass an object (value/reference/const reference/move). A far simpler model exists in ObjC, which can be exploited. So there is a shift in design here: there is less “value dominance” in ObjC and more of “favor immutability and sharing”.

In some cases, you can write a move method. Since common framework classes do not support this, it typically makes more sense to use object composition.

Since objects are allocated on the heap, moves are not so important. Well designed classes take costs into consideration to minimize huge/expensive copies, and internally use some interesting optimizations. The idiom just suggests that you should take a different approach to creating your classes — how do they share data? What is mutable? What must be copied? Sometimes, you might be dealing with big, mutable/expensive data and a move would be convenient, but you could often just place that in a shared container object or reconsider semantics of your objects’ initialization in order to minimize physical copying (and avoid odd semantics in object interfaces). Beyond that, I don’t see moves as being very useful all too often in pure Objective-C. Of course, they become important for C++ libraries which have been designed to make use of move semantics and are able to create objects in several memory locations. If you do move, you would usually want to keep that detail private or make it really obvious (e.g. I have done that in a rendering pipeline to minimize big allocations for each filter).

Examples of where you think it would be beneficial would also help understand your problem/rationale.