GCC_ENABLE_CPP_EXCEPTIONS and Objective-C - objective-c

I have a pure Objective-C project (no C++ anywhere). Can I turn off GCC_ENABLE_CPP_EXCEPTIONS or do Objective-C exceptions rely on this?

If you're not using any C++ code, you can turn it off (it only applies to C++ code). Or you can leave it on -- it won't really matter either way.

Related

Objective-C++: is there an overhead in generated code compared to Objective-C?

Let's say you have an Obj-C module written in pure Obj-C. Does switching the extension to .mm mean that the generated code will be larger due to C++ exception handling (or something else maybe)?
There are two possibilities: You either need Objective-C++ or you don't. If you don't need it, don't use it. If you need, well then you need it, so if there is memory overhead, there isn't much you can do about it.
Don't switch to Objective-C++ just for fun. I wouldn't use it for anything other than writing bridging code between Objective-C and C++.

Can Swift do everything that Objective-C can do?

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!

Is it possible to see Objective-C ARC output?

In xcode, it's possible given some Objective-C code, to see the code it would output in Assembly.
Is it possible to see given ARC enabled code, to see the Objective-C that would be outputted by ARC?
It is not possible, because ARC does not produce Objective-C code. ARC is a compiler feature that modifies the assembly produced in the same way that enabling optimizations might do. You can't tell the compiler to show you "optimized" C code; the optimizations are not applied at the level of C code. Likewise, you cannot ask to see the "ARC-ified" Objective-C, because the ARC memory management calls are not applied at the level of Objective-C code.
If you really want to see where the memory management calls are being made, you'll have to look at the assembly.
ARC doesn't as such output Objective-C, it a phase of the compiler which alters the assembler/machine code the compiler produces - and as you noted you can see that in Xcode. However if you use a decompiler on the binary you should see a "MRC equivalent", which is as good as you'll get. Try Hopper - demo available, I've not used it myself, don't know the producers, etc. However it produces psuedo-code, which looks like structured assembly, not Objective-C. HTH.

How to programmatically detect automatic reference counting?

This might be a silly question, but I just wanted to know. I want my code to detect if ARC is enabled, programmatically. How do I do that? Is there is any flag that I could check? Actually the problem is that, I have written an open-source library. I have used release and retain in it. if some one else uses my library files using ARC enabled, I dont want them to get any errors. how do I achieve this? or is there any possible ways I can provide any tools to compile my library before using it?
#if !__has_feature(objc_arc)
//Do manual memory management...
#else
//Usually do nothing...
#endif
This is of course a compile-time check, you cannot check for ARC at runtime.
An alternative would be to set the -fno-objc-arc compiler flag for your files that use manual memory management in a project that otherwise uses ARC.
Whether you want to bother with this at all or just use ARC everywhere depends on how backward-compatible you want/need to be. Code that supports both ARC and MRC can get quite hard to read and maintain.
You don't detect it programmatically, it operates based on translations. That is, it is not like Garbage Collection -- which is process-wide, required all linked libraries to support (and implement it correctly in that mode). You can have some files compiled with ARC, and some without.
However, you can detect it at compilation.
As far as the distribution of your library: I would not bother with a translation based system, where ref count ops are conditionally enabled. I would (personally) just support one model (MRC in your case, until you choose to migrate it to ARC), then expect people to link to the library, or if they compile it in a target they configure, to disable ARC. Conditionally enabling/disabling code based on the presence of a feature is asking for tough bugs, particularly when it's likely to affect 9% of your library's lines of code.
NO, you can't, Xcode would not compile in ARC projects if your source uses retain-release

Template in Objective C?

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.)