   i really dont get headers
  ive been using c++ for 2 years now and you know what i realised today, i still dont understand headers. ive been using them in project after project, making my own and been realatively ok, however today i kept getting linker errors telling me that things were being redifined, this is the header that i have created and want to include in two cpps:#ifndef __BITMAP_FONT_H#define __BITMAP_FONT_H//***********************START OF BITMAP FONT*************************************unsigned int CreateBitmapFont(char *fontName, int fontSize, HDC hDC){  ...some code i have defined them and declared them here (im guesing that could    be the problem}..some more functions in the same way#endifand i want to include it in a cpp called menu and my main cpp, i also want to include menu.h in main.cpp...menu.cpp#include "Menu.h"#include <gl\gl.h>#include <gl\glu.h>#include <gl\glaux.h>#include "BitmapFont.h"#include "BitmapFont.h"..main.cpp#include <windows.h>#include <gl\gl.h>//i would also prefer not to re-include gl headers as i would have though this be wasteful?#include <gl\glu.h>#include <gl\glaux.h>#include "NeHeGL.h"#include <stdio.h>#include <stdlib.h>#include "Menu.h"#include "BitmapFont.h"#include <strsafe.h>i have always been a bit unsure of where to re-include headers and exactly how to structure my includes, i find trying to just include one monster header never seems to work and i'd imagine that its not a good idea either! but today is the last strawcan someone please explain why in this case its not working and can someone also explain to me a litle bit about how headers work and how thet SHOULD be used and what is the best ethos when using them?Any help will be much appreciated, i have researched this before but ive always managed to find articles a bit above my head, i know i am still very much a noob at this stuff even if i can make pretty games and show off a bit, im still very unsure on the basic stuff!   
  Hello Chris. Can you please post the exact error you are getting?   ;  sure no problem (should have done that before really)error LNK2005: "void __cdecl PrintString(unsigned int,char *)" (?PrintString@@YAXIPAD@Z) already defined in AlienGameMain.objPrintString is a function within the BitmapFont Header and cleaning the project or deleting AlienGameMain.obj doesnt solve the problem.AlienGameMain.cpp is the first place i include BitmapFont.h and i think that maybe the fact that AlienGameMain.cpp doesnt have its own header could be a problem, but i have no idea and thats just me trying to make it sound like i know what im doing! lolthanks for your quick reply! :-);Quote:Original post by ChrisPepper1989sure no problem (should have done that before really)error LNK2005: "void __cdecl PrintString(unsigned int,char *)" (?PrintString@@YAXIPAD@Z) already defined in AlienGameMain.objThis is because each .cpp that #includes your bitmap_font.hpp file gets their own definition of PrintString.  They'll only get it once per #including .cpp thanks to the include guards, but that still ends up being multiple definitions if you have multiple .cpp files (which nontrivial project should).Two options (don't pick both!):1)  Move your function body into a .cpp (usual/recommended option):// the .hpp:unsigned int CreateBitmapFont(char *fontName, int fontSize, HDC hDC);// the .cpp:unsigned int CreateBitmapFont(char *fontName, int fontSize, HDC hDC){    ...none of this should be the problem...}2)  Declare your function "inline" thus allowing multiple definitions (only recommended for small or tiny functions (usually 1-liners))inline unsigned int CreateBitmapFont(char *fontName, int fontSize, HDC hDC){    ...none of this should be the problem...}HTH    -Mike   ;  ahh, thanks, but in option 1, does it mean that i have to incldue the cpp into my project? i was hoping that bitmapfont.h could just be added to future projects whenever i need it.when you say inline is usually only for one liners, why is that? are they not a good idea for slighlty larger functions?also when you say hpp, ive seen .hpp before, how does this differ from the standard .h?Thank you for your quick reply im still scratching my head a litle but that makes sense, im going to go try both solutions now.;Quote:Original post by ChrisPepper1989ahh, thanks, but in option 1, does it mean that i have to incldue the cpp into my project? i was hoping that bitmapfont.h could just be added to future projects whenever i need it.When you #include a header you are essentially pasting a copy of it's contents at that point in your 'cpp file', verbatim.So if you define a function in your header and #include it in multiple files, you have multiple definitions, hence the linker error. Which definition should the linker pick?You've already been told how to work around this at the source code level. But to allow you to reuse your code in multiple projects, you should create a library and simply link that to any project that needs the facilities declared by the associated headers.Quote:when you say inline is usually only for one liners, why is that? are they not a good idea for slighlty larger functions?Think about what inlining is. It's very roughly equivalent to pasting the contents of a function at various points throughout your code. Very, very bloaty. A compiler isn't necessarily obliged to inline a function just because you have declared it as such, but by defining the function body in a cpp file, you make it impossible for the compiler to inline invocations in other translation units (though some advanced linkers may  be able to do this, if they deem it an appropriate optimisation).Quote:also when you say hpp, ive seen .hpp before, how does this differ from the standard .h?Not in any way that matters to the compiler. It's just a convention. I tend to use hpp for c++ headers to indicate that I can't use them in C code.;Quote:Original post by ChrisPepper1989i have always been a bit unsure of where to re-include headers and exactly how to structure my includes, i find trying to just include one monster header never seems to work and i'd imagine that its not a good idea either! but today is the last straw.Headers should have logically grouped definitions in them.  If you are doing object-oriented stuff, this will probably be a single class--and maybe some helpers--in each header.  In non-OOP, it is probably a set of related functions etc.  DON'T just "include one monster header". If there are groups of files that ALWAYS will be included together, for whatever reason, then maybe you can have a single header that includes all of them, but I would try to avoid it.  In the GL example, you won't always use glu functions when you are using gl functions, so just include them individually as needed.As for where to "re-include" headers, don't think about it that way.  If a .cpp file uses a class or a function, it should include the header that defines it.  Just like in java you have to import the namespace for anything you use.  Just like in C# you have to have a "using" statement for anything you want to use without explicitly naming it with namespaces, etc.That's not to say that those 3 situations (c++, java, c#) are doing the same thing, but the usage will end up being similar.;Quote:Original post by ChrisPepper1989ahh, thanks, but in option 1, does it mean that i have to incldue the cpp into my project? i was hoping that bitmapfont.h could just be added to future projects whenever i need it.The usual solution to this is to build the project containing the .cpp files as a library.  You can then link to this library from another project, which will provide the program with all the function definitions.Quote:when you say inline is usually only for one liners, why is that? are they not a good idea for slighlty larger functions?Two reasons:1)  The historical reason:  inlining large amounts of code will bloat your executable sizes.  This alone wouldn't be much of a problem, but it also means your program may end up having more "active memory" dedicated just to the instructions, which might (for example) make a loop that could once run entirely in L1 cache on your processor end up having to spill out into using L2 cache (or from L2 into main memory) because the duplicated (inlined) code made it need to use more memory.  That said, modern compilers mostly ignore inline when it comes to deciding what to actually inline -- the keyword in the C++ language is a hint, not a mandate.2)  The modern reason:  compile times.  Any time you modify the header, anything #including it will need to be recompiled (whereas your .cpp files won't be #included from anything, only it will need to be recompiled).  Worse yet, the compiler will need to reinterpret the function body every time something #including it is recompiled, regardless of if that body actually changed or not.  While interpretation (aka lexing or parsing) of a language is always one of the most time consuming tasks, C++ isn't just hard -- it's one of the very worst offenders, a very hard to parse language.  In fact, I'd go so far as to say it's the hardest language to parse that I know of -- compile times can bloat up into the range of hours in a large project with badly managed dependencies.Quote:also when you say hpp, ive seen .hpp before, how does this differ from the standard .h?They're basically the same, except that .h could mean a C (not C++) header.  I use .hpp to make it clear I'm refering to a C++ header instead of a C header, although not everyone does this.(Note that the difference between .c and .cpp is more significant:  They often determine how the compiler will treat your code.  But, this caries over to any #included files -- a .h (or any other extension) #included from a .cpp will still be parsed as C++)   ;  wow thank you everyone for your response! particualarly MaulingMonkey :-) for giving me the intial solutions and full explanation on inlining!but everyones input is very appreciated! smitty1276, thanks for answerng my monster header question i always i had a feeling that was a terrible idea and also for re-asuring me on re-includes! and thanks to the_edd for covering the re-use in a bit more detail!this stuff is starting to make more sense now, i also think i know why some unis recomend learning c before c++, i also think it might of helped if a.)my college covered headers and such a bit better. b.)i knew some other language before c++ but thats just me rambling on...i have one final question, how the hell do you make a libary? do you just open a new project and build in a different way? i have never done it before so i have no idea how! and when you say linking to it in future projects what would be the best method?(im using visual studios 2005) by using something like:#pragma comment( lib, "opengl32.lib" )and/or linking it in Tools->Options->Projects and Solution->VC++ Directories->lib filesor using another method?-Thanks again for the quick responses and helpful info :-), Chris;Mandatory linkQuote:i have one final question, how the hell do you make a libary? do you just open a new project and build in a different way?Yep. In Visual Studio, you just change the output type to 'Static Library' in the project properties. (On the General page)Quote:when you say linking to it in future projects what would be the best method?(im using visual studios 2005)by using something like:#pragma comment( lib, "opengl32.lib" )and/or linking it in Tools->Options->Projects and Solution->VC++ Directories->lib filesThe latter is generally considered to be cleaner (partly because the #pragma isn't portable, and partly because you (the user of the library) may not want the file to be linked automatically.Boost gets away with using #pragmas, and to be honest, I'm not really sure why no one objects to that, when they do it if the same method is used by anyone else... [grin]   