Template in Objective C?

Question

Everything is in the title :)

Is there any templates in ObjC ?

I need equivalent of c# :

public class MyClass<T> : Message

in ObjC .

Any helps will be strongly thanks :(

Solution 1

There is no such ObjC feature. While ObjC++ does exist, I strongly discourage its broad use. It has many problems from poor tool and debugger support, to poor compiler optimization, to degraded ARC performance.

Generally templates are not required in ObjC because it is not a strongly typed language. An NSArray can hold any object, so you don't need to use a template to get the right type. Do you have a specific problem you're trying to solve? There is likely a better ObjC solution.

Solution 2

Obj-C supports templates since Xcode v7. It is named generics:

Lightweight generics now allow you to specify type information for collection classes such as NSArray, NSSet, and NSDictionary. The type information improves Swift access when you bridge from Objective-C, and simplifies the code you have to write. For example:

NSArray<UIImage *> *images; 
NSDictionary<NSString *, NSURL *> *resourcesByName;

Look for "Objective-C Language Changes" section in https://developer.apple.com/library/content/documentation/Xcode/Conceptual/RN-Xcode-Archive/Chapters/xc7_release_notes.html

Solution 3

By the way, Xcode supports adding C++ classes through the New->File. Using the extern "C" {} construct in C++ means you can provide as much or as little C-callable interface as you need, which you can then call directly from your Objective-C code, since Objective-C is a superset of C.

Having said that, it's probably a good idea to stick within the Objective-C paradigm unless you have a pressing reason to move outside it, such as the need to incorporate a body of existing C++ code into your project. (That's not to say that Objective-C is a "better" language, which is a different matter entirely.)

Comments

[UIChris]

Yes. In Fact, I need to send information in byte[] to a server, in c#. I must respect the same class organization, with their names, inheritance, and template. The first class I need to reproduce is public class MyClass<T> : Message

[Rob Napier]

Writing a network protocol has no relationship at all to the class implementations. But if you find it easier to transliterate the code, then write a pure C++ layer that takes and receives byte buffers from the ObjC. Let ObjC talk to the network, and let C++ parse and encode the data. You could then share the same C++ with C# as well. stackoverflow.com/questions/935664/…

[UIChris]

I don't choose it :( It's because I must follow this implementation because I have to send, into byte[], thoses classes to be understandable by server

[Rob Napier]

Bytes are bytes. They're not related to the implementation that writes them. I can write the same bytes in Perl as I can write in C#. I can write data that says "This piece of data represents a template instantiation on 'x'" in any language without requiring that the language itself support templates. Perhaps you can open a new question with details of the data format you're trying to read and write, and we can help you build a portable system to do that. That said, taking language-specific object serialization from one language to another is always going to be challenging at best.

[Rob Napier]

BTW, if what you need is tight, low-level integration with existing C#, you should look at the mono project. mono-project.com

[UIChris]

Is it easy to use ? Did u ever use it?

[Rob Napier]

No; I do very little work with C#. And I tend to find that projects like Mono lead to poor iOS products. But if you need a piece of your product to be very tightly integrated with a specific C# implementation and you cannot fix the data format to be less implementation specific, then you're best off starting with a tool that is designed to deal with C#. The much better solution is to read and write your data in less implementation-dependent ways, such JSON, protobuf, thrift, messagepack, etc. But that's not always in your control.

[bshirley]

Note: this supports compile time checking and not runtime enforcement.