I never really understood why it's better to only DECLARE your classes and functions in a .H file, but not just define them within that same header file.....why is it frowned upon to do that? Why define them in another source file?
I never really understood why it's better to only DECLARE your classes and functions in a .H file, but not just define them within that same header file.....why is it frowned upon to do that? Why define them in another source file?
Because when you pass your class or functions to another programmer (the client), they want to be able to know how to use the function and what it looks like, but they don't need to know how it works exactly. Its like a car, you see the body and have break, gas, and steering wheel. But when you drive you never actually look at the engine running.
What I'm saying is...
It's easier for someone that wants to use your work to just read the declerations to get an Idea of how to use it (because they should be commented), then going through all the "inside work" which could confuse them.
It's all about data encapsulation, one of the fundamental concepts of Object-Oriented Programming.
Join is in our Unofficial Cprog IRC channel
Server: irc.phoenixradio.org
Channel: #Tech
Team Cprog Folding@Home: Team #43476
Download it Here
Detailed Stats Here
More Detailed Stats
52 Members so far, are YOU a member?
Current team score: 1223226 (ranked 374 of 45152)
The CBoard team is doing better than 99.16% of the other teams
Top 5 Members: Xterria(518175), pianorain(118517), Bennet(64957), JaWiB(55610), alphaoide(44374)
Last Updated on: Wed, 30 Aug, 2006 @ 2:30 PM EDT
Originally Posted by major_small
Sorry major, you're off here. The location of code in different files is a totally separate issue from data encapsulation (when used in the traditional sense). It has more to do with the fact that .h files are typically declarations while .cpp is implementation. The actual encapsulation of the objects in the class does not change: those members which were private remain private, public members remain public. The user may now be able to see the code and edit it, but it doesn't make the objects any less protected than they were before. Since the user has access to the declarations, by modifying the .h file, the user could just as easily break the included code without even touching the implementation.
Basically, the .h file can be regarded as a poor man's documentation for the class.
Well it is because you give others header files while implementation is hidden and buried in libraries. When you write class libraries for example you give others compiled library and header file. In header file they can see declaration and therefore how to use function, create object etc. But implementation is separated and compiled so others cannot see the code and stole it.
For example by examining header cstdio you can understand how to use functions fprintf() or fread() but how that's implemented, that you cannot see. You only need to know interface i.e. how to use function, but how is that function implemented that you cannot see and there is no need for you to know that detailes.
- Micko
Last edited by Micko; 07-29-2005 at 09:31 AM.
Gotta love the "please fix this for me, but I'm not going to tell you which functions we're allowed to use" posts.
It's like teaching people to walk by first breaking their legs - muppet teachers! - Salem
Not to mention, if you have a big project with say one header/source pair (foo.h and foo.cc) that is used in everything, and you decide to go and modify the implementation (foo.cc), all you will have to do is recompile the object file for foo, and relink. If you had not done this, then everything that includes the modified code must be recompiled, and you might have a very long lunch break as a result.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
depending on interpretation... read on:Originally Posted by golfinguy4that's what you're doing when you just include the .h files - you're only providing the interface, but some people think of encapsulation as the actual act of hiding the variables from the rest of the code. the way I've always known it to be, you're hidnig the inner workings of the class because you know that can change and don't want a program to be able to depend how your code does what it does.Protecting a design decision involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change). In modern programming languages, the principle of information hiding manifests itself in a number of ways, including encapsulation and polymorphism.
Join is in our Unofficial Cprog IRC channel
Server: irc.phoenixradio.org
Channel: #Tech
Team Cprog Folding@Home: Team #43476
Download it Here
Detailed Stats Here
More Detailed Stats
52 Members so far, are YOU a member?
Current team score: 1223226 (ranked 374 of 45152)
The CBoard team is doing better than 99.16% of the other teams
Top 5 Members: Xterria(518175), pianorain(118517), Bennet(64957), JaWiB(55610), alphaoide(44374)
Last Updated on: Wed, 30 Aug, 2006 @ 2:30 PM EDT
I'm not going to get into an argument here over this. I'm just letting the OP (and I guess everyone else) know that, although putting your implementation in a .cpp file and not a .h file protects your code from user modification and is most certainly a good practice, this scheme is not traditionally classified as a form of encapsulation.
arguement are what make thsi board fun and people learn
soemthing new, i say brign the arguement on and do your best
to defend each of your points
Also, when you work on non opensource libraries, you don't want people to have access to the internal workings, so you just hand them the headers and binary form of the library to link to.
If any part of my post is incorrect, please correct me.
This post is not guarantied to be correct, and is not to be taken as a matter of fact, but of opinion or a guess, unless otherwise noted.
As gulfinguy said, breaking code into headers for declarations and source files for implementation is not encapsulation. While code written with encapsulation in mind will often place interfaces and implementation into separate files, it is possible to break code in to headers and implementation without achieving encapsulation.
The more usual reason for breaking code into header files and source files are;
1) Interfaces change rarely, while implementation details get tweaked regularly. Placing interfaces into header files means that C/C++ source files which uses those interfaces do not need to be recompiled whenever implementation details change. On large projects, that avoids a need for large recompile times, as alluded to by Zach: I have seen cases of recompile times reduced from several days to less than an hour by simply placing implementation in separate files from interface. [The trade-off, of course, is that if an interface needs to change, suddenly a large recompilation is required].
2) As Xipher said, some developers want to distribute libraries for reuse without complete source code. Separating source into header files and implementation allows the header files to be distributed with a compiled library, but does not require the basic source code that implements functionality to be distributed.