I've been looking at the D programming language and it looks like a lot of fun to try for someone already proficient in C++.
Can I use D to program to the Java Native Interface which is a C interface?
I don't know much about the JNI, but for functions declared extern(C), and using only C datatypes, D matches the C ABI, so the JNI should not even know the difference. You probably just need to translate a few headers to D, which can be partially automated with the htod utility.
I'm pretty sure it's possible (I have used D and C++/JNI).
You'd have to convert the JNI headers to D, and as JNI is ABI agnostic these headers don't even change much with new JDK releases.
The annoying part is that the javah utility does not generate D header files .di
Related
I have written a C++ library to do some numerical analysis. Is there a programmatic advantage to include a C API interface to the library in addition to the C++ API?
Is this isn't an appropriate question for stackoverflow I can delete it.
What has C over C++: a stable well-defined ABI.
There are multiple C++ ABIs (MSVC's and Itanium being the foremost) and each Standard Library implementation (Dirkumware, libstd++ or libc++ for examples) is incompatible with the others. Therefore, the only way for C++ code to correctly link with C++ code is to be compiled with the same compiler (or with compilers sharing the same ABI) and above the same Standard Library implementation.
C, however, is different. C compiled by gcc integrates smoothly with C compiled clang... but it goes well beyond. It integrates smoothly with C++, Python, Haskell, Java, Rust, Lua, Perl, ... most if not all "serious" languages can interact with C more or less smoothly.
So, what is the benefit of a C API over a C++ ? Smooth integration with virtually any programming language under the sun.
Yes, there is one: you need a C API if you would like to call your functions from C code. Unlike the C API, which can called also by your C++ code (extern "C" { ... }), this is not true for C++ API, which can't be call by your C code.
No there is no programmatic advantage to include a C API.
Guess it is down to marketing and what your customers want.
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
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.
Apart from C++, which non-toy languages have direct or easy-to-use compatibility to C? As in "I can take a C library out there, and compile my code against it without having to find, write, or configure some kind of wrapper."
I know that lots of languages have compatibility with C through some form of external call or binding (I've been using bindings in Java, Ruby, Python, etc., so I know it can be done). But you rely on someone (possibly you), to write and maintains a binding for all the libraries you want to use, and the binding has to works on all platforms, etc.
Do more expressive languages than C++ have this feature?
Thanks to all for the mentions of swig or related wrapper-generation tools.
I am aware that those exists, but I don't think they're really as easy as C->C++ integration... but then integrating with C might be the only thing that is easier in C++ ;) )
Objective-C, the bastard child of C and Smalltalk.
Objective-C is a direct superset of C (you can't get more compatible than that), but there are languages which compile to C. Some recent examples would be Vala and Lisaac.
Most statically compiled languages allow interfacing with C libraries. Examples of such languages are Ada, Fortran, Pascal and D. The details are platform and compiler specific; for x86, this basically means supporting the cdecl calling convention.
The D language is compatible with the C ABI. However, it's sometimes non-trivial to convert C header files into compatible D modules. See this page for more details.
Fortran can call C routines, or be called by C. This used to be "platform and compiler specific" as stated in another answer, but Fortran 2003 includes the "ISO C Binding", which makes this part of the language standard and therefore portable rather than platform and compiler specific. The ISO C Binding is supported by numerous Fortran compilers, including gfortran (>= 4.3), Intel ifort, Sun Fortran, etc.
You do have to write an "interface" description of a C routine being called, but it is compiler and platform independent.
For a lot of languages, wrapper code for C libraries are not hard to write - just use SWIG: http://www.swig.org/
While originally written as a quick wrapper generator for Tcl, it now supports:
Tcl, Python, Perl, Guile, Java, Ruby, Scheme, PHP, Ocaml, Pike, C#, Modula-3, Lua, Common Lisp, R and Octave.
If you use any of the language it supports, give it a try. For C functions that deals with strings, integers and floats it is very easy to use. For more complex C functions it obviously gets more complex.
With the right compilers/linkers, name mangling and function arguments, you can link C and Fortran modules. Details here.
Python has a dynamic wrapping module, ctypes, which, while it doesn't eliminate boilerplate binding code completely, does greatly reduce it.
G'day,
You can interface Perl onto C libraries by writing an XS interface between the two. Here's the perlXSTut over at CPAN.
This is how the XML::LibXML and XML::LibXSLT modules are implemented.
You can also interface Ada to C libraries buy means of pragma Import. This is also true for libraries written in C++. And COBOL and FORTRAN BTW.
HTH
cheers,
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