Quick Question about Header Includes

[XianForce]

Ok, so let's make this simple and say I have the definition of my cat class in "Cat.h" and then all of its accessor functions/member methods/etc. in "Cat.cpp" then I have my "main.cpp". So with this, where do the includes go, and for what?

[avansc]

Ok, so let's make this simple and say I have the definition of my cat class in "Cat.h" and then all of its accessor functions/member methods/etc. in "Cat.cpp" then I have my "main.cpp". So with this, where do the includes go, and for what?

you will have cat.h that will look something like this.

Code: Select all

#ifndef _cat_h
#define _cat_h

class cat
{
public:
    cat(char* name);
private:
    char* name;
};

#endif

then cat.pp

Code: Select all

#include "cat.h"
cat::cat(char *name)
{
    this->name = name; //im not sure this will work, you might have to allocate mem for this->name first.
}

then lastly main.cpp

Code: Select all

#inlcude <stdio.h>
#include <stdlib.h>
#include "cat.h"

int main(void)
{
    cat *meowder = new cat("meowder");
    return 0;
}

let me know if this worked for you?

[XianForce]

Yes, thanks that worked, so I have to include the headers in my main.cpp and the .cpp file(s) that are using it?

[avansc]

Yes, thanks that worked, so I have to include the headers in my main.cpp and the .cpp file(s) that are using it?

yup. if you are going to use function or variables or whatever you need to include the .h file that contains that data.
sometimes i make one h files. something like includes.h, then put all my #include "cat.h" and whatever in there.
then i only inclide the includes.h in all of my files. that way its not as much typing and not as clutered. its especially nice if you say merge 2 files or take one away, you only have to take that definition out of the includes.h and not all your source files.

ps: ALLWAYS use the #ifndef _filename_h and all that jazz

[XianForce]

ps: ALLWAYS use the #ifndef _filename_h and all that jazz

My IDE automatically does that for me =D. But with your whole thing with the "includes.h" that has all your other header files in it. Wouldn't that take up more memory, and have your program eventually run a lot slower?

[avansc]

ps: ALLWAYS use the #ifndef _filename_h and all that jazz

My IDE automatically does that for me =D. But with your whole thing with the "includes.h" that has all your other header files in it. Wouldn't that take up more memory, and have your program eventually run a lot slower?

mmm.. you know im not sure. i dont think so. the #ifndef bla bla besically say has the file been linked to the main program, if not do so.
so its not like its linking more than it has to. it might make compiling a little bit slower, but nothing major. but should not effect efficiency pr size at runtime.

ps: i might be wrong about this, but i dont think so. so dont qoute me.

[XianForce]

lol, ok, thanks for the help.

[Arce]

Wouldn't that take up more memory, and have your program eventually run a lot slower?

How you structure your program before compiling it won't effect it at all in runtime. In theory, putting your program on a single line, or in 10000 different files should execute the same.

The only difference is compile-time. It will take longer to compile, generate the objects, link, etc.

[XianForce]

Wouldn't that take up more memory, and have your program eventually run a lot slower?

How you structure your program before compiling it won't effect it at all in runtime. In theory, putting your program on a single line, or in 10000 different files should execute the same.

The only difference is compile-time. It will take longer to compile, generate the objects, link, etc.

Alright, great. Time to get back to practice then xD

[Arce]

Haha. sadly, I just ran into a project setup bitchfest involving misuse of headers and source files...Was killing my linker after switching from BloodShed Dev (at school) to MVC++--one covers multiple declaration checks for ya and the other doesn't.

Luckily, marauder bailed me out...But I gotta tell ya, there's no better way to feel like a shitty programmer than to have a computer scientist critique your code. XDDDD

[XianForce]

Haha. sadly, I just ran into a project setup bitchfest involving misuse of headers and source files...Was killing my linker after switching from BloodShed Dev (at school) to MVC++--one covers multiple declaration checks for ya and the other doesn't.

Luckily, marauder bailed me out...But I gotta tell ya, there's no better way to feel like a shitty programmer than to have a computer scientist critique your code. XDDDD

Its even worse when you have no idea what the hell their talking about xD

[MarauderIIC]

By the way... putting multiple includes in one include and including that single file will increase your compile time. If the include guards (#ifndef .. #define .. #endif) are inside the file, then the compiler still has to open the file to see the guards. This happens for every .cpp that it's included in (as every .cpp file is compiled to a .obj file and then linked together). In short, the more effective #includes you have, the longer your compilation takes.

Scenario 1:
scen11.cpp

Code: Select all

#include "a.h"
#include "b.h"
...

scen12.cpp

Code: Select all

#include "c.h"

Scenario 2:
scen21.cpp

Code: Select all

#include "all.h"

scen22.cpp

Code: Select all

#include "c.h

all.h

Code: Select all

#include "a.h"
#include "b.h"
#include "c.h"

Scenario 1 compiles faster than scenario 2, because in scenario 2 when main.cpp is being compiled, the compiler has to open all.h and c.h, which is two more files than then first setup had to open.

Additionally, in scenario 2, if you change something in c.h, then all.h changes (since c.h is pasted by the linker into all.h), which means that scen21 changes (since all.h is then pasted into scen21.cpp), which means that scen21.cpp has to be recompiled and so does scen22.cpp.

In Scenario 1, if you change something in c.h, scen11.cpp is not changed and is not recompiled, although scen21.cpp still has to be. So in scenario 2, not only does the compiler have to open more files, it also has to recompile .cpp files more often than scenario 1. C/++ compilation is too slow in the first place to code this way :P

If you want a blatant demonstration, make a for loop that terminates when i = 100 or something. Then add some file i/o inside that loop and witness the huge speed decrease, due to accessing the hard drive. Now make i = 50 and of course it'll run faster since you'll use the hard drive less. Same thing: more includes per .cpp/.obj = more hard drive use = slower compilation time.

[XianForce]

Same thing: more includes per .cpp/.obj = more hard drive use = slower runtime

Wait so it can produce a slower program? and not just increase compile time?

[MarauderIIC]

Just slower compile time

Click here to see the hidden message (It might contain spoilers)

(which is runtime for the compiler, hence the "make a program and put file I/O in a loop" analogy).

I fixed that sentence in my OP, sorry.