This piece of code is from SubtitleKit, a library regarding processing different types of subtitle files. I occasionally use some features that does not exist in GCC or older versions of Clang so I used those boilerplates to make sure my code compiles under all my target platforms with minimal changes. My targets include OS X 10.7-10.9, iOS 5-7 and GNUstep SVN.
Sent from my iPhone I never needed something like what you wrote. That stuff belongs in a framework. If a compiler doesn't support an attribute that I need (and I typically don't need attributes), then I don't support the compiler.
Objective-C modules also doesn't really need anything special to expose C functions to modules written in C, except perhaps an extern "C" in case a header defining C functions is included by a C++ module.
So no, I don't typically have things like what you wrote down there :-) Regards,
Ivan Vučica via phone
I mean exposing a function or two from Objective-C code so that it can be accessed from other languages. There is no reason to prevent a function with signature CGIApplicationMain(int, const char **, const char *restrict, const char *restrict); from being exposed, right?
Also, the inline function wrapper for [NSString stringWithFormat:] can be really useful.
Sent from my iPhone Why...would anyone want to do that? The whole point of OOP is to hide details so as to allow programmers to concentrate on one thing at a time (while giving us the bonus of modular, reusable, easily maintainable code). Why would you want/need to unhide details?
|