EDIT: Tested out first question and got answer... but I have another question now.

I just tested to see whether .cpp files could access the code in other c++ files by including them, and it came out positive.  What I've been doing recently is putting both my functions, classes, and structs in header files, and utilizing them from a single .cpp file. This doesn't seem right, as open-source C/C++ projects that I've seen have multiple .c/.cpp files. So, when would you want to make a .cpp file instead of a header file?

(By the way I'm relatively new to C++)

Header files provide the function prototypes and class interfaces.  They do *not* (or are not supposed to) contain code.

Functionally it's irrelevant; the compiler sees everything as code anyway.  You can include a .d file and as long as it's valid C/++ code you're okay.

The reason you have a .h file is that you don't want to include your code in external binaries.  Say for example I have a DLL or .LIB that exports the function

[code]
__declspec(dllexport) int blarghonk(void);
[/code]

You have two choices: you can separate these out by putting this declaration in your .h file and compile the actual code into your own binary.  Then, when someone using your code is working, all they need to do is compile with your header and link against your library or DLL.

This is why, when you create a new Win32 DLL project in Visual Studio, it'll do something like this:
[code]
#if defined(LIBRARY)
#define LIBAPI __declspec(dllexport)
#else
#define LIBAPI __declspec(dllimport)
#endif


// your function prototype would then be...
LIBAPI int blarghonk(void);
[/code]

When you're compiling the code as your own library, you define the LIBRARY constant which makes the LIBAPI symbol __declspec(dllexport).  When someone is importing your code, usually that symbol (LIBRARY) won't be defined, do it's __declspec(dllimport).  So the compiler and linker know when a particular function should be imported from another binary source.

[quote author=MyndFyre link=topic=14174.msg144888#msg144888 date=1139269434]
Header files provide the function prototypes and class interfaces.  They do *not* (or are not supposed to) contain code.

Functionally it's irrelevant; the compiler sees everything as code anyway.  You can include a .d file and as long as it's valid C/++ code you're okay.
[/quote]I usually do this, however I've ran into problems trying to do this with templated classes... g++ doesn't like when I put the template class definition in a header file and the template class declaration in a source file, then try to use the template class in a application file.  Is this only because it is a template class?

Yes, templated functions/classes need to be implemented inside the header file.

[quote author=K link=topic=14174.msg146811#msg146811 date=1140644055]
Yes, templated functions/classes need to be implemented inside the header file.
[/quote]

Isn't that so partial specialization can be accomplished inside the code file?

You can usually get away with not putting the template in the header file if you're willing to resolve the link errors by hand.  That is, after all the members are implemented, explicitly instantiate the pieces you need.  If you only ever invoke MyList<T> with T=char and with T=int (two instantiations), you'd need to explicitly instantiate MyList<char> and MyList<int> at the end of the implementation of MyList.

Note that this is undesirable for several reasons.  First, it puts a greater burden on you to manually instantiate each variation you want.  Second, your compiler may or may not prune out instantiations you don't need (so you can't just go through and instantiate every possibility).  It also prevents compile-time inlining of the template's members, which is nice for accessors (methods that just { return m_X; }).

On the bright side, doing so avoids having the compiler reparse the implementations for every file which needs the template.

Meh, I really dislike my current professor.  He quite a douche.  Heh, so like today at the beginning of class I told him that found that g++ didn't like me defining a template class in a header file, declaring it in a implementation file, and then trying to use it in a application file...

So since todays topic was about template classes and template functions  he logged into PuTTY and tried doing it towards the end of class...  he made a simple template class definition in a header file, put the template class declaration in a source file, and wrote a 5 lined application file.  He compiled the template class implementation file into an object file, then compiled the application file into an object file with no problems.  Then he was like "HAHA you're a liar."  However he had not yet outputed both object files to a executable file.  So he then went to do that in a short makefile and when he ran the make it crapped in his face :)

Although during what time we had left, he got it to work by rigging it differently... he removed the #include of the header file from the implementation file and added at the end of the header file an #include "stack.cc"... >_<

Never seen this done before >_>;  I'm assuming this isn't something I should get a habit of doing since it looks like it's somewhat unconventional?

Including the .cc in the template header is not all that unconventional at all; I see it done a lot. I know I have programmed in an environment where that was not required though.


Later...
[url]http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html[/url]

See the Cfront model!