Writing a library that needs to be object-orientated. Objective-C or C++ for the highest compatibility with C?_问答_开发者

I am planning to write an open-source library which really needs to be written in an object-orientated language. One problem is that the library should be possible to use with C, where it doesn't matter of direct inclusion of source code or (dynamic) linking to a precompiled library.

I know all three C++, C and Objective-C.

Objective-C is a superset of C (i.e. every C code, even the Linux kernel, should be able to be compiled as Objective-C); and therefor, it should work if the C application which uses the library is compiled as Objective-C (and I can include this in the usage instructions, of course).

C++ is not a superset of C, but it's more supported than Objective-C, and there are more C++ programmers and compilers than Objective-C's.

What should I do?

Are binaries written in C bigger or have lower performance if they 开发者_Go百科are compiled as Objective-C?

I think you are taking compatibility the wrong way. You don't want to compile your other code as Objective-C just because of that library.

If you need this library to work on any "C" platform, then C is the only way to go.

Many of those platforms support C++, too, so this would be a good choice in OO terms.

Objective-C is not that common on other platforms than Apple, and if you start using some special frameworks this might get you into trouble.

If you use C++, you probably want to keep the interfaces 'visible outside' (for the C applications using the library) C-compatible, e.g. declare them as

extern "C" {
 ...
}

and not make any classes etc. visible to the library user.

Another point: if you plan to have other people contribute to the project (you said it's open source), you'll more likely to find contributors who know C++ than contributors who know objective C.

Obj-C compilation is supported on pretty much everything, as it is part of gcc.

However, the big difference between Obj-C and C++, is that Obj-C also needs a runtime library. This is far less widely supported, and the GnuStep version lags behind the OS X one.

The dynamic nature of Obj-C makes it technically easier to write and compile cross-platform code, but in reality you need to understand exactly what methods are supported by the different target environments, because the compiler isn't going to trap them.

Also, GnuStep, Cocotron and Etoile - the 3 non-Apple Obj-C environments - only have niche take-up amongst Windows and Linux developers. This would reduce the take-up of your library to OS X developers and a very small number of developers on other platforms. Cocotron, for instance, is mostly used by OS X developers looking for a fast port to Windows, not by developers looking for a good x-platform tool.

Another option could be to look at Apple's own open source efforts on macosforge - CoreFoundation, WebKit, clang - or the structure of the OS and other third-party projects that have taken existing code and exposed to Obj-C.

A typical pattern is to have a core C or C++ project, which is then exposed via an Obj-C API.

People have also done the same with C++ and C - i.e. writing OO C++ code, but then exposing it to C via a procedural wrapper at the interface level. You may need to consider this if you expect your code to be linked in to plain C.

In summary - unless writing in Obj-C will simplify the design, and your audience is OS X/iOS developers, I would suggest going with C++ (you say the library needs to be written in an OO language) and then wrapping it with Obj-C at the top.

If it is for OS X/iOS only, I would go with Obj-C.

Another option could be completely ditching the C language requirement and going with a portable OO language like Python or Ruby, where there is a lively community of open source developers.

For object-oriented programming if you need the highest compatibility with C, then i recommend GObject which is an object-oriented library for C language.

http://en.wikipedia.org/wiki/GObject