I have an Objective C Class called Donald, I also have a C++ class called Donald in a static library that I would like to use in the same project. They both have a header file called Donald.h. Is there a way to do this?
You can include both header files by specifying a bit more of the path e.g.
#import "staticlibraryheaders/Donald.h"
#import "Donald.h"
However, you might find that the code won't compile since you are declaring two types both called Donald. If the compiler sees:
Donald* duck;
How does it know to type duck as a pointer to an instance of the C++ class or the Objective-C class? You might be able to fix that if the C++ class is in a C++ namespace. However, that hits the limit of my C++ knowledge.
Related
I have a framework target in which most of the classes are written in Objective C. Recently we have started introducing Swift files in the code. We make private Objective C files available to swift code using modules(more on this can be found here).
This approach worked well until recently when I tried subclassing one of my Objective C class using Swift, I got an error in the Generated MyFramework-Swift.h file which said "Module TestSwift not found" where TestSwift is the name of the module I provided in the modulemap file. However, if I try subclassing the classes which are listed in the umbrella header of my framework(public classes), it works.
import TestSwift
#objc public class NewSwiftClass: ExistingObjectiveCClass {
//throws error in the generated MyFramework-Swift.h file while compiling
}
If I keep my swift class internal, it works
import TestSwift
#objc class NewSwiftClass: ExistingObjectiveCClass {
//works fine
}
but I would like to use this Swift class in my Objective C files hence cannot keep it internal.
TL;DR: I'm unable to subclass an existing Objective C class using Swift inside a framework target.
I believe this is impossible in Swift because it's impossible in Objective-C.
If you have a class A in your framework that is not part of your umbrella header, and you want B to subclass it and be in your umbrella header, you can't do it.
You have to declare the inheritance in your interface declaration #interface B: A, which goes in B's header and thus in the umbrella header. But the compiler is going to complain: "What is A?" You could import A's header there, but unlike Swift's import, Objective-C's #import literally drops the contents of A's header into the B header. Which means A is now in the umbrella header too i.e. public.
Mixing Swift with Objective-C isn't magic. The compiler still needs to be able to make a valid Objective-C header that accurately describes the Swift interface. So unless you can think of a way to make Objective-C do this, you can't do it in Swift.
The only alternative I can think of is to change your "is a" relationship into a "has a" relationship i.e.
#objc public class NewSwiftClass {
let parent: ExistingObjectiveCClass
}
obviously you lose most of the benefits of actual inheritance but you'll still have the parent around as a substitute for super. You could also declare a public protocol that both classes conform to to ensure that you get consistency between their methods.
Unfortunately, I have a class defined in Objective C (Class.h, Class.m) and another class, with the same name in Swift(Class.swift).
I have a bridging header, where I import the class
#import "Class.h"
Now, I want to create a method that returns the class from Objective C.
Is there a way to specify that I want to use the Objective C class instead of the swift one, or should I start renaming my classes?
Rename classes. I am not 100% how Swift classes that are not tagged #objc are treated, but nothing good can come of having two classes with the same name, even if they're written in different languages. If the Swift version is visible to the Objective-C side, you have a definite problem, and you cannot be sure when instantiate a Class which one you will get. It could theoretically change on every run of the program, though in practice the class loader is probably too deterministic for that to occur.
I want to create an Objective C class at runtime from a file. So for example I have an objective c application, I want to then point it at a text file (or an .h .m pair, whatever works) and then have the application parse the text file and create the class at runtime (Class no object). Of course I would write the parser and all of that stuff I just want to know if its possible. I read these two articles:
http://www.mikeash.com/pyblog/friday-qa-2010-11-6-creating-classes-at-runtime-in-objective-c.html
http://www.mikeash.com/pyblog/friday-qa-2010-11-19-creating-classes-at-runtime-for-fun-and-profit.html
Which shows how to make an objective C class at runtime, but its being done using C functions which were defined at compile time. If I can find a way to do the same thing using strings to define the functions that would be perfect, because then I don't have to define them at compile time.
That's what called reflective programming. I guess there's no code evaluation support for Obj-C since it's not a scripting language, so the reflection concept for Obj-C is quietly limited. Plus, at run-time the compiler already translate the code into Obj-C clang code and it's a very time-consuming job just to reverse-translate the bytecode and recompile it again
For Obj-C reflection you can refer to these answers
Build a class :
Create objective-c class instance by name?
Implement a method :
Objective-C, how can i hook up a method in another class
Change class for an object :
Objective-C: How to change the class of an object at runtime?
Sure. Totally possible.
I would suggest starting with the Objective-C support in this as it includes a full-on Objective-C parser and code generator.
see my github project cocoa-interprreter it does part of what you want.
it takes a text file and compiles it at runtime .. and then runs the resulting executable using NSTask. It would be quite easy to change it so the binary is loaded into the own process using NSBundle
https://github.com/Daij-Djan/cocoa-interpreter
I left the original, so people can understand the context for the comments. Hopefully, this example will better help explain what I am after.
Can I create a class in Obj-C that has file-scope visibility?
For example, I have written a method-sqizzling category on NSNotificationCenter which will automatically remove any observer when it deallocs.
I use a helper class in the implementation, and to prevent name collision, I have devised a naming scheme. The category is NSNotificationCenter (WJHAutoRemoval), so the private helper class that is used in this code is named...
WJH_NSNotification_WJHAutoRemoval__Private__BlockObserver
That's a mouthful, and currently I just do this...
#define BlockObserver WJH_NSNotification_WJHAutoRemoval__Private__BlockObserver
and just use BlockObserver in the code.
However, I don't like that solution.
I want to tell the compiler, "Hey, this class is named Bar. My code will access it as Bar, but I'm really the only one that needs to know. Generate a funky name yourself, or better yet, don't even export the symbol since I'm the only one who should care."
For plain C, I would is "static" and for C++ "namespace { }"
What is the preferred/best/only way to do this in Obj-C?
Original Question
I want to use a helper class inside the implementation of another. However, I do not want external linkage. Right now, I'm just making the helper class name painfully unique so I will not get duplicate linker symbols.
I can use static C functions, but I want to write a helper class, with linker visibility only inside the compilation unit.
For example, I'd like to have something like the following in multiple .m files, with each "Helper" unique to that file, and no other compilation unit having linker access. If I had this in 10 different files, I'd have 10 separate classes.
#interface Helper : NSObject
...
#end
#implementation Helper : NSObject
...
#end
I have been unable to find even a hint of this anywhere, and my feeble attempts at prepending "static" to the interface/implementation were wrought with errors.
Thanks!
I don't believe you will be able to do what you want because of the Objective-C Runtime. All of your classes are loaded into the runtime and multiple classes with the same name will conflict with each other.
Objective-C is a dynamic language. Unlike other languages which bind method calls at compile time, Objective-C does method resolution at invocation (every invocation). The runtime finds the class in the runtime and then finds the method in the class. The runtime can't support distinct classes with the same name and Objective-C doesn't support namespaces to seperate your classes.
If your Helper classes are different in each case they will need distinct class names (multiple classes with the same name sounds like a bad idea to me, in any language). If they are the same then why do you want to declare them separately.
I think you need to rethink your strategy as what you are trying to do doesn't sound very Objective-C or Cocoa.
There's no way to make a class "hidden." As mttrb notes, classes are accessible by name through the runtime. This isn't like C and C++ where class are just symbols that are resolved to addresses by the linker. Every class is injected into the class hierarchy.
But I'm unclear why you need this anyway. If you have a private class WJHAutoRemovalHelper or whatever, it seems very unlikely to collide with anyone else any more than private Apple classes or private 3rdparty framework classes collide. There's no reason to go to heroic lengths to make it obscure; prefixing with WJHAutoRemoval should be plenty to make it unique. Is there some deeper problem you're trying to fix?
BTW as an aside: How are you implementing the rest of this? Are you ISA-swizzling the observer to override its dealloc? This seems a lot of tricky code to make a very small thing slightly more convenient.
Regarding the question of "private" classes, what you're suggesting is possible if you do it by hand, but there really is no reason for it. You can generate a random, unique classname, call objc_allocateClassPair() and objc_registerClassPair on it, and then assign that to a Class variable at runtime. (And then call class_addMethod and class_addIvar to build it up. You can then always refer to it by that variable when you need it. It's still accessible of course at runtime by calling objc_getClassList, but there won't be a symbol for the classname in the system.
But this is a lot of work and complexity for no benefit. ObjC does not spend much time worrying about protecting the program from itself the way C++ does. It uses naming conventions and compiler warning to tell you when you're doing things wrong, and expects that as a good programmer you're going to avoid doing things wrong.
Where can i find a concrete document or a dos and donts documentation on using C++ with Objective-C?
Apple seems to have removed that document from their website and i am all puzzled with collating bits of information from blogs and questions posted here.
Anyone can guide about the same.
When do we use .mm file, while mixing syntax or while using an object in .m file which belongs to a C++ class ?
While passing objects between functions belonging to two different language like passing objective-c object to a function in cpp file is it necessary to collect it in void * or can I use (ObjectiveC inteface)*?
You need to use Objective-C++ whenever you are either #include/#importing or directly writing both Objective-C and C++ code in the same file. It's usually obvious with explicit code; the #includes are often less so, and you need to take care to avoid "leaking" one of the languages into too much of the other. Your example of #importing a C++ header file is clear-cut: you can only do that with Objective-C++. Note that if your Cplusplus was a struct type, you could forward-declare it as such instead of #importing a C++ header.
If you do this in a header, it will "poison" the header to only work in that mode. You'll need to actively avoid this, or your whole project will soon end up with only .mm files. I have documented some techniques in this article and previously, in this earlier article. For newer versions of Objective-C, you can also add ivars to classes in category extensions. This means you can define C++-typed ivars in your .mm file, not the header, which allows .m files to #import it.
For your second question (Please only ask one question at a time): the id type is defined in the objc.h header file in terms of C and thus will work in both Objective-C and C++. Likewise, the Objective-C runtime API is exposed in terms of C functions, which will work from C++, too. If you actually want to send messages and access properties on Objective-C objects with the canonical syntax from C++ code, you'll need to switch that file to Objective-C++.
Use .mm files when you have a c++ syntax in your code or when including file(s) which contain c++ code.
Mixing C++ with objective-c may be a bit confusing but if you think pointer-wise than it is not a big deal. Treat C++ object instance methods as you would in C++ and the same goes for objective c objects.