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.
macOS mixing c++ and objc
- Thread starter kamo
- Start date
- Sort by reaction score
Imagine you need to do something, and you find a library that does exactly what you want, and that library is 100,000 lines of C++ code. Do you (a) rewrite 100,000 lines of C++ code in Objective C, or do you (b) find a way how to mix C++ and Objective C?
Apart from the above reasons, if you know and love C++ then you won't feel so restricted by Objective-C.
There are a lot of concepts that are common to both Objective-C and C++ (same ideas but different way of doing things), but there is a whole bunch of stuff in C++ that isn't in Objective C, and, at least in theory, is very useful.
b e n
There are a lot of concepts that are common to both Objective-C and C++ (same ideas but different way of doing things), but there is a whole bunch of stuff in C++ that isn't in Objective C, and, at least in theory, is very useful.
b e n
"Object orientation" is just one of the paradigms C++ adds to C. There is also "generic programming" and even a hint of "funtional programming".
C++ is quite a language, really.
At the risk of some duplication of valid responses 
You've already witnessed the 'mix' of C and objective-C within the same source file, primarily because objective-C relies upon C. One might state that as objective-C extends C, is a superset of C, lots of ways to put that. My point is that objective-C is a unique language component, and the portion that is unique isn't complete enough to write an application. That is, you can't confine yourself entirely to the objective-C component of syntax, you must use the incorporated C lexicon.
From that perspective, it isn't much of a leap to assume that one might as well state that C++ lexicon is just as valid, yet a better choice than C, as that 'backdrop' or 'parental' language component to objective-C. The C 'level' of 'parental' language lexicon isn't object oriented, but C++ is. For all that's good about objective-C, there are, really, more features in C++ for expressing and implementing object designs which don't appear in objective-C. One might argue there are objective-C counterparts, but like other posters pointed out, the libraries appearing for C++ development, especially boost, are important enough that choosing not to avail oneself of them is probably a detriment.
There are caveats and issues, though, and it's worth considering whether or not one is willing to accept them. C++ is a serious, deep study. It's one of the legitimate complaints about the language. Intermediate to entry level advanced developers have more trouble with C++ than they would with other languages like Java, C# or objective-C. To that end, any tool that is 'more trouble than it's worth' is, well, not worth the trouble. I read and hear a lot of developers claim knowledge of C++, but I discover they know less than half what they think they do about C++, and it gives them either the position that it's not a good language (some even say awful), or that it's the best language. It's neither, because it's not really about the language.
Exceptions in objective-C aren't compatible with exceptions in C++. That's a serious problem for less than advanced developers who aren't familiar with the intricacies of exceptions on both languages. The problem is manageable, but one must understand it well in order to manage the issue. Exceptions in C++ must be kept separate from objective-C code, and the reverse must be held true too. This is fine because the general guideline is that any interface between modules should have exception boundaries, even if the work is entirely within C++. Treating the boundary between C++ and objective-C code like any boundary between modules is generally good design, because this boundary represents a separation of interface to application logic anyway.
Anyone more interested in staying entirely within objective-C or entirely within C++ is choosing to stay safe within their known language, and that's a good choice for them.
In my own view, the only place where objective-C should meet C++ is in a framework designed to provide AppKit and related frameworks from cocoa to C++ applications, but then I'm focused on portable code.
For an objective-C developer, the issue of exceptions in C++ vs objective-C must be understood before launching into the use of C++ as a better replacement for C as the parental language.
Of course, some would simply forgo exceptions altogether, but that, too, is a mistake.
You've already witnessed the 'mix' of C and objective-C within the same source file, primarily because objective-C relies upon C. One might state that as objective-C extends C, is a superset of C, lots of ways to put that. My point is that objective-C is a unique language component, and the portion that is unique isn't complete enough to write an application. That is, you can't confine yourself entirely to the objective-C component of syntax, you must use the incorporated C lexicon.
From that perspective, it isn't much of a leap to assume that one might as well state that C++ lexicon is just as valid, yet a better choice than C, as that 'backdrop' or 'parental' language component to objective-C. The C 'level' of 'parental' language lexicon isn't object oriented, but C++ is. For all that's good about objective-C, there are, really, more features in C++ for expressing and implementing object designs which don't appear in objective-C. One might argue there are objective-C counterparts, but like other posters pointed out, the libraries appearing for C++ development, especially boost, are important enough that choosing not to avail oneself of them is probably a detriment.
There are caveats and issues, though, and it's worth considering whether or not one is willing to accept them. C++ is a serious, deep study. It's one of the legitimate complaints about the language. Intermediate to entry level advanced developers have more trouble with C++ than they would with other languages like Java, C# or objective-C. To that end, any tool that is 'more trouble than it's worth' is, well, not worth the trouble. I read and hear a lot of developers claim knowledge of C++, but I discover they know less than half what they think they do about C++, and it gives them either the position that it's not a good language (some even say awful), or that it's the best language. It's neither, because it's not really about the language.
Exceptions in objective-C aren't compatible with exceptions in C++. That's a serious problem for less than advanced developers who aren't familiar with the intricacies of exceptions on both languages. The problem is manageable, but one must understand it well in order to manage the issue. Exceptions in C++ must be kept separate from objective-C code, and the reverse must be held true too. This is fine because the general guideline is that any interface between modules should have exception boundaries, even if the work is entirely within C++. Treating the boundary between C++ and objective-C code like any boundary between modules is generally good design, because this boundary represents a separation of interface to application logic anyway.
Anyone more interested in staying entirely within objective-C or entirely within C++ is choosing to stay safe within their known language, and that's a good choice for them.
In my own view, the only place where objective-C should meet C++ is in a framework designed to provide AppKit and related frameworks from cocoa to C++ applications, but then I'm focused on portable code.
For an objective-C developer, the issue of exceptions in C++ vs objective-C must be understood before launching into the use of C++ as a better replacement for C as the parental language.
Of course, some would simply forgo exceptions altogether, but that, too, is a mistake.
I've had that same question on my mind, too.
I get the impression that exceptions in objective-C follow a design that is much older than what is currently used in C++. I find it difficult to provide even the basic guarantee just yet.
It seems that catches have to be rather explicit about what to do, and so far as I can see the assumption is that you're probably going to exit/abort rather than continue.
I'm still studying this part myself.
I get the impression that exceptions in objective-C follow a design that is much older than what is currently used in C++. I find it difficult to provide even the basic guarantee just yet.
It seems that catches have to be rather explicit about what to do, and so far as I can see the assumption is that you're probably going to exit/abort rather than continue.
I'm still studying this part myself.
Carefully
Seriously, do you mean safe in terms freeing allocated resources?
Objective-C code needs to take a direct hand in freeing resources that would otherwise be leaked--this is true in case of exceptions or not. The @finally clause helps.
At the risk of answering for Sander, which I shouldn't do:
"Exception-safe" is a term used to describe the pre-post conditions of a function in the presence of an exception. It does apply to freeing resources, but also to other points regarding application work as well. For example, say you have two instance variables (member variables in C++), and you're about to perform a copy inside a 'copy function' of that object, you've been given a reference (C++ parlance) to a source object for the copy.
Tempted to be quick about this, one might say:
a = s.a;
b = s.b;
Assuming that a and b are the instance variables, and s is the source object. This code isn't exception safe.
Exception safe functions must offer one of 3 guarantees in the presence of exceptions. The basic guarantee, the strong guarantee and the no-fail guarantee. In C++, we must insist that destructors can't fail. If they're written in any way that can raise an exception, the program can't be 'valid' from the standpoint of exceptions. I'd have to point you to the literature to investigate more, lest this post turn into a chapter on the subject.
In case it's puzzling as to why a simple copy of a couple of instance variables might not be 'exception-safe', consider as an example that (especially in C++) the copy of b = s.b raises an exception. The value of a was already modified, and the value of b is it's former state. The object is now invalid, it can't be used anymore. There could, obviously, be circumstances where b's unassigned condition isn't consequential enough to be a problem, but we're not talking about specific circumstances. We're talking about any/all circumstances, the way engineers approach professional code.
The only way to make the copy exception safe is to assume that there exists a 'swap' function that's guaranteed not to fail, just like a destructor is guaranteed not to fail. Without this assumption, a copy can't be made exception safe. Instead of assigning each instance variable in order, from the source to the 'this' or 'self' members, a temporary should be used.
obj t;
t.a = s.a;
t.b = s.b;
If this doesn't throw an exception, the swap can be performed afterwards without causing a problem. The swap will be performed between 'this' (or self) and the temporary.
The reason is that if t.b = s.b fired an exception, and the function exits, the object performing this operation is exactly in the condition it was in before this happened. If it's part of data which should be saved in a complex document (say a CAD file), it's still valid. Without exception safety techniques, it wouldn't be possible to guarantee we could save the user's work before a 'graceful' exit, should that be the only course to take from this point out.
Exception-safe coding techniques are a study by themselves, and engineers that use the techniques (and insist upon them as coding standards) generate code that's more stable, robust and reliable.
One of the more surprising aspects of 'exception-safe' coding in C++ is that many times you're considering exceptions and their implications in functions that have no try/catch clauses of any kind.
The issue of stack unwinding, and object destruction, in the presence of exceptions IS about allocated resources, but more generally about the preservation of the state of the application even when an exception occurs. The possibility of 'surviving' an exception increases dramatically when 'exception-safe' techniques are used.
I've had "Exceptional C++" on my bedside table for a while, so I also know about the various guarantees. I didn't expect Objective-C-people to know them too, so I focused on RAII for now (because it's so useful even without exceptions).
Reading Objective-C code with all this manual release stuff makes me really appreciate C++'s scoping and ctor/dtor paradigm.
Reading Objective-C code with all this manual release stuff makes me really appreciate C++'s scoping and ctor/dtor paradigm.