On Nov 26, 2014, at 7:03 PM, Quincey Morris
<[email protected]> 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 protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to [email protected]
