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++.)
Related
When I call 3rd party Objective-C code from Swift, and that code is not annotated with _Nullable/_Nonnull, it's imported to Swift as Implicitly Unwrapped Optional. That means that if I'm not extra careful, I can easily cause a crash if my code just assumes it's not nil - the compiler doesn't even give a warnings.
Is there a pattern or idiom that will help in this situation?
The compiler seems to be happy, I'm happy with slightly improved readability, but Xcode's code completion doesn't particularly recognize alloc and class when invoked this way:
MyClass* object = [MyClass.alloc initWithBounty:bounty];
<...>
if ([object isKindOfClass:MyClass.class])
<...>
So I was wondering what is wrong with the above, if at all?
Well, primarily what's wrong is that dot notation is for retrieving things that are conceptually properties. alloc does not access a property of the class; it creates an object. Using it for any zero-argument method is not more readable — it's confusing.
MyClass.class is actually not problematic in that way, but there's no way to declare properties on a class and they usually aren't thought of as having properties, so the autocomplete apparently doesn't support it.
Dot notation is originally added to be used for property access. So you can use them only for
A method takes no parameter and returns single value (getter).
A method takes single parameter and returns no value (setter).
Otherwise, recent compiler will complain about it.
Anyway, I agree to #nhgrif that using dot notation on non-property method is not a good practice.
I have heard that C doesn't have closure, and today I saw the use of closure in Objective-C. Is closure supported in Objective-C and not in C?
Update: thanks for all the answers. I found this guide on the web on blocks as well: http://pragmaticstudio.com/blog/2010/7/28/ios4-blocks-1
Apple added the ^ operator to add closure support. It is not tied to Objective-C however, and can be used in C and C++ as well, as long as you compile the project with Apple's brach of GCC or LLVM. This new feature is called blocks.
C has closures in the form of application-defined structures that contain both a function pointer and data pointer. The problem is just that many/most interfaces that take a callback pointer (like qsort) accept only the function pointer and not a corresponding data pointer, making it impossible to pass closures to them.
By the way, it's theoretically possible to add closure support at the library level without assistance from the compiler, i.e. create a library that would return a function pointer to a closure. However, the library code would be rather implementation/machine-dependent. It would need to allocate space for executable code and generate code to pass a fixed pointer value (saved as part of the closure object) along with other arguments to the function.
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
}
What is the difference in accessing an objects properties or methods via foo.property to [foo property]?
Nothing! Dot-notation is "syntactic sugar" introduced in Objective-C 2.0. In fact, the compiler converts foo.property to [foo property] during compile-time, so they compile to exactly the same thing.
It's simply a matter of which you prefer.
At compile time they're treated the same, but one benefit of using dot notation to handle properties is that while coding, after placing the "." code completion/code window will only show valid properties as suggestions whereas using brackets will show all methods.