Trouble including...
Pages: 12
Well I guess I got it, as long as its not a problem to be including SDL/SDL.h in multiple header files. like the timer, because it uses SDL_GetTicks()
It failed until I included SDL/SDL.h in the header file.
It failed until I included SDL/SDL.h in the header file.
SDL is maintained by a team of programmers who are past the beginner stage.
It is safe to assume that every header they have is guarded in one way or another.
It is ok to include any header files in any number of files.
It is good programming practice to include it as few times as possible.
So don't worry about it for now.
It is safe to assume that every header they have is guarded in one way or another.
It is ok to include any header files in any number of files.
It is good programming practice to include it as few times as possible.
So don't worry about it for now.
Include guards won't protect against multiple definition errors, as the header file may be included by multiple source files. Using "extern" in the header, and defining the object in a source, is the way to fix that, as Peter87 said.
True. But you shouldn't have multiple definition errors. If you're getting those, then you don't need to be making header files, yet.
Last edited on
How so? What if you need an object to be accessible in multiple source files? A header file with an "extern" declaration of that object, with the actual object being defined in ONE source file, is the way to do that, aside from manually writing the "extern" declaration in each file that needs the object, but thats stupid.
Hmm. But I don't understand where you coming from. If you have something that more than one object needs, then yeah, put it in a global file. But why would you put it in more than one global file?
Take this globals.hpp file for example:
If you were to include that header file from multiple sources, the int would be instantiated multiple times, even with the include guards. In order to prevent multiple instances, you would put "extern" in front of the int's declaration, then define the int (by declaring it without "extern") in a separate source file (presumably globals.cpp).
|
|
If you were to include that header file from multiple sources, the int would be instantiated multiple times, even with the include guards. In order to prevent multiple instances, you would put "extern" in front of the int's declaration, then define the int (by declaring it without "extern") in a separate source file (presumably globals.cpp).
Edit: For safety from more flaming. *The compiler should throw an error for defining the same variable twice.
As for your example up there. That is definition and instantiation. Defining twice gets an error. Instantiating twice, as you said, is something people don't want, right? But luckily for them, it won't happen, because instantiating is this:
myNum = 0;But if a type is there, then its a definition, and the compiler will throw an error before myNum ever gets instantiated twice.
Last edited on
Yes, that example was meant to show the error created, which you said would be solved by using include guards, but it isn't. Also, I believe your mixing up "initialized" with "instantiated". Giving myNum a value initializes it, whereas declaring it without
extern will instantiate it. Instantiate means to create an instance, in case you couldn't tell from the root of the word.
Um. Ok. So I guess we are trying to be rude to each other. I actually do know what instantiate means. I figured you were using it incorrectly, so I used it how you used it.
Defining and instantiating is the same deal. myNum only does it once, because of the include guards. It only gets instantiated once, it only gets declared once, it only gets defined once, and it only gets initialized once. If you have a myNum object floating around, the you CAN'T make another one. Even you said that. Therefore, you won't be instantiating it again.
Defining and instantiating is the same deal. myNum only does it once, because of the include guards. It only gets instantiated once, it only gets declared once, it only gets defined once, and it only gets initialized once. If you have a myNum object floating around, the you CAN'T make another one. Even you said that. Therefore, you won't be instantiating it again.
In fact, one could argue that a definition, a declaration, and an instantiation are all the same thing. But I know full well what the differences are.
However, whether I know the difference or not has nothing to do with the fact that you can't define int myNum twice no matter how hard you try.
However, whether I know the difference or not has nothing to do with the fact that you can't define int myNum twice no matter how hard you try.
You can't have initialization without instantiation, but
Generally speaking, the compiler doesn't generate an error for a violation of the ODR, because it deals with one translation unit at a time and these multiple definitions usually occur across translation units. The linker, on the other hand, tosses a wrench into the works when it encounters the multiple definitions.
I'm not sure why Vlykarye is trying to differentiate between instantiation and definition. There isn't a difference for variables.
myNum = 0; is simple assignment, which wouldn't be legal at file scope so I'm not sure why it was brought up in the context of header files.Generally speaking, the compiler doesn't generate an error for a violation of the ODR, because it deals with one translation unit at a time and these multiple definitions usually occur across translation units. The linker, on the other hand, tosses a wrench into the works when it encounters the multiple definitions.
I'm not sure why Vlykarye is trying to differentiate between instantiation and definition. There isn't a difference for variables.
Last edited on
The compiler sees the include guard and notes it down. It doesn't just forget, or at least I hope yours doesn't.
And again. Linker, compiler. The point we are making is that it gets an error. Sorry. I'm used to fighting about them separately. If you just want to attack me, then tell me I have a big nose, or that my eyes are too plain. Stop picking at my word choice. I haven't lived my life explaining to everyone the difference between the compiler and the linker.
Last edited on
I don't see why he couldn't just stop at "Use externs" and leave everyone else alone.
His way is fine, my way is fine. If my way wasn't fine, then everyone would be using externs, but they aren't. Get over yourselves. The question has been answered. Stop trying to make yourself look all cool by picking at every little thing someone else says. Mistakes happen. You're not cool cus you can point them out then make them seem like huge errors.
His way is fine, my way is fine. If my way wasn't fine, then everyone would be using externs, but they aren't. Get over yourselves. The question has been answered. Stop trying to make yourself look all cool by picking at every little thing someone else says. Mistakes happen. You're not cool cus you can point them out then make them seem like huge errors.
As it is now, I doubt anyone even cares what we are talking about. And it seems that I can't say "use header guards" without be trolled. So, I'm leaving this topic to the rest of you. Hopefully you haven't missed the point, and will try to help explain to the op what he can do, not force him into one option. Bye.
Vlykarye: You talk too much! I was going to say you are wrong because that was my first impression but now I'm not sure. Maybe I just don't understand you. What ModShop and cire says is true so if you disagree with them you should rethink your attitude.
Haha. Haven't heard from you in a while, so I'll respond to your post. I think that my attitude has little to do with this though. I agree fully well with some of the things they say. But, seriously:
Include a header file from multiple sources; I believe he means including the header file in more than one source file (.cpp or .c or whatever).
The int would be instantiated multiple times; I believe he means there will be more than one myNum objects of type int created. This is simply not the case. And that is all I was really trying to say. Sorry for the confusion.
If I am wrong in saying that only one myNum object of type int is created in the example given, then PLEASE give me a link to some facts and proofs, because I am fked if that's the case.
| ModShop wrote: |
|---|
| If you were to include that header file from multiple sources, the int would be instantiated multiple times, even with the include guards. In order to prevent multiple instances, you would put "extern" in front of the int's declaration, then define the int (by declaring it without "extern") in a separate source file (presumably globals.cpp). |
Include a header file from multiple sources; I believe he means including the header file in more than one source file (.cpp or .c or whatever).
The int would be instantiated multiple times; I believe he means there will be more than one myNum objects of type int created. This is simply not the case. And that is all I was really trying to say. Sorry for the confusion.
If I am wrong in saying that only one myNum object of type int is created in the example given, then PLEASE give me a link to some facts and proofs, because I am fked if that's the case.
ModShop is right about this.
Each translation unit is compiled separately and include guards only prevents the header from being included more than once in the same translation unit.
If you end up defining a variable in more than one translation unit you will get a linker error. This is similar to how you can't have multiple definitions of non-inline functions. http://en.wikipedia.org/wiki/One_Definition_Rule (read Summary point 2, or the C++ standard section 3.2).
Each translation unit is compiled separately and include guards only prevents the header from being included more than once in the same translation unit.
If you end up defining a variable in more than one translation unit you will get a linker error. This is similar to how you can't have multiple definitions of non-inline functions. http://en.wikipedia.org/wiki/One_Definition_Rule (read Summary point 2, or the C++ standard section 3.2).
Last edited on
Topic archived. No new replies allowed.
Pages: 12