> Hello:
>
> Can we pass a pointer to an object from one cpp file to another by
> using a function call. Assuming the object was created and declared
> along with its accessor methods in the first cpp file, but you need
> to manipulate the same object in the second cpp file.
Yes, of course. There's nothing magical about what is in a single source
file. If your code is properly structured (i.e. you're not violating the
one definition rule anywhere and you're #including the right headers
everywhere) then there's no difference between putting your entire program
in a single source file or putting each and every function in a separate
source file.
> heres a quick example of the function call which calls a function
> in the second cpp file:
[quoted text clipped - 26 lines]
> c:\_DTS_PROGRAMMING\C_PROGRAMMING\vc++\MY_APPS_LAB\XPPLC\SFC_1.h(19):
> error C2065: 'components' : undeclared identifier
> c:\_DTS_PROGRAMMING\C_PROGRAMMING\vc++\MY_APPS_LAB\XPPLC\SFC_1.h(19):
> error C2065: 'cp' : undeclared identifier
Remember that the compiler sees only what you "feed" to it. Does cpp #2
#include the definition of the class "components" anywhere? If not, then
the compiler can't see it.
> It seems that all cpp files *must* have their own class definitions,
> and associated implementations... right?
No. A .cpp file is simply a unit of code that the compiler processes - but
each .cpp file is processed in isolation. Nothing that's declared in one
file is visible in another file. That's why we have #include and the
convention of using "header files" - common definitions and declaration are
placed in header files that are then included into all of the compilation
units that need them.
The most common way of structuing C++ programs is to put class definitions
into header files and the implementation of functions (be they member
functions or free functions) into compilation units (i.e. ".cpp files").
That way you can #include the defintion of a class into as many compilation
units as you require.
-cd