• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Warnings that won't go away
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Warnings that won't go away


  • Subject: Re: Warnings that won't go away
  • From: Daniel Jalkut <email@hidden>
  • Date: Wed, 30 Nov 2005 09:43:02 -0500

My "in a nutshell" advice is this:

1. Use #import whenever you can.
2. Use @class whenever you have to.

To slightly crack that nutshell open, the differences between #import and @class are gigantic. The #import directive is like pasting a copy of the entire header (or source, if you're wild and crazy) file into the content of your file. The @class directive is (used in this way) simply a "forward declaration" for a class that is defined elsewhere. It tells the compiler to "chill out" about a class name it doesn't recognize.

The argument for using @class is that "pasting" the whole header file into your own header can muck things up (by forcing clients to also take the "paste") or slow compiles down.

It's common to use @class in the header and #import in the implementation, to "lighten the load" on the header file of a class. Let's say your class "Bingo" has an instance variable of type "Booyah*", but none of your public methods take or return a "Booyah*" type. Importing "Booyah.h" to the class header isn't really doing anybody a favor, because the *client* of this class doesn't need the Booyah class! So you would typically declare Booyah in the header with a @class directive, while importing "Booyah.h" directly into the implementation source file. Now the dirty details of "Booyah.h" are confined to the implementation file and not spread out to all of the clients of your Bingo class.

Some people are more aggressive about "unloading" the header files. Me, I am lazy and I have a fairly fast compiler. I tend to #import in the header until and unless problems arise. I consider doing otherwise to be "premature optimization," because it takes work to figure out which @class declarations to make, while one #import will often take care of several classes in one swoop.

Daniel

On Nov 30, 2005, at 8:07 AM, Tom Jones wrote:

The problem was that I was not including the header file (Playlist.h).
Which leads to my next newbie question. What's the difference between
the @class directive and the #import directive...when should I use one
and not the other? I was using @class, and getting warnings. Do I need
to use #import when I am calling specific methods of my class, and use
@class when I want to instantiate a member variable of a particular
class?

_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Warnings that won't go away
      • From: Sherm Pendley <email@hidden>
    • Re: Warnings that won't go away
      • From: j o a r <email@hidden>
References: 
 >Warnings that won't go away (From: Tom Jones <email@hidden>)
 >Re: Warnings that won't go away (From: Sherm Pendley <email@hidden>)
 >Re: Warnings that won't go away (From: Tom Jones <email@hidden>)

  • Prev by Date: Re: How to interrupt a function
  • Next by Date: [SOLVED] Mixing cocoa and carbon crashing in photoshop plugin
  • Previous by thread: Re: Warnings that won't go away
  • Next by thread: Re: Warnings that won't go away
  • Index(es):
    • Date
    • Thread