Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS Can Objective C object Contains STL Object
- Thread starter teguh123
- Start date
- Sort by reaction score
You can use the STL (or any other C++ libraries) if you work around a lot of the 'gotchas'.
The biggest one is ObjC will not call destructors for your C++ types automatically... which means if you insist on using std::string* over NSString* you have to make sure that every collection (NSArray, etc) you add the string to, you go back and manually delete. The Cocoa collections won't do so for you.
Unless you are doing so for a very specific reason, by the time you ref count your std::string and wrap it to be released properly, you've generally copied NSString* and running slower to boot.
On top of that, you have to make sure you wrap all your calls between the two (ObjC and C++) as the exceptions in one aren't caught in the other.
The biggest one is ObjC will not call destructors for your C++ types automatically... which means if you insist on using std::string* over NSString* you have to make sure that every collection (NSArray, etc) you add the string to, you go back and manually delete. The Cocoa collections won't do so for you.
Unless you are doing so for a very specific reason, by the time you ref count your std::string and wrap it to be released properly, you've generally copied NSString* and running slower to boot.
On top of that, you have to make sure you wrap all your calls between the two (ObjC and C++) as the exceptions in one aren't caught in the other.
Let your needs dictate which you use. If your libraries use STL, or if that is how you want to write your core implementation, do so. Get an NSString out of it only when necessary (for display, for example).
Don't mix Obj-C and C++ just for the fun of it. It will make you unhappy with both languages.
Don't mix Obj-C and C++ just for the fun of it. It will make you unhappy with both languages.
I am not going to use std::string *
I am going to use std::string
You said that cocoa won't call the destructor of std::string destructor automatically?
I am thinking of doing the the biz logic in C++ and the UI in obj_c
Anyway is there a resources on combining C++ and obj_C and what gotcha should I learn?
I am going to use std::string
You said that cocoa won't call the destructor of std::string destructor automatically?
I am thinking of doing the the biz logic in C++ and the UI in obj_c
Anyway is there a resources on combining C++ and obj_C and what gotcha should I learn?
You can only use std::string inside a function, not as a class instance variable. C++ objects must* be accessed through pointers to the heap to be member variables of an ObjC class.
The only way around this is to create a large C++ class with all the member variables inside it, and allocate that one class on the heap.
You seem to have some aversion to allocating std::string on the heap. Not sure why, but you'll continue to hit your head getting C++ and ObjC to interact if you do so.
To summarise:
Good:
Bad:
*As noted below, very simple C++ classes can live inside ObjC classes as member variables if they have default constructors and no virtual functions.
-Objective-C classes cannot have instance variables of C++ classes that do not have a default constructor or that have one or more virtual methods, but pointers to C++ objects can be used as instance variables without restriction (allocate them with new in the -init method).
-C++ "by value" semantics cannot be applied to Objective-C objects, which are only accessible through pointers.
-An Objective-C declaration cannot be within a C++ template declaration and vice versa. However, Objective-C types, (e.g., Classname *) can be used as C++ template parameters.
-Objective-C and C++ exception handling is distinct; the handlers of each cannot handle exceptions of the other type.
-Care must be taken since the destructor calling conventions of Objective-C and C++s exception run-time models do not match (i.e., a C++ destructor will not be called when an Objective-C exception exits the C++ objects scope). The new 64-bit runtime resolves this by introducing interoperability with C++ exceptions in this sense
The only way around this is to create a large C++ class with all the member variables inside it, and allocate that one class on the heap.
You seem to have some aversion to allocating std::string on the heap. Not sure why, but you'll continue to hit your head getting C++ and ObjC to interact if you do so.
To summarise:
Good:
Code:
-(void)foo
{
std::string s;
// magic/your code here
// s is cleaned up when scope exits
}Bad:
Code:
@interface bar {
std::string s; // compiler error here, std::string has virtual methods; cannot be a member variable
std::string* ps; // ok, by using a pointer ObjC doesn't have to worry about calling constructors, destructors, setting up vtables, etc, you will do that yourself manually with new and delete.
}
-(void)foo;
@end*As noted below, very simple C++ classes can live inside ObjC classes as member variables if they have default constructors and no virtual functions.
-Objective-C classes cannot have instance variables of C++ classes that do not have a default constructor or that have one or more virtual methods, but pointers to C++ objects can be used as instance variables without restriction (allocate them with new in the -init method).
-C++ "by value" semantics cannot be applied to Objective-C objects, which are only accessible through pointers.
-An Objective-C declaration cannot be within a C++ template declaration and vice versa. However, Objective-C types, (e.g., Classname *) can be used as C++ template parameters.
-Objective-C and C++ exception handling is distinct; the handlers of each cannot handle exceptions of the other type.
-Care must be taken since the destructor calling conventions of Objective-C and C++s exception run-time models do not match (i.e., a C++ destructor will not be called when an Objective-C exception exits the C++ objects scope). The new 64-bit runtime resolves this by introducing interoperability with C++ exceptions in this sense
Apple used to have a document on Objective C++ that is linked to from many places on the web, including Wikipedia and https://forums.macrumors.com/threads/757218/, but seems to have been removed from their site entirely and the document that it redirects to doesn't say anything about C++. The wayback machine can't find it either.
Weird.
B
Not really no. But I think the main question is why do you want to use it? If it's for the portability of some core logic in the application then keep that separate in C++ and bridge with Obj C++. If it's just so you can code the logic in familiar C++ I recommend against it; keeping the whole thing in Obj C, if it doesn't need portability, is much easier to manage.
Easier said than done if the main source of documentation for Obj-C++ everyone points to is missing in action.
It really does seem like Objective-C++ is deprecated in Apple's mind if they don't even mention it in passing anymore.
B
Could have just been moved or is being updated. Obj C++ still compiles in Xcode 4 with LLVM and I would have assumed that Apple would have announced it if it was going away completely.
Yeah, me too. I hope it's just temporarily lost in the shuffle. I have a project where it would have been useful.
B
I see.
What would be kind of cool is if I simply use C++ restaurant classes and then build a bridge function to objective C.
However after thinking about it, I see that building that bridge function will be more complicated than making the whole restaurant classes in Objective C
What would be kind of cool is if I simply use C++ restaurant classes and then build a bridge function to objective C.
However after thinking about it, I see that building that bridge function will be more complicated than making the whole restaurant classes in Objective C