Does Objective-C have C++11 rvalue references and move semantics equivalents or how to implement this?

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.

Answer 2

Objective-C does not have these features just as C does not, because Objective-C is a specific set of features on top of pure C. Objective-C++ does have these features because it's the same set of features on top of C++.

One of the things that makes move semantics so important in C++ is C++'s strong emphasis on value semantics. Typically you don't hold pointers to C++ objects, you hold C++ objects by value. Without move semantics this results in lots of unnecessary copies.

Not only does Objective-C not place the same emphasis on value semantics, it completely prohibits value semantics for Objective-C objects; you can only create Objective-C objects dynamically, you cannot copy an object the way you can copy C structs, etc.

@interface Foo
@end
@implementation Foo
@end

int main() {
    Foo f;
    Foo *a, *b;
    *a = *b;
}

error: interface type cannot be statically allocated
Foo f;
    ^
    *
error: cannot assign to class object ('Foo' invalid)
*a = *b;
   ^

So the C++ concept of references and moving is all done the C way in Objective-C, with pointers. Of course this means that C++ has many of the same performance advantages over Objective-C as it does over C, due to the same ability to avoid pointers.