Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Charles S. <bas...@ch...>]

On Jul 5, 2012, at 8:06 AM, Alexei Svitkine wrote:

> Could you point me at a reference that explains why @autoreleasepool would be more efficient than just managing one yourself?

Doesn’t say *why*, but Apple does claim that @autoreleasepool is about six times (!) faster:

http://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html%23//apple_ref/doc/uid/TP40011226-CH1-SW16

Presumably this would be done by avoiding the creation of actual objects (i.e. the NSAutoreleasePool instance and whatever internal storage it uses), and by using optimized versions of the retain and release methods. Maybe other dark magics as well; one would have to pore through the clang sources to find out exactly what it’s doing.

> Also, shouldn't the ifdef to use it be testing for the version of clang that added it? Some Googling reveals that it's not supported by older clang (e.g. the one shipped with Xcode 3.2).

Well, clang didn’t become the default compiler for Xcode until Xcode 4, as the early versions were not fully baked, so I have my doubts that anyone would still be using those old versions of clang. Nevertheless, you are correct; it would be best to check. unfortunately, clang doesn’t seem to have a __has_feature(()) macro for @autoreleasepool, which is the preferred way to check for these things, and the clang docs claim you’re not supposed to check the version number, since different vendors are apparently allowed to have different version numbering schemes (http://clang.llvm.org/docs/LanguageExtensions.html#builtinmacros). OTOH, since these files are Apple-specific, it’s probably safe *most* of the time to assume they’ll be using Apple’s version of clang and thus their numbering scheme. Not 100% though.

I guess we could add a ./configure check, or we could just put this off until we actually have LLVM/clang support working.

Charles