I had this declaration.
- (BOOL)getNHPData:(REMOTE_MESS_ID)msgId withEvent:(RSEvent*&)pEvent;
I tried with RSEvent** also but i'm getting this error for 2 times
Expected ')' before RSEvent
Why is it so.
Objective-C is a superset of the C language and does not have references. If you want to use C++-style references in Objective-C, you must compile as Objective-C++ (as you might expect, Objective-C++ is a superset of C++). Use the .mm extension to automatically use the Objective-C++ in Xcode.
If the method in question is a public API that will be consumed from Objective-C, I would highly recommend using a pointer-to-pointer (RSEvent**) instead of a pointer reference. Using Objective-C++ in a header "infects" clients with Objective-C++ (unless you're very careful). Objective-C++ takes much longer to compile that Objective-C and you will eventually run into the inevitable C vs. C++ incompatibilities. Standard practice is to hide Objective-C++ from public APIs whenever possible.
I personally have never had much success in c++ or obj-c with pointer references, if I need that kind of functionality, I usually just use a pointer pointer like this:
some function()
{
RSEvent *pEvent = new RSEvent();
[self getNHPData:DEFAULT_MSG_ID withEbvent:&pEvent];
}
- (BOOL)getNHPData:(REMOTE_MESS_ID)msgId withEvent:(RSEvent**)pEvent
{
//Do some stuff
}
Related
I have to hack on an Objective-C++ project and I am trying to figure out how optionals work there. What's the analogous of std::optional there?
Simple example:
- (void)foo:(CGSize)first
second:(nullable CGSize*)second;
I can now pass nil if I want to omit second.
However, I cannot figure out how to construct a pointer to CGSize to pass it to foo.
If you're using Objective-C++ throughout (the implementation and the consumer of the API are both Objective-C++, not Objective-C) you can just use std::optional:
- (void)foo:(CGSize)first
second:(std::optional<CGSize>)second;
If your method needs to be callable from Objective-C, you can use a pointer, as you indeed have in your code snippet. However, for non-object types (non-#interface, non-id, non-#protocol) you use NULL instead of nil in Objective-C, much as you do in C. (You can interchangeably use nullptr instead of NULL in Objective-C++, with the former providing all the advantages it also gives in pure C++.)
I am new to IOS developing, and want to use the Swift language instead of Objective-C.
I know few concepts about Cocoa touch, and I want to know : Can Swift do everything that Objective-C can do ?
There are a lot of things that can be done in Objective-C but cannot be done in Swift, without implementing it in Objective-C and then using it from Swift. Some of them include:
Catching Objective-C exceptions
Using C++ APIs (through Objective-C++)
Using NSInvocation, performSelector: and other ways of making calls dynamically where the method to call is chosen at runtime
Handling unimplemented method calls using forwardInvocation:
Provide a function for use in C APIs that take a function pointer
The only concept I know that is in Objective-C but not in Swift, is Key-Value Observing (KVO). You can use KVO for a Swift class to observe the property of an Objective-C class, but you cannot observe any arbitrary property of a Swift class. See this answer for more details.
This is an interesting question but essentially the answer must be NO because you can use Objective-C resources in swift using bridging-headers. Xcode automatically translates Swift to Objective-C and vice versa. However, if you cannot write Objective-C code then you cannot include your own custom objective-c classes in your swift projects!
It all depends on how you like to code. Apple have said that Objective-C is still a 'first class' language meaning that they are going to run Swift and Objective-C side by side for the foreseeable future. Personally I prefer Objective-C because you can use C very easily (as anything that is legal in C is also legal in Objective-C) added to which Swift is a more procedural in style where Objective-C is quite clearly object orientated.
It is worth noting that the Cocoa and Cocoa Touch classes are all objective-c classes and so it may be useful to have a working knowledge of Objective-C. I think the best advice I've heard so far is, if you have the time, learn both!
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 :(
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.
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
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.)
Thank you to Yuji for answering another question I had and pointing me to this article about dynamic ivars in Objective-C.
However, as explained in my other question the sizeof operator now behaves inconsistently. In short, sizeof will not take into account dynamic ivars from outside the class .m file but will take them into account inside the .m file after the #synthesize declarations that create the dynamic ivars.
So my question is does this break the idea that Objective-C is a strict superset of C?
No. All valid C code remains valid Objective-C code with the same meaning it has in C, so Objective-C is still a strict superset. Keep in mind that a superset is allowed to have features not found in a subset — that's the whole reason Objective-C can have all the additional capabilities and syntax that it does while remaining 100% C-compatible.
What this does affect is the implementation detail that Objective-C classes are essentially C struct types with a set of functions that act on them. Note that similar functionality to objC_setAssociatedObject() could be implemented for a CoreFoundation-style pure C struct without changing the C language itself at all — and it would have the similar side effect of making sizeof() not give a fully "accurate" idea of all the data the struct encompasses.
No. If you run Objective-C code through a C compiler it never would have compiled anyway. If you run C code through an Objective-C compiler it will behave exactly as if you had run it through a C compiler (barring compiler bugs).
If you ever find yourself writing sizeof(MyObjectiveCClass) you are almost certainly doing something horribly wrong that will be completely broken.
i have a .m class written in objective c that needs to send information to a .mm class written in c++
i tried to use CFNotification and as far as i can tell the notifcation sent by the .m class can be picked up by the .mm class
the problem now is trying to get information across in that notification.
The documentation says i need to pass the info as a CFDictionary, i'm having a lot of trouble trying to create the dictionary...
the problem is due because of the second and third parameter. They require a const void** type...
which is a c++ array (right?) and i can't make a c++ array that contains some objective c objects
i tried making a c++ class in another .mm file but i can't include that in the .m file because i get compile errors saying there is stuff wrong with the syntax. if i change the .m file to a .mm file i get rid of those errors but i get a whole lot of other errors from the openGL and a few other conversion compile errors
... i tried making a .m wrapper for the .mm file so i can send and receive NSNotifications but i get a stupid error saying i've tried to redeclare the type of the wrapper but only when i tried using it...
The easiest solution to your problem is to forget about Objective C files and C++ files and switch to using Objective C++ files (extension .mm) for everything. You can alternatively tell Xcode to compile everything as Objective C++ irrespective of file extension.
Then use the fact that NSNotificationCenter and CFNotificationCenter interoperate, so you can use whichever you prefer at the time, or since your code is now all Objective C++, you can use either one exclusively from everywhere.
Follow that up with the fact that NSDictionary* and CFDictionaryRef are toll free bridged, as are NSString* and CFStringRef. That is to say, anything that accepts a CFDictionaryRef as a parameter can be passed an NSDictionary* cast to a CFDictionaryRef and vice versa.
So if you have an NSDictionary with NSString keys and values you can equally treat that pointer as a CFDictionaryRef with CFStringRef keys and values.
Okay, you're making this way harder than it needs to be.
So you want to send a notification with Objective-C? Use NSNotificationCenter. That's it, you're done. Don't use CFNotificationCenter. Actually, they're the same thing, but you shoud use the NSNotificationCenter interface from Objective C and only use the CFNotificationCenter interface when you need to write something in plain old C -- approximately never, if your app already has Objective C in it.
The void const** isn't necessarily a C++ array, either. And yes, you CAN put Objective-C objects in normal C arrays. For example:
NSString *const MESSAGES[2] = { #"Hello", #"Goodbye" };