As the title says... are they considered different languages? For example if you've written an application using a combination of C++ and Objective-C++ would you consider it to have been written in C++ and Objective-C, C++ and Objective-C++ or all three?
Obviously C and C++ are different languages even though C++ and C are directly compatible, how is the situation with Objective-C++ and Objective-C?
From: https://en.wikipedia.org/wiki/Objective-C#Objective-C.2B.2B
Objective-C++ is a front-end to the GNU Compiler Collection, which can compile source files which use a combination of C++ and Objective-C syntax. Objective-C++ adds to C++ the extensions Objective-C adds to C. As nothing is done to unify the semantics behind the various language features, certain restrictions apply:
A C++ class cannot derive from an Objective-C class and vice versa.
C++ namespaces cannot be declared inside an Objective-C declaration.
Objective-C classes cannot have instance variables of C++ classes which do not have a default constructor or which 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++ object’s scope). The new 64-bit runtime resolves this by introducing interoperability with C++ exceptions in this sense
Objective-C++ simply allows Objective-C and C++ code to be mixed (with caveats). It's not really a language on its own so much as a mechanism for allowing the two languages to intermix.
C and C++ are not directly compatible. Neither is a superset of the other (though most C is valid C++). Objective-C is a strict superset of C, and Objective-C++ is a strict superset of C++. Those are the only statements you can make (except trivially reversing it).
It's hard to answer this question confidently without understanding what definition of "different language" you want to apply.
Objective-C is a superset of C: it adds some additional syntax on top of the C language. Objective-C++ is a superset of C++ in the same way.
C and C++ are actually different languages. Although C++ is designed to be compatible, there is some C that is not valid C++, and vice versa.
So, I'd say, yes, Objective-C++ is a different language from Objective-C, because C++ is a different language from C. However, I wouldn't call them totally different.
At first glance, using the Objective-C++ dialect looks like a straightforward approach. It is the result of mashing C++ and Objective-C together in the same compiler, and robust implementations exist in GCC and now clang. Considering just how different the details of Objective-C and C++ are, the GCC hackers have done a great job of it. But as you start renaming your .m files to .mm to introduce chunks of C++, you quickly realise it's not quite so simple.
Header files and the C preprocessor in general have caused headaches for C, C++ and Objective-C programmers for decades. It gets worse when you try to mix the languages. Say you wanted to use the STL's map in an Objective-C class in your project. Apple's Foundation libraries to my knowledge don't contain a sorted, tree-based map; one of our StyleKit Components needs exactly that, for example. So we simply create an instance variable for the map in our class and away we go:
#include <map>
#interface MyClass : NSObject {
#private
std::map<int, id> lookupTable;
}
// ...
#end
However, std::map [2] only makes sense to a C++-aware compiler, and only after an #include [3], so this header now can only be #imported from Objective-C++ files. Any code using this class now needs to be converted to Objective-C++ itself, and importing from other headers leads to a cascade effect that quickly encompasses the whole project.
In some cases, this may be acceptable. However, switching a whole project or large parts of it across just to introduce a library which is used in one location is not only excessive; if you're the only one who knows C++ on a project with multiple Objective-C programmers, you might find this to be an unpopular idea. It might also cause issues in the same way that compiling pure C code with a C++ compiler rarely is completely hassle-free. Moreover, it means that code isn't automatically reusable in other Objective-C projects.
So it's always better not to mix up unless it's so important
To know more about strategies for using objective c++ in objective c and vice versa click here
Objective-C is probably the official term that you would put in a resume.
Objective-C++ is not really a new language, it just specifies a few things that allow Objective-C code to co-exist with C++ code. Saying your app was written in Objective-C and C++ or just Objective-C++ is probably what you want. Putting all of Objective-C, Objective-C++, C++ is redundant.
Related
I'm taking a class on Object Oriented Programming in C++. In a recent assignment I defined a member function within a struct. My instructor explained that, although it's compilable to use member functions within structs, he would prefer we didn't, for backward compatibility with C, and (especially in this beginner class) to practice good data encapsulation- we should use a struct for types that contain mostly data, and a class for applications that benefit from more procedural encapsulation. He indicated that this practice comes from the history of structs/classes in C++, which is what I'd like to know more about.
I know that structs are functionally the same as classes except for default member/inheritance access. My question is:
Why are structs AND classes included in C++? From my background in C#, where structs and classes have important differences, it seems like struct in C++ is just syntactic sugar for defining classes with default public-ness. Is it?
I'm not looking for opinions on when/why one should be used instead of the other- I was born well after these constructs were, and I'm looking for the history of them. Were they conceived together? If so, why? If not, which came first, and why was the second added? I realize that there are many venerable elders within this community who may have living memory of these features' origins, and links to standards publications, or examples of code, where both, one, or the other first appeared, will add to answers' helpfulness.
Please note, this question is not:
What are the differences between struct and class in C++?
C++ Structs with Member Functions vs. Classes with Public Variables
Can C++ struct have member functions?
nor Function for C++ struct
To ease development of polyglot headers.
C and C++ are separate languages, but the C++ language is designed to provide a large useful common subset with the C language. Several commonly used constructions in the C++ language have the same meaning (or nearly so) as they have in the C language. In the case of struct, the C++ language defines it as syntactic sugar for class that approximates the behavior of a struct in the C language, namely that members are public by default. Thus a program or part thereof can be written in this common subset. This allows, for example, a library to provide a single header file that declares the same API to both programs written in the C language and programs written in the C++ language.
Some differences between the C language and the C++ language are listed in a question that has since been closed as too broad. From the perspective of somebody programming in this common subset language, these differences can be treated as "implementation-defined behavior", where compilers for the C language produce one behavior and compilers for the C++ language produce the other.
In fact, the C++ standard provides mechanisms to aid development of polyglot programs that are valid in both C and C++ languages. The extern "C" linkage specifier allows a program to be written partly in C and partly in C++. And the __cplusplus symbol is used in #ifdef __cplusplus conditions to conditionally enable macros, linkage specifiers, and other specifics that only one of the two languages is supposed to see.
In the old days (late 1980s or early 1990s), a C++ compiler (then called cfront) translated C++ code to C code. That C++ was widely different from current C++11 or C++14 (or even old C++03).
I don't remember the details, but it could have happened that struct at that time was parsed completely, but passed unchanged into the generated C code, while class was preprocessed to something different (and was translated to a struct).
I might be completely wrong, this is from my human memory, and I only used (on SunOS3, Sun3/160 workstations) a couple of times that cfront. It left me unimpressed, but interested. At that time, the translation to C code added a significant time to the build process. But things have changed a lot, translating to C makes a lot of sense today...
(In those days, a hello world program in Ada took 5 minutes to compile, and with cfront it might be 3 minutes, but in C it was less than a minute)
Later on, the definition of C++ changed, and struct foo { was indeed equivalent to class foo{ public:, but I am not sure that was the case in the primordial C++ compiler.
Both were included in the original C++ language, but struct long predates C++ in the C language.
C++ includes structs because it inherited them from C. There was no reason to remove them from C++ and break existing C code bases that may be compiled with a C++ compiler.
C++ introduces class as a new keyword. Presumably the keyword was introduced to provide the option of differentiating newly created C++ classes from existing structs in legacy C code bases.
C++ is mostly a superset of C. So (mostly) if you can do something in C you can do it in C++. Structs are a C feature and were included in C++. Refer to this for the reasons C++ isn't a true superset: Where is C not a subset of C++?
I'm trying to develop an application that can "stack" FITS images. To read FITS images I can either use CCFits (a C++ library) or CFITSIO (A C library) - there is no native Objective-C library.
I would prefer to use CCFits as it allows object-oriented design which I'm hoping will allow me to organize the program better. I've already tried to use CFITSIO but it gets rather unwieldy after a while (of course, this could be because of my inexperience in developing large applications).
So overall, what's the best way to approach this? Should I write wrappers for the CFITSIO functions and write my own classes? Is there a way to use C++ classes in Objective-C - the library contains quite a few classes and I know I can use opaque pointers to wrap around the classes, but how would things like class inheritance be preserved? Will I have to subclass a class in Objective-C manually and wrap the subclass there?
You can easily mix C++ and Objective-C using Objective-C++. In XCode just rename your .m files to .mm and it will recognize the files as Objective-C++. Then you can use the C++ classes in your Objective-C code (some restrictions apply, but not many).
Since Objective-C is an extension to C you can use C libraries in any Objective-C program easily.
Mixing C++ and Objective-C is easy, as #myrkos says.
However do make sure you read up carefully how the two languages interact.
In particular you cannot inherit an Objective-C class from a C++ class, or vice-versa (which you seem to allude to in your question).
That's not usually an issue in practice.
They compose very nicely, however (that is you can have an Objective-C object as a member of a C++ class and vice-versa - as long as it's all in a .mm file).
If you hold a C++ object as an ivar of an Objective-C class by value then constructors and destructors will be called for you automatically.
So overall, what's the best way to approach this?
Use the variant you are comfortable with (CCFits).
Should I write wrappers for the CFITSIO functions and write my own classes?
No.
Is there a way to use C++ classes in Objective-C - the library contains quite a few classes and I know I can use opaque pointers to wrap around the classes, but how would things like class inheritance be preserved?
Objective-C++ allows you to use C, Objective-C, and C++ programs in the same translation with very few issues. Therefore, your implementations can mix Cocoa and C++ as needed. C++ classes can hold ObjC types, and ObjC types can hold C++ types.
Will I have to subclass a class in Objective-C manually and wrap the subclass there?
Just use the CCFits library as-is. There is little to gain by wrapping it in ObjC types, and a lot of time to lose.
If you want to stick with strict ObjC in some areas, then you will need to learn how to hide C++ types behind ObjC interfaces (not a wrapper interface -- just a high level interface for your app's usage of CCFits).
I want to know the difference between c++ and objective-c and objective-c++.
Can any one give me the difference and Can we use the c++ for iPhone development
Thank you,
Madan Mohan
C++ is Bjarne Stroustroup's language based on adding classes and metaprogramming to C in such a way that puts most additional work into the compiler, and relies on least possible effort at runtime.
Objective-C is Brad Cox's language based on adding a SmallTalk-style dynamic message-passing runtime library to C, with a small amount of syntax addition to make it easier to use.
Objective-C++ is, to put it bluntly, what you get when you add the Objective-C runtime and syntax to C++. It has its limitations (e.g. you can't create an Objective-C subclass of a C++ class or vice versa, and Objective-C doesn't like C++ namespaces) but allows you to use C++ classes from Objective-C objects and vice versa.
You can use Objective-C++ in iPhone development. What this means practically is that you could write an application whose object model was entirely C++, where the controller layer would need to interface to Objective-C in order to use the Cocoa Touch APIs.
C++ and Objective C were/are two different approaches to adding object orientation to C. Current objective C compilers also accept C++ as input, so you can build a program with some files written in Objective-C and other files written in C++. When C++ is used this way, it's often called Objective-C++.
1) C++ is a language derived from C that adds Object Orientation (OO) amongst other features. *
2) Objective-C is a language derived from C that adds Object Orientation (OO) amongst other features. *
3) Objective-C++ is Objective-C that you can use C++ classes with.
You CAN use C++ for iPhone development but you will need "some" Objective-C code to interface with the iPhone libraries.
(*) Though they both try to solve the same problem they do it quite differently. There is some information about the differences on wikipedia and I'm sure you can use google to find more.
You CAN use C++ for iPhone development but you will need "some" Objective-C code to interface with the iPhone libraries.
This will very likely give you code and possibly memory bloat. As you know, iOS programming should be a lean as possible: minimize both the library size and runtime memory needs. iOS programming and runtime environments are also highly optimized for Objective C.
Pure ObjC is much better than C++ for iOS. Unless you're trying to use existing large C++ code base it will probably be better to re-write from scratch. Nearly all of the C++ STL have analogs in the iOS frameworks, often easier to use, and highly optimized by Apple.
Learn Objective C memory management, get familiar with the frameworks and go for it.
Are there any high level language that don't support using C++ libraries?
Using C++ libraries from other high-level languages has a couple of major obstacles:
if the library is OO, you need to be able to create a C++ object in the calling language - this is not easy.
C++ implementations use a technique known as "name-mangling" to ensure type-safe linkage. Unfortunately, there is no standard for name mangling, so C++ code cannot even easily be called between different C++ implementations.
So the answer to your question is that most HLLs will have problems calling C++ code. They may also have problems calling any other language of course - there are actually no standardised binary interfaces between languages, except ad hoc, platform-specifc ones.
I can't think of any language that is able to use C++ libraries directly. Even getting C++ to do it can be tricky (if the library was compiled with a different compiler than you're using)
Of course, if you write a wrapper of some kind (either a wrapper for the specific library, or some kind of bindings library that lets you expose specific types), then any language can use C++ libraries. But directly, as-is, with no extra work? I don't think any language other than C++ can do it.
This is a bit of an anti-answer, but many popular high-level languages can have bindings to C++ library code created for them via swig (http://swig.org/).
I want to use some C++ STL collections in my Objective-C iPhone app. Apparently this is possible by giving files the extension ".mm" . What are some of the quirks/surprises associated with this?
I want to use the basic containers that I'm familiar with (vector, queue, set, ...)
Cheers!
See Using C++ With Objective-C for a detailed list of what you can and can't do. You can do most things that you would expect. You just can't do things like have a C++ class inherit from an Objective-C class or vice-versa, you can't mix C++ exceptions with Objective-C exceptions, and C++ introduces several new keywords not present in Objective-C.
The major quirk of Objective-C++ is that if you don't pass -fobjc-call-cxx-cdtors to g++, it won't call the constructor and destructor of C++ instance variables in of ObjC objects. So remember to turn that option on and you should be good.
The files will be compiled with the Objective-C++ compiler, so things will behave more like g++ than gcc, but since that's what you want it probably doesn't count as a surprise. From the Objective-C side, I'm not aware of any gotchas, and I've worked on several large projects that made significant used of Objective-C++. Just keep in mind that Objective-C reserved words are reserved in Objective-C++ as well, so you can occasionally run into issues with third-party C++ libraries (e.g., if they use "id" as a parameter in a public interface).
You'd be surprised how well it works. I haven't really gotten into any problems intermixing Obj-C and C++ in a .mm file.