i was just curious to know if all the codes provided by Apple is the ios dev library, and by the forums are objective c or c++. What exactly is the difference between the two?
Which one works in Xcode?
Both Obj-C and C++ are extensions of the C language. Both wanted to do the same - extend C with objects.
C++ is much more complex and currently much more popular on every non-Apple system.
Both work in Xcode. Actually you can combine Obj-C and C++ in one program (Obj-C++).
The differences between the languages are great - objects are declared, allocated and freed differently. Not only the syntax is different, they were designed differently (Operator overriding, access rights, multiple inheritance, templates in C++; Message sending, categories, properties, reference counting, protocols in Obj-C).
It's hard to explain the differences, if you don't know anything about either of them.
Obj-C is easier to learn (it's much simpler).
For both languages, you need to know C well.
EDIT: most of the code in iOS dev library is either pure C or Obj-C
Related
While developing a new product, we decided to go for a mix of C++ and C#, haven been told that bridging them to allow the C# code to call the C++ code would be easy (spoiler, it's not).
We're pretty experienced C++ programmers and not at all C# programmers so we pretty much just had to believe what we've read. A few attempts to call C and Objective-C was promising and we even found a few articles that showed how to make an unmanaged C++ class available in C# -- or at least we thought. The C++ code in the articles, wasn't C++, but instead the horrible monster C++/CLI that Microsoft seems to think is C++. Since we're doing the C# stuff to get some bits "for free" in macOS and Windows, C++/CLI isn't an option either :-(.
Anyway, plenty of people have claimed that it's easy to call C++ code from some specific programming language, but so far, I haven't seen a single one that will allow me to do so (I haven't been paying too much attention to this, so please provide me with an obvious example). C++ invariably always means C with no C++ stuff at all; no namespaces, classes, no stl, lambdas or anything. Just plain dumb C.
So, are there any languages, besides C++(/CLI) that will allow me to do the following:
Create an instance of a class, using a C++ constructor, and dispatch it with a C++ destructor.
Call member functions on an object ( foo f; f.foo();) with a C++ class.
Use std::vector, std::find_if, std::string and other stuff from the stl. Complete coverage of the stl is not required.
Use overloaded functions (i.e. f(), f(int), f(std::string))
Use overloaded operators (foo operator + (foo, foo))
Use C++11, C++14 and/or C++17 features.
Use RAII (rather important IMHO).
Use namespaces.
No. There is no such language.
Unless you count Objective-C++. But that falls pretty much in the same bucket as C++/CLI, in being C++ with some extensions. And C++/CX is another such beast.
There are some interop tools that can work with C++ classes (SWIG for example), but I have never heard of a tool that is capable of instantiating C++ templates (like vector or find_if) on demand.
What languages will call C++ with no explicit bridging?
The short answer to this question is: NONE
Remember that a programming language is a specification written in some technical report, usually in English. For examples, read n1570 (the spec of C11) or R5RS (the spec of Scheme). For C++, see n3337.
Actually, you are interested in implementations, e.g. in compilers and interpreters for your programming languages. These implementations are practically software. And then the answer might become: it depends (notably on the ABI used & targetted by your compiler and system).
See for examples this list of ABIs for Linux.
plenty of people have claimed that it's easy to call C++ code from some specific programming language,
The C calling conventions are quite common, and it might help to declare every C++ function callable from outside as extern "C". But there is no silver bullet, and details matter a lot.
So, are there any languages, besides C++(/CLI) that will allow me to do the following:
list of C++ features skipped
Probably not.
You probably need at least to understand more about memory management approaches. I recommend understanding more about garbage collection, e.g. by reading the GC handbook (at least for underlying concepts & terminology). Learn more about foreign function interfaces (in some cases, the libffi might help) and language bindings.
You might also consider generating some of the C++ or C glue code, maybe with SWIG (or write your own C++ glue code generator).
On operating systems providing dynamic linking capable of loading plugins at runtime (e.g. Linux with dlopen(3)/dlsym(3); but other OSes often have similar facilities) you could even consider generating some C or C++ glue code at runtime in some temporary file, compile it as a temporary plugin, and dynamically loading that plugin. You could also consider JIT-compiling libraries like GCCJIT or LLVM (or libjit).
I recommend reading SICP, the Dragon Book, and probably Lisp In Small Pieces. Of course, learn something about OSes, e.g. Operating Systems: Three Easy Pieces. Reading about Linkers and Loaders could also help.
As an excellent example of cleverly gluing C++, look into CLASP and see this video.
But whatever approach you take, you'll need a lot of work (years, not weeks).
C++ as a language does not have a defined ABI (Application Binary Interface) - which basically means that there is no universal standard of what a C++ class/function call/template would look like in binary form on any given platform, or across platforms.
What that means is that there is no universal way to call C++ code from other languages, on different platforms, or even across compilers on the same platform. It also means that the people who are telling you "it's easy to call C++ code from XYZ language" are mostly incorrect (or at least incredibly incomplete).
Where there are interfaces it's either because the provider of the interface controls the ABI (C++/CLI with .NET), or because there is a translation layer from C++ to something like the C calling convention (Boost::python).
Some work has been done towards attempting to define an ABI per-platform (http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4028.pdf), but as far as I'm aware it has not yet been accepted into C++17.
You can look into using C++ interpreter, which allows for the fine-grained control you ask for. But I don't know of any that "just works", see also:
Have you used any of the C++ interpreters (not compilers)?
What does it offer to an object oriented language such as C++? or is it not possible to use GTK+ without it?
Is the GObject implementation of objects is of a similar quality to that of C++ in terms of the size and speed of an executable assuming both examples use the same compiler? Or are there some trade-offs where GObject would be slower on the account of additional capabilities it provides?
GObject (a bit like COM in the Windows world) is a C API designed with cross language interoperability in mind.
This means that you can use GObjects in any language which supports calling C functions, but this makes it very difficult to write GObjects in a non-C language which are truly reusable from any language (if you write a GObject derived class in say, Python, you'd have to embed a Python interpreter every time you wanted to use objects from this class in C).
It is possible to semi-automate the creation of bindings for many languages (eg. Python, Perl, JS etc), and here lies one of the strengths of GObject. This accounts for the somewhat opaque API that GObject provides, which is, I confess, quite difficult to understand thoroughly.
Unfortunately, it doesn't fit well within the C++ language either. GObjects have no trivial relationship with C++ classes, and even if bindings are available (Gtkmm) it is not possible to easily write a C++ class "inheriting from GObject" and expose it to the world. You have to write C for this.
[What the world would need would be some kind of extensions to the C++ language which would make it easy to interop with GObject, a little like C++Cx on Windows, but 1) it is a difficult task, perhaps achievable through a GCC plugin, and 2) there is no momentum towards C++ in the Gnome world, or generally in the Linux world (KDE being a notable exception). For now we are stuck with the Gtkmm bindings.]
The article on GObject from Wikipedia includes a comparison with C++. Some of the things they mention is the lack of multiple inheritance, and the presence of signals. Additionally, GObject benefits from the fact that the names of exported C functions do not, unlike C++, depend on your choice of compiler. So if you were to develop an object-oriented library using GObject, it would probably be easier to link with than a C++ one.
It would also be interesting to look at the Vala programming language, which targets GObject.
Just a little elaboration on something hinted by Vlad: A major point in favour of C is that it makes interoptability between compilers or languages 'possible' (guaranteed), in that it standardises an ABI. This (pardon me if I'm oversimplifying) enables guarantees about how callers from any C compiler or other language can use exported symbols. Hence why GTK+ has bindings to various other languages - including C++ in GTKmm. The latter is the best of both worlds IMHO: the well-established API of GTK+ but with the language features of C++.
C++ as yet does not have an official standard ABI, though all is not yet lost, as the A-Team are working on it: https://isocpp.org/files/papers/n4028.pdf
C and C++ are different languages, blababla we know that.
But if those language are different, why is it still possible to use function like malloc or free ? I'm sure there are all sort of dusty things C++ has because of C, but since C++ is another language, why not remove those things to make it a little less bloat and more clean and clear ?
Is it because it allows programmers to work without the OO model or because some compilers doesn't support high-level abstract features of C++ ?
Because C++ would be right out dead if it wouldn't be compatible to C the way it is now. No one, except the fanbois, would like C++ if it wouldn't be compatible to C. (I know I'm probably going to be downvoted for this. Be it so!).
About "Why there's no "pure" C++ language... Well, there is at least one. The most popular one is called D, it's great, well-designed, feature-rich, pleasant to code with, and you can use C libraries with it.
Ah, and almost nobody uses it. :)
The direct reason is that C++ is not bad enough to give people a good reason to port millions of lines of their legacy code to more modern, and as you described, "pure" languages like D.
Most operating systems expose a C API, so if you want to use C++ for systems programming, you need some level of C interoperability.
That the C standard library was incorporated into the C++ standard library has historical and practical reasons: C++ began its life as an extension of C, and the C standard library was ready to use. It would be silly to exclude part of the library (like malloc and free) just because there are more idiomatic C++ alternatives: if you want to do stupid things, C++ gives you the power to do so.
For actual language semantics, the same applies - but to a lesser degree - and because of backwards-compatibility, C++ can never be entirely free of its C heritage.
It's designed so that you can port C code and compile it as C++ code directly, and it allows for incremental upgrading of existing code. If C++ didn't have malloc/free, you couldn't compile existing C code as C++, because you'd have to pay some poor shmuck to go through and find all the malloc calls and replace them, which is expensive.
C++ was designed to be compatible with C -- in fact it was originally a superset of C, but the C language has since changed to break that.
This means that C libraries -- including the C run-time library -- can be called from C++ code. It does not mean that it is a good idea to do so!
If you want a "pure" C++ then you can just use C++ without calling any C libraries.
[As others have said since I started typing this: The Design & Evolution of C++ is a good place to start reading for the background on this.]
I suggest you take a look at The Design & Evolution of C++ to get a better feel for the reason the language turned out the way it is. There are historical reasons why C++ grew out of C and was made backward compatible with it.
The early versions of C++ were built on top of C and in fact the compiler translated C++ code to C which was in turn compiled by the local C compiler. Bjarne Stroustrup is a great believer in backwards compatibility and would, I'm sure, resist any attempt to take functionality away.
You can read all about in in Bjarne's book The Design and Evolution of C++.
There were plenty of more pure languages. They didn't get widely used, though, because they were too far outside the comfort range of most programmers. C++, on the other hand, allowed programmers to slowly ramp up by allowing C styles.
What you're doing is looking at languages like C# or Python and wondering why C++ doesn't look like them, but forgetting that getting there required stepping stones like C++ and Java, or Awk and Perl.
To adapt a quotation I heard earlier: C# is Microsoft's version of Sun's for-idiots version of Bell's version of C-enhanced-by-Simula.
All are right. To sum up: the reason is politics. If you want something to be popular, enhance something already popular and you have a ready market. Design something new and no one will be interested unless you are Sun, design some utter crap, but throw billions of dollars into library development and marketing.
malloc() and free() are required so that you can call into C language libraries from C++ code. The C language library might return a pointer to memory allocated with malloc() that must be freed by the caller with free(); or, less commonly, it might require a pointer to memory allocated with malloc() that it can internally reallocate with realloc() or free with free().
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.
I would like to create a portable library for iPhone, that also could be used for other platforms.
My question is the fallowing:
Does anyone knows what is the best to be used on the iPhone: Objective-C or Objective-C++? Does it works with C++ the same way as Objective-C with C or not?
Reasons: Objective-C is a superset of C, but Objective-C++ is not a superset of C++.
Thanks in advance!
UPDATE: What about memory usage, speed in the same implementation of an use case?
UPDATE1: If anyone can provide any more information, he'll be welcome.
If you're writing a portable library, and don't need specific language features for it, why not write it in straight C? It can be easily called from C++, C, Objective-C, and many, many other languages.
If you require specific language features that aren't available in C, you should tell us what they are so you can get better advice =)
I believe your information is incorrect. Objective-C++ is a superset of C++. Any C++ is legal Objective-C++. In addition, you can mix Objective-C and C++ code in an Objective-C++ (usually .mm) file and (with some restrictions) mix Objective-C and C++ class instance variables within an Objective-C++ class. Objective-C++ is particularly useful for interfacing between Objective-C and a C++ library. Write your cross-platform library in C++. You can then call it from Objective-C++ within an application. Re-read the Objective-C++ section of the Objective-C language guide for more info.
The major downside to using Objective-C++ is increased compile times (Objective-C++ is even worse than C++ and the Clang LLVM compiler doesn't handle Objective-C++ yet). There is no performance difference between Objective-C and Objective-C++ beyond any differences in the code that's called (e.g. if you're a better C++ dev., your C++ will probably be more efficient than your C library and visa versa).
They're not really different languages. Objective-C++ is just Objective-C with slightly limited support for including C++ code. Objective-C is the standard dialect, but if you need to work with C++, there's no reason not to use it. AFAIK, the biggest practical difference (aside from allowing use of different libraries) is that Objective-C++ seems to compile a bit slower. Just be sure to read up on it first if you do decide to go that route, because the merging of C++ and Objective-C is not 100% seamless.
If you are going to use this library on platforms other than the iPhone and Mac OS, you should use C++. If you plan only to port it to Mac OS, then go ahead and use Objective-C. Objective-C++ is just a way to integrate existing C++ code into Objective-C projects. Thus, you would not write a library in it. You might, however, use Objective-C++ to use this library from an iPhone or Mac project.
The truth is you can use C or C++ in Xcode. The reason to use Objective C for Cocoa and Cocoa Touch (iphone) is because of it's ease of use and how it handles many of the memory issues you would come across on it's own. Objective C and Xcode work like a dream. I would also recommend checking out http://www.kevincallahan.org/software/accessorizer.html
Accessorizer is amazing and cuts development time into nothing.
Having said that I see no problem in writing functions/methods in C or C++ and using them within a part of your XCode project. Just do not expect to use Objective C to play as nicely on other platforms. Apple and Windows development IDE's are different and Microsoft has a nice habit for not making things as compatible with other environments (not just Apple.)
I am glad to hear someone out their trying to reuse their code for other projects : ) Too many people forget to create their own libraries these days and I haven't the slightest idea why.
I hope this helps. Cheers,
Matthew
Here is your caveat: Spend the hundred on becoming a developer and launch xcode the IDE you will be working with on the Mac - this would be the best way for you to decide as it is apparent that you do not fully understand how this platform works at all.
Please don't be rude to everyone trying to help you. This community is built on respect. The people here really actually do help out and care and there are few places like this on the net left.
Go for C or C++ - I do not see any reason for recommending one over the other without knowing more about your goals.
In terms of memory usage, C++ and C do demand more disciplined coding. In terms of speed, C and C++ will in virtually any case be faster than any ObjC/ObjC++ solution. I do frequently mix my Objective C applications with C and C++ code and was always pleased with the results. As Jonathan correctly stated, ObjectiveC++ is mostly a bridge for using C++ code/libraries within your Objective C application/s.
You can freely use C++ objects from within Objective C++. You can however NOT use Objective C/C++ objects within C++. So its a one-way-road. To overcome any limitations imposed by this restriction, simply wrap your C++ objects with Objective C++ classes where needed.
"Objective-C is a strict superset of C, and Objective-C++ is a strict superset of C++." - https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html