Quote:
Originally Posted by
LMHmedchem
Thanks again for your patient and thoughtful replies, they are a huge help.
I have a few instances where I have function definitions in header files. These are usually functions that are only included when specific things have been defined, #ifdef, etc. I guess it would be better to have the functions definitions in their own object and implement the abstraction in the make file by linking the additional objects under the specified conditions.
Depends what they are. If they're very short thing you might be able to make them either macros or inline functions, both of which are safe to put in headers.
Quote:
So for global variables, you declare those in a header file (as extern), and then include the .h in only one src file?
Sorry if that was unclear. You include the header in both the thing that declares it, and anything that uses it.
Quote:
Then you have to re-declare and initialize the var in the same src file where the header is included ?
It's a safety-check to make sure you're creating the same kind of variable your header says you are. C/C++ are, technically, low-level languages, so creating variables and function ends up being done in assembly language, and assembly language is all about memory and symbols.
You don't HAVE to include the header but it's a great idea to do so. I had to debug a library where there was an "internal" headerfile which was only used by the library and an "external" headerfile which was only used by things using the library. Very odd way to do things, especially considering the amount of extra work it took to do so.
One of the functions used a 'long int' parameter, but the external header said it was a 'uint32_t' -- a guaranteed 32-bit integer. On 32-bit machines a long is 32-bit, but on a 64-bit architecture, it's not! This caused extremely bizzare errors in 64-bit architectures, returning a nonsensical errorcode even when the function actually succeeded. Not even a debugger could tell what was going wrong. If they'd just included the external header, the compiler would have told them "your function isn't what your header says it is!" and refuse to go.
Quote:
That is so different from Fortran when you have to include global (common) variables in every src file where they are used, and then if you re-declared it, you would get a compiler bonk.
It's because of how C/C++ lets you compile each file completely separately. You can declare that a variable or function
exists anywhere, and if it's not available at compile-time, it'll be able to find it when the objects are all linked together. But you only should declare what a variable or function is, once.
Quote:
I am still a bit confused about the function prototypes. Lets say we are not using extern "C", can I declare the function prototype (with no code block) in one and only one header file, or do I need to include the header file in every src file that will be using the function.
Include it everywhere, yes. It never implicitly includes anything. Each .c/.cpp file is compiled completely separately, one C file doesn't give a darn if you included so and so header in a file you compiled 900 microseconds ago.
---------- Post updated at 02:11 PM ---------- Previous update was at 01:52 PM ----------
Another way to put it would be that C or C++ requires you to explicitly declare everything, be it a library function, internal variable, external variable, or what have you. (C++ is stricter about this than C. C is willing to assume external functions exist if you try to use them, which is sometimes a problem.) It's very simple, very straightforward, and extremely simpleminded -- imagine a language where you're supposed to
manually define all your library functions before you're allowed to use them! That's how C works. It does this because each C file is its own separate little universe when compiled, completely blind to any help from other source files until the final linking step.
Because doing that by hand is silly they put all of that mess into header files. But header files have no special behavior. Copy/pasting the raw contents of a header file into your source code would have the same effect as including it. So the rules remain the same: Explicitly declare the existence of
every symbol you want to import into your source code. And just to be fair, explicitly declare the existence of every symbol you want to export too. "This symbol exists and I'm using it", or, "This symbol exists and I'm creating it".