Cocoa mail archive
Re: Where to include header files - relates to last question on variable scope
FROM : Don Arbow
DATE : Tue Nov 02 17:33:04 2004
On Oct 31, 2004, at 2:25 PM, Ole Voß wrote:
> Yes, that does sound feasible but I would still have to re-include
> this header file in every class that I use it in?
>
> I'm just spoilt because I've been programming Perl for over five years
> now and that language just does everything for you ;-)
Just to reiterate on this thread's point. If you've been programming
Perl for that long, you must know that you need to 'require' or 'use' a
CPAN module in a script before you can use any functions of that
module. This is roughly equivalent to what you must do in C, C++, ObjC,
(or Java for that matter). The big difference being that Perl doesn't
have a separate header file, the module must be compiled into the
script in order to know the names of the functions (yes, Perl can
autoload routines whose names are unknown at compile time, but this
slows down execution).
Sure, you can use something like a precompiled header file or just one
uber header that declares everything. But, precompiled files are better
suited for things like system headers (such as Foundation and AppKit)
since they change much less frequently than your project's source
files. As your project gets bigger, your compilation times will
increase because just changing a semicolon in that one header causes
every file in your project to have to be compiled, like starting from
scratch each time. If your project only has a dozen or so files, it
doesn't seem to be that big of a deal. But in mega projects, having to
wait an hour to recompile after making a minor change is something that
becomes tedious very quickly.
The concept of separate header files is something that you should
embrace. It's not such a burden to have to include (import) the headers
only where they will be used. Having separate header files is a good
thing and cuts down on your compile, link, test times. I think it also
helps to crystalize the project's design and guide you to thinking in a
more object oriented modular way.
I'm not picking on you, but many times I see newbies come into an arena
and declare "This is stupid", as if the people who came before them
designed the system to purposefully confuse newbies. Remember, there
are lots of smart people who have come before you and they have come up
with these concepts in order to make their workflow much more
productive.
Don
DATE : Tue Nov 02 17:33:04 2004
On Oct 31, 2004, at 2:25 PM, Ole Voß wrote:
> Yes, that does sound feasible but I would still have to re-include
> this header file in every class that I use it in?
>
> I'm just spoilt because I've been programming Perl for over five years
> now and that language just does everything for you ;-)
Just to reiterate on this thread's point. If you've been programming
Perl for that long, you must know that you need to 'require' or 'use' a
CPAN module in a script before you can use any functions of that
module. This is roughly equivalent to what you must do in C, C++, ObjC,
(or Java for that matter). The big difference being that Perl doesn't
have a separate header file, the module must be compiled into the
script in order to know the names of the functions (yes, Perl can
autoload routines whose names are unknown at compile time, but this
slows down execution).
Sure, you can use something like a precompiled header file or just one
uber header that declares everything. But, precompiled files are better
suited for things like system headers (such as Foundation and AppKit)
since they change much less frequently than your project's source
files. As your project gets bigger, your compilation times will
increase because just changing a semicolon in that one header causes
every file in your project to have to be compiled, like starting from
scratch each time. If your project only has a dozen or so files, it
doesn't seem to be that big of a deal. But in mega projects, having to
wait an hour to recompile after making a minor change is something that
becomes tedious very quickly.
The concept of separate header files is something that you should
embrace. It's not such a burden to have to include (import) the headers
only where they will be used. Having separate header files is a good
thing and cuts down on your compile, link, test times. I think it also
helps to crystalize the project's design and guide you to thinking in a
more object oriented modular way.
I'm not picking on you, but many times I see newbies come into an arena
and declare "This is stupid", as if the people who came before them
designed the system to purposefully confuse newbies. Remember, there
are lots of smart people who have come before you and they have come up
with these concepts in order to make their workflow much more
productive.
Don
