Re: Precompiled headers
Re: Precompiled headers
- Subject: Re: Precompiled headers
- From: Fritz Anderson <email@hidden>
- Date: Thu, 27 Nov 2014 23:45:50 -0500
On Nov 26, 2014, at 7:03 PM, Quincey Morris <email@hidden> wrote:Follow-up questions for extra credit:
— Is there now an emerging trend to use @import in place of #import <> (for code that doesn’t need backward compatibility, of course)?
I haven’t done a survey, but I do it. You see the encouragement in the new-target templates; and the equivalent of @import is the only mechanism Swift uses for importing API and directing linkage. I assume that from here on, module imports are the way Apple thinks about frameworks, and #import-and-link-library will be a concession to compatibility.
You’ve read what’s on the box: Faster, smarter, more-stable precompilation; better control over leakage of internal symbols; elimination of #include-order dependencies; cross-header #define dependencies eliminated so far as the @importing code is concerned.
I have yet to run into a downside from the feature when it is working as intended.
— Does the linker support automatic linking of frameworks mentioned in module @/#import statements? The clang web site describes this as not universally supported, but I don’t know if Apple’s ld does it, or for that matter whether Xcode provides the behavior even if ld doesn’t.
It does, again with the “when working as intended” caveat. This is not Xcode behaving-as-if. If you @import Foundation and CoreData in main.m of a command-line tool (taking care to create an NSManagedObjectContext and NSLog() the pointer so there’s no question of optimizing it away), the file will compile and run as expected, even though the frameworks don’t appear in the build phases, nor the strings “foun” or “core” in the build transcript
— F
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden