Content deleted Content added
→C++: C++ has nice ABI coupling with C, but doesn't guarantee API compatibility |
|||
Line 41:
*** You at least need to ''extern "C" {}'' the callee and include the C header. [[Special:Contributions/24.243.3.27|24.243.3.27]] ([[User talk:24.243.3.27|talk]]) 08:50, 24 March 2009 (UTC)
**** Still one of the big advantages of C++ is you can usuaully just include the C header in an extern "C" block (unless the C header trys to get really fancy). With most other languages you have to actually translate the imports (and home the library authors don't change them. [[User:Plugwash|Plugwash]] ([[User talk:Plugwash|talk]]) 19:46, 24 April 2009 (UTC)
***** How does C++ prevent upstream from changing the library API? Sure, you get the functions for free by including the header, but if upstream changes the API on you, you get something like "implicit redefinition of function foo: original definition was in foo.h". But I agree that C++ has the tightest binding to the C ABI. So while it is not a ''Con'' against C++, it is still a ''Pro'' for Vala that it has a nice FFI for C. [[Special:Contributions/64.234.67.2|64.234.67.2]] ([[User talk:64.234.67.2|talk]]) 05:09, 27 May 2009 (UTC)
* Vala also makes it easy to write C libraries -- you can use Vala to write libraries, compile them to C files, then distribute the C files. Vala can even generate a VAPI for the library along with the C files, so that you can use the compiled library from Vala -- i.e., you can use Vala to write a C library that can be used from any application with a C ABI and natively from Vala itself (the tutorial shows an example of this near the bottom).
* Since it is so tightly coupled with Glib/Gobject it obviously make it easier working with libraries that also use GLib/GObject.
| |||