noob question regarding #include

If I have two separate files for a class (a header file and a file containing all the member function definitions), and in the header file I have something like this:

Code:

---

#include<iostream>
#include "SomeOtherClass.h"
using namespace std;

---

can I then leave out all this stuff in the file where I define all the methods of the class (and just #include the header for that class and nothing else)? do I even need to put them in the header class, since the header doesn't actually call any functions or do any operations? would it be better to just put them in the definition file? or do they need to be in both? thanks.

First, the more advanced programmers here recommended to me a while back not to use using statements in header files. I've followed that advice.

As to your other questions, I'm pretty sure that if you #include "my_classes.h" (where that's the file that has all the stuff you have above) in the definition file "my_classes.cpp", you don't have to repeat all of the other includes.

However, I think it's actually good practice to go ahead and repeat most of the time but only to put the includes in each file that you really need.

My own practice is to put only the includes that I really need in my header. So, normally not #include <iostream> because you usually don't need that one for the prototypes. But you may well need #include <vector> or #include <string> or something like that because your prototypes may rely on those.

In summary (my opinion): 1) Don't put using in your header file, 2) Only put those #include's that you really need into each file with the exception of 3) Don't worry about repeating library includes that the file needs but would have by virtue only of #include "my_classes.h"

Quote:

---

Originally Posted by Aisthesis

First, the more advanced programmers here recommended to me a while back not to use using statements in header files. I've followed that advice.

---

Sorry the question within a question, but could you supply a link to one of these posts that describes why? And this to mean you include the std:: etc for every call within a header file?

As for the first question,

Quote:

---

Originally Posted by Aisthesis

In summary (my opinion): 1) Don't put using in your header file, 2) Only put those #include's that you really need into each file with the exception of 3) Don't worry about repeating library includes that the file needs but would have by virtue only of #include "my_classes.h"

---

I think this is good advice. The more stuff you put in your header files, the longer the compilation time, so that's a good reason to avoid it!
Aside from that, including whatever you need for each file is another good idea since it won't break your code if, say, your header changes and you remove some includes.

Quote:

---

Originally Posted by Spazmotic

Sorry the question within a question, but could you supply a link to one of these posts that describes why? And this to mean you include the std:: etc for every call within a header file?

---

Basically, the thing is that every .cpp file that includes your header files will get the using statement. This is bad since it basically imports stuff into the global namespace, and some .cpp files may work under the condition that they don't use using namespace because, for example, they define their own string class in the global namespace. If the .cpp file included a header file that uses using namespace std, you'd get compile errors.
So, avoid it in header files. Use explicit form, ie std::string, etc.

Ahh...the things I didn't know could fill the congressional library :D Thanks much for the explanation!

[edit: this is incorrect! Sorry]

One thing you can do if you still want to use namespace std is put it in the .cpp lib file, but not the lib header. Compile the lib .cpp file as an object, and the header is what gets included in some other .cpp file (the one with main()). When you compile main(), link it to the precompiled library object. The presence/absence of "using namespace std" in the lib .cpp source won't matter (as long as it is not in the header), eg.

In header (just forward declarations):

Code:

---

class foo {
      std::string somemethod()...

---

Then in the .cpp source for which this is a header:

Code:

---

using namespace std;
string foo::somemethod ()

---

As long as the later is compiled by itself, you can link to it and use the header without any collisions [ edit: probably wrong! :p]

Mk27,

My mind was trying to grasp that concept as an idea but my conclusions kept coming up a conflict , your way makes sense though.

My original way of thinking..I guess because of lack of experience would be, couldn't you just create a header with the using and link it to any other cpp that exclusively needs it? My logical mind wants to say that's a problem because if it was if that file was included it would include the using std:: as well and cause the conflict.

Lol, now that I think about it more in depth..i'm not sure how that's any different from just including ing the using in the first place...sigh..sorry.

Actually: I was just double checking this and I think I am wrong! I'm pretty new to C++ too.

Quote:

---

Originally Posted by Spazmotic

My original way of thinking..I guess because of lack of experience would be, couldn't you just create a header with the using and link it to any other cpp that exclusively needs it? My logical mind wants to say that's a problem because if it was if that file was included it would include the using std:: as well and cause the conflict.

---

I think it will be impossible to either link to or include a source file or library object that uses namespace std without it also applying to main(). So Elysia's caveat applies no matter what -- of course, if you are not worried about namespace collisions of that sort yet, it is not a big deal. Altering code along these lines later is pretty easy anyway.

Either way,

As someone fairly new to C++ ( I took several classes in school but it's been quite some time, so it's learning syntax all over again), I do greatly appreciate the patience and answers from everyone.

Would like to make sure the original posters question got answered though..seeing as how I seem to of overshadowed it :-/

Edit: yeah, seems if you needed to, could just regex all of the std:: if they needed to be swapped out.

I'm of the opinion that a header should include every header it requires...even if it could or does grab that header from another include. The problem with not following this is if someone makes changes in the other header which brings in the one you need and they remove that for some reason now your header is broken as a result of their change. In a multi-user environment it is much easier to ensure each header brings in all headers it needs and does not rely on other headers for required headers.

I'm also of the opinion it is not the other person's job to fix your header before submission, however, they pretty much have to or they will break the code line or component when they submit. This type of stuff can really make your day hectic since you either fix the broken header that broke b/c it was poorly written or you hunt down the fella who is responsible for it (if they still work at your company) or you alter more than just the code that was related to the issue you were fixing thus causing tracking and revision history issues.

So generally it comes down to if you're working alone, and realize you need to make a change to the STD or whatever namespace, and you can just run through in 10 minutes in (we'll say regedit) fix it.... or pass your patch down the line for the next poor sap to do.

From what I can tell..if it comes down to an opensource production environment and you do have the headers including the namespace..should the end user decide to make adjustments and wind up changing the header in this way..they'll error out..but hey..that's what .patch files are for :)

The thing is that no one has any business changing your header file, because often we don't know the details of the how and why. so avoid using the using directive in header files. Be nice. Respect other source file's wishes and needs.
They should not need to change your header because it's problematic.

Good point as well..and I believe I'll follow that...should i develop an open source app, I'd like to see people improve on it by editing the source code..but if I did my job right there's no reason for them to dig into my header files. I'm really glad I got to hear separate sides of this argument, allowed me to see the "ethical" choices.

Quote:

---

Originally Posted by Spazmotic

Good point as well..and I believe I'll follow that...should i develop an open source app, I'd like to see people improve on it by editing the source code..but if I did my job right there's no reason for them to dig into my header files.

---

Well no, if I add a method I will alter the header. I think this in reference to a scenario where you are supposed to be contributing something to spec that should not require alteration OR cause stupid problems for the rest of the project AND leave as few constraints as possible for future development.