class definitions in headers
if the following appears in a header file:
class A
{
public:
int a, b;
int add ()
{
return a+b;
}
}
where is the code compiled to?
is a new copy of the compiled class code stored in every c file that the header is included into?
if not, is there any reason not to completely define classes and their function bodies in header files?
I think a new copy of the class is created in every file that has the header file included.
As for if there is any reason not to completely define classes and their function bodies in header files, you probably shouldn't do this b/c if the header file is included in multiple files you'll get a linker error.
BTW, i'm kinda new to this C++ stuff so i hope i'm correct
+AA_970+
Edited by - +AA_970+ on July 26, 2000 10:18:17 AM
As for if there is any reason not to completely define classes and their function bodies in header files, you probably shouldn't do this b/c if the header file is included in multiple files you'll get a linker error.
BTW, i'm kinda new to this C++ stuff so i hope i'm correct
+AA_970+
Edited by - +AA_970+ on July 26, 2000 10:18:17 AM
well, I was wary about the idea - surely there''s a good reason to define functions in CPP files?
but as far as I can tell there is none... if you have ever programmed in Java you know how useful the class definitions are - there is only one def. and it contains EVERYTHING about the class including functions and so on.
as far as I can tell, the same sort of effect can be recreated in C++ by having only one CPP file in your project which includes several header files, each of which contains one or more class definitions complete with function bodies.
I thought there would be problems, such as the MSVC auto-member thing not recognizing functions which weren''t defined in CPP files, or not displaying a member list from inside a header file, but there aren''t. Also i didn''t think you''d be able to call member functions which are defined further down in the header file than where they are called from, since they haven''t yet been declared or prototyped anywhere - but even here the compiler didn''t have any trouble at all.
It seems to work well, makes very neat code, and the program actually seems to compile much much quicker! so i''m going to carry on using it
but as far as I can tell there is none... if you have ever programmed in Java you know how useful the class definitions are - there is only one def. and it contains EVERYTHING about the class including functions and so on.
as far as I can tell, the same sort of effect can be recreated in C++ by having only one CPP file in your project which includes several header files, each of which contains one or more class definitions complete with function bodies.
I thought there would be problems, such as the MSVC auto-member thing not recognizing functions which weren''t defined in CPP files, or not displaying a member list from inside a header file, but there aren''t. Also i didn''t think you''d be able to call member functions which are defined further down in the header file than where they are called from, since they haven''t yet been declared or prototyped anywhere - but even here the compiler didn''t have any trouble at all.
It seems to work well, makes very neat code, and the program actually seems to compile much much quicker! so i''m going to carry on using it
The primary reason to define class functions in the header file is to make them inlined. The compiled code for the function is then expanded instead of making an actual function call to a piece of code. This only works for small pieces of code.
The use of header and program text files is meant to separate interface and implementation. The header file provides the interface a programmer has to use, while the implementation details are in the program text (= CPP) file. I find it irritating as well sometimes (updating function prototypes in two files), but it''s the way C/C++ is created. The major drawback of the Java approach is that you can''t quickly get an overview of all the members of a class.
You could put all your code in header files, but be sure to use header inclusion guards to prevent multiple includes (which will lead to linker errors). The drawback is that compiling can take a very long time if you have a lot of header files, because every header file has to be parsed and compiled each time because no object file is created. Pre-compiled headers can help, though.
Also, global variables visible in multiple code modules can''t be used, because they have to be declared in a program text file as well.
My advise is to go with the separate header/program text thing, because it will save you from a lot of problems.
Erik
The use of header and program text files is meant to separate interface and implementation. The header file provides the interface a programmer has to use, while the implementation details are in the program text (= CPP) file. I find it irritating as well sometimes (updating function prototypes in two files), but it''s the way C/C++ is created. The major drawback of the Java approach is that you can''t quickly get an overview of all the members of a class.
You could put all your code in header files, but be sure to use header inclusion guards to prevent multiple includes (which will lead to linker errors). The drawback is that compiling can take a very long time if you have a lot of header files, because every header file has to be parsed and compiled each time because no object file is created. Pre-compiled headers can help, though.
Also, global variables visible in multiple code modules can''t be used, because they have to be declared in a program text file as well.
My advise is to go with the separate header/program text thing, because it will save you from a lot of problems.
Erik
well i would disagree that java has a disadvantage from that point of view - because you manually have to maintain .H files, so in java you could keep a list of functions in a seperate text file with no more effort than is required for C++. But that's a completely irrelevant and unimportant point. Anyway onto other things:
my question is, would the statement be replaced with 'printf ("Rage Against The Machine");'?
i.e. are class member functions which are defined in headers DEFINATELY inlined when they are used in .cpp files?
and if they are is there any way to prevent it?
Edited by - remo on July 26, 2000 1:31:59 PM
// in header.h: class A{public: int MyFunc () { printf ("Rage Against The Machine"); }}// in main.cpp:void main (){ A a; a.MyFunc(); // <---- this statement}
my question is, would the statement be replaced with 'printf ("Rage Against The Machine");'?
i.e. are class member functions which are defined in headers DEFINATELY inlined when they are used in .cpp files?
and if they are is there any way to prevent it?
Edited by - remo on July 26, 2000 1:31:59 PM
It is basically up to the compiler what to do. I am pretty sure there is a flag or an option that you can set to make the compiler do what you want. There is a little discussion on the inlining issue here http://www.flipcode.com/forums/cotd/COTD-FileStream.shtml.
Nate Miller
http://nate.scuzzy.net
Nate Miller
http://nate.scuzzy.net
well well if it isn''t nate miller himself! well done on your great little GL page
thanks for that link, it has been useful - as far as I can tell from the source code, even in header files the functions don''t get inlined unless you explicitly define them as an inline (that''s meant to look like a keyword) function. So I guess i can carry on using header files to keep all my code in. i think it''s a much more sophisticated way to code anyway, because since the classes are all contained in one definition instead of potentially being scattered over several files, it gives a much less abstract object oriented feel to c++ (if you see what i''m getting at).
I didn''t realise anyone else actually coded like that though
thanks for that link, it has been useful - as far as I can tell from the source code, even in header files the functions don''t get inlined unless you explicitly define them as an inline (that''s meant to look like a keyword) function. So I guess i can carry on using header files to keep all my code in. i think it''s a much more sophisticated way to code anyway, because since the classes are all contained in one definition instead of potentially being scattered over several files, it gives a much less abstract object oriented feel to c++ (if you see what i''m getting at).
I didn''t realise anyone else actually coded like that though
Man, I would play it safe and never define any function in a header file (save a CTOR). This will keep you from eventually ending up with hella linker errors.
-BacksideSnap-
-BacksideSnap-
If you included a complete function inside the class definition it''s considered an inline function. So it will be inlined subject to the normal rules for your compiler. Which usually means if it''s a small non-recursive function it''ll be expanded inline.
There are plenty of good reasons not to put all your functions in the .h file. For example every time you change a function, your entire project will need to be re-built. I assume that some of you classes will use other classes, so you''ll probably get lots of problems with the order you included stuff.
There are plenty of good reasons not to put all your functions in the .h file. For example every time you change a function, your entire project will need to be re-built. I assume that some of you classes will use other classes, so you''ll probably get lots of problems with the order you included stuff.
July 26, 2000 02:25 PM
well i don''t agree with -BacksideSnap-... you don''t linker problems if you arrange it properly.
but i guess most of what wilka said is true... the project re-compiling isn''t so much of a problem - there wouldn''t actually be lots of seperate cpp files, only ONE for the whole project which contains the entry point - all the rest of the code is in header files in the form of classes. It is stupid though, that there is no way to specify that you do not want a function inlined even if it is in a header file, but rather that you want it contained elsewhere in an automatically created .obj file or something.
about the inclusion order, yes I could see this could create problems.
let me explain my situation. I have started to make a little DirectX flight sim game (screenshots here), but i have got to a point where it is becoming increasingly hard to modify my code because i''ve carelessly let it become tangled and patched up. Since i''ve done a portion of the actual code, I thought it would be better to start again with a new project and a new structure and just copy + paste in the actual code.
What I wanted was a very modular structure - i decided that practically EVERYTHING should be in its own class from CDirect3D to CEntityList and so on, and all as independent of each other as possible. but one thing that bugs me is that for every class you need one .cpp file and one .h file... why? it would be much much better if each class had its own file and then there was just one additional file for the application as a whole.
can anyone else think of some way of achieving this or something similar?
but i guess most of what wilka said is true... the project re-compiling isn''t so much of a problem - there wouldn''t actually be lots of seperate cpp files, only ONE for the whole project which contains the entry point - all the rest of the code is in header files in the form of classes. It is stupid though, that there is no way to specify that you do not want a function inlined even if it is in a header file, but rather that you want it contained elsewhere in an automatically created .obj file or something.
about the inclusion order, yes I could see this could create problems.
let me explain my situation. I have started to make a little DirectX flight sim game (screenshots here), but i have got to a point where it is becoming increasingly hard to modify my code because i''ve carelessly let it become tangled and patched up. Since i''ve done a portion of the actual code, I thought it would be better to start again with a new project and a new structure and just copy + paste in the actual code.
What I wanted was a very modular structure - i decided that practically EVERYTHING should be in its own class from CDirect3D to CEntityList and so on, and all as independent of each other as possible. but one thing that bugs me is that for every class you need one .cpp file and one .h file... why? it would be much much better if each class had its own file and then there was just one additional file for the application as a whole.
can anyone else think of some way of achieving this or something similar?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement