🚀 go-pugleaf

"Steven Daedelus" <sdaedelus@ira.gov> wrote in message
news:sdaedelus-89709B.15582112012005@comcast.dca.giganews.com...
> Hi all,
>
> Help a fairly clueless guy: Let's say I add source1.cpp to a project. It
> refers to functionX defined in source2.cpp. Now, if I put include
> "source2.cpp" at the top of source1.cpp, it works ok. If I add
> source2.cpp to the project, it tells me that functionX is undefined.
>
> Perhaps I just don't understand linking. Could someone explain this to
> me?


When you #include "source2.cpp", you effectively add the entire file to the
beginning of source1.cpp. Everything in source2.cpp is compiled before
everything in source1.cpp, and it works.

When you add source2.cpp to the project, it is compiled separately and
linked in; however, source1.cpp no longer sees it (the error you're seeing
means that the compiler doesn't know what functionX is, and can't generate
code to call it: the linker isn't involved at this point, and the compiler
only sees what you tell it to.)


If you #include source2.cpp everywhere it's referenced, it  willl work but
source2.cpp will have to be compiled every time a file that #include's it is
Any changes to source2.cpp would force every file that #included it to be
rebuilt as well
Your binary might not get bigger (modern linkers are pretty good at spotting
redundant code and removing it) but your build times will increase.


You should:
Add source2.cpp to your project: that way it gets compiled once
#include source2.h (which should at least include a declaration of
functionX) to every file that needs it. That way the compiler knows
functionX is defined and the linker will look for and reference it properly.
Now you can change source2.cpp without forcing anything else to recompile
(as long as the declarations in source2.h don't change.)

Another way is to declare functionX extern in source1.cpp. This simply tells
the compiler that the function is defined and prevents an error, and the
linker takes care of locating the right code in source2.cpp. This isn't
generally a good idea for several reasons, notably that you will have
trouble if functionX's declaration ever changes (you'll have to hunt down
every single extern declaration and fix it, instead of fixing it once in
source2.h.)


This is just the way C works: a separate header that lets files refer to
each other (a type of forward declaration.) Pascal and other
module-structured languages handle this by effectively generating their own
headers from the source code and #including it automatically. there have
been several attempts to do this with C-style languages (google MakeHeaders,
for example, but it's pretty limited w/ C++.)

In article <vRgFd.4749$KJ2.3072@newsread3.news.atl.earthlink.net>,
 "Paul" <remove_this_its_just_paul@patchdance.com> wrote:

> "Steven Daedelus" <sdaedelus@ira.gov> wrote in message
> news:sdaedelus-89709B.15582112012005@comcast.dca.giganews.com...
> > Hi all,
> >
> > Help a fairly clueless guy: Let's say I add source1.cpp to a project. It
> > refers to functionX defined in source2.cpp. Now, if I put include
> > "source2.cpp" at the top of source1.cpp, it works ok. If I add
> > source2.cpp to the project, it tells me that functionX is undefined.
> >
> > Perhaps I just don't understand linking. Could someone explain this to
> > me?
> 
> 
> When you #include "source2.cpp", you effectively add the entire file to the
> beginning of source1.cpp. Everything in source2.cpp is compiled before
> everything in source1.cpp, and it works.
> 
> When you add source2.cpp to the project, it is compiled separately and
> linked in; however, source1.cpp no longer sees it (the error you're seeing
> means that the compiler doesn't know what functionX is, and can't generate
> code to call it: the linker isn't involved at this point, and the compiler
> only sees what you tell it to.)
> 
> 
> If you #include source2.cpp everywhere it's referenced, it  willl work but
> source2.cpp will have to be compiled every time a file that #include's it is
> Any changes to source2.cpp would force every file that #included it to be
> rebuilt as well
> Your binary might not get bigger (modern linkers are pretty good at spotting
> redundant code and removing it) but your build times will increase.
> 
> 
> You should:
> Add source2.cpp to your project: that way it gets compiled once
> #include source2.h (which should at least include a declaration of
> functionX) to every file that needs it. That way the compiler knows
> functionX is defined and the linker will look for and reference it properly.
> Now you can change source2.cpp without forcing anything else to recompile
> (as long as the declarations in source2.h don't change.)
> 
> Another way is to declare functionX extern in source1.cpp. This simply tells
> the compiler that the function is defined and prevents an error, and the
> linker takes care of locating the right code in source2.cpp. This isn't
> generally a good idea for several reasons, notably that you will have
> trouble if functionX's declaration ever changes (you'll have to hunt down
> every single extern declaration and fix it, instead of fixing it once in
> source2.h.)
> 
> 
> This is just the way C works: a separate header that lets files refer to
> each other (a type of forward declaration.) Pascal and other
> module-structured languages handle this by effectively generating their own
> headers from the source code and #including it automatically. there have
> been several attempts to do this with C-style languages (google MakeHeaders,
> for example, but it's pretty limited w/ C++.)

Oh, of course. That makes perfect sense. Many thanks.