Re: Newbie question: Can't get Xcode "Build & Run" to run
Re: Newbie question: Can't get Xcode "Build & Run" to run
- Subject: Re: Newbie question: Can't get Xcode "Build & Run" to run
- From: Michael Crawford <email@hidden>
- Date: Fri, 22 May 2009 13:26:53 -0700
On Fri, May 22, 2009 at 10:30 AM, Chris Espinosa <email@hidden> wrote:
> On May 22, 2009, at 3:19 AM, Michael Crawford wrote:
> My advice is to avoid using precompiled headers at all until you're
> completely certain of what you're doing.
>
> Michael, I continue to wonder why you advise people to disable precompiled
> headers, when it's the default for every Xcode installation (and has been
> for most of the decade), and is used with a high degree of success by
> literally hundreds of thousands of Xcode developers?
It's not at all a problem with Xcode. As far as I can tell, Xcode's
implementation of precompilation works just fine. I apologize if my
advice made you feel that I was criticizing your craftsmanship.
There were many years in which I always used precompiled headers, all
the way back to ThinkC.
What changed my mind was reading John Lakos' book Large Scale C++
Software Design, in which he devoted a great many pages to discussions
of the physical structure of one's code base.
He specifically makes a case for not including any header merely as a
convenience. Rather, a header should be included only if it is
absolutely *required* to compile the file in which it is included.
When one implements a C++ class, the very *first* header in the cpp
file should be the one containing the class declaration, with no other
headers ahead of it, just to make certain that it can compile without
extra help. That is, the class declaration comes before any standard
library headers.
It's a pretty weighty book, but very much worth that weight in gold.
I recommend it to every programmer - even if you don't use C++, the
majority of its advice applies to just about every language.
Following Lakos' advice not only cuts down build times considerably -
thus making precompiles unnecessary - but it also makes your code
easier to understand, to test, and to debug.
With or without precompiled headers, I always avoid:
#include <Carbon/Carbon.h>
Instead, when I need a framework header, I only include the specific
one I need. This takes some extra work in setting up one's Xcode
projects, because internal frameworks aren't found by default, but it
can be handled by setting the framework search paths appropriately.
I hope this clears things up. I meant no offense, really! Xcode is a
fine product these days - it has come a *long* ways since Project
Builder, and I happily use it every day.
Mike
--
Michael David Crawford
mdcrawford at gmail dot com
GoingWare's Bag of Programming Tricks
http://www.goingware.com/tips/
_______________________________________________
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