List244
asked on
Standards, what is the difference?
I am told to keep my class separate from its functions, why? I find it much cleaner to keep my functions with my class header.
Not only do I find it cleaner, but easier to transfer when needing a class elsewhere. This way, I only need to copy the one file,
not both. What is the difference?
Not only do I find it cleaner, but easier to transfer when needing a class elsewhere. This way, I only need to copy the one file,
not both. What is the difference?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Still you'll risk trouble. Apart from that, if you want to provide a library or a DLL, it does not make sense to have the implementation in the header file also, because that's why you create a library in the 1st place. I'd only go for your approach when it comes to templates, but that is another story.
ASKER
So, then, you would say it is necessary for me to have a header file, and a CPP file for each class?
If this is the case, I would keep my class as is, and just copy the functions to a TTT.CPP? What kind
of trouble am I risking with my current method?
If this is the case, I would keep my class as is, and just copy the functions to a TTT.CPP? What kind
of trouble am I risking with my current method?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Looks like jkr made the same point before I got it posted :(
ASKER
I completely understand the whole team-projects, and how that works. I am just curious of the dangers of doing
it the way I am. Most of my assignments are around 100 lines of code, and I just hate having to go back and forth
between files to make a small change, or add a function. For that reason, I was curious if it was okay for such small
projects to do it the way I am. Or if it is dangerous, and if so, how.
it the way I am. Most of my assignments are around 100 lines of code, and I just hate having to go back and forth
between files to make a small change, or add a function. For that reason, I was curious if it was okay for such small
projects to do it the way I am. Or if it is dangerous, and if so, how.
If it is for an assignment or a short hack, it can be OK. However, if it is code that you expect to reuse later or maintain for a while, I'd go for the separation into a header and an implementation file. Modularity, as already mentioned is another aspect for separating things.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
With the above method, only foofoo.cpp defines the macro before including foofoo.h
All other source files would just include foofoo.h, and they would only get the class declaration, and not the implementation.
All other source files would just include foofoo.h, and they would only get the class declaration, and not the implementation.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> When I first saw Java code, I couldn't figure out why they'd want to put so much implementation in the headers
That's why Java uses the concept of "Interfaces" to enforce encapsulation - it's (arguably) even cleaner that the C++ header file scheme.
That's why Java uses the concept of "Interfaces" to enforce encapsulation - it's (arguably) even cleaner that the C++ header file scheme.
>>When I first saw Java code, I couldn't figure out why they'd want to put so much implementation in the headers
In general, I hate Java.
But this is actually one feature I do like about Java.
I prefer to have the class declaration and the implementation in the same place.
IMHO, it's not that confusing, unless it's poorly spaced.
IMHO, it's more confusing switching back and forth between the *.h and the *.cpp file to compare implementation with data members and methods.
In general, I hate Java.
But this is actually one feature I do like about Java.
I prefer to have the class declaration and the implementation in the same place.
IMHO, it's not that confusing, unless it's poorly spaced.
IMHO, it's more confusing switching back and forth between the *.h and the *.cpp file to compare implementation with data members and methods.
>>That's why Java uses the concept of "Interfaces" to enforce encapsulation - it's (arguably) even cleaner that the C++ header file scheme.
You can do the same thing in C++ with an abstract class that has nothing but pure virtual functions.
That's basically what is a Java interface class.
It's been my experience that there are very few features that Java has, that you can't duplicate in C++.
IMHO, Java is just a restricted version of C++
You can do the same thing in C++ with an abstract class that has nothing but pure virtual functions.
That's basically what is a Java interface class.
It's been my experience that there are very few features that Java has, that you can't duplicate in C++.
IMHO, Java is just a restricted version of C++
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>If you gave me a class you had written to use in my app the I could quickly scan the header to see what methods it supports and how to use it.
If you have a well designed class, it doesn't have too much code in each function, and therefore it shouldn't be that hard to scan the header and find the functions.
Also, the functions should be documented with a comment header, which would also aid in finding the function.
IMHO, when you have methods that take more than two pages, that's a sign that you're giving that method too much functionallity.
Often when I find bugs in code, 95% of the time it's in large functions. Because these funtions are so big, it's easier to add bugs in them, and they're harder to maintain.
For my clients, I never put implementation in the header unless the entire implementation and declaration takes less than one page.
It's really not that pratical with anything bigger.
But I can see why some developers would like to see class declaration and implementation in the same place.
I can also see why most C++ programmers prefer seperation.
There are advantages and disadvantages to both methods.
If you have a well designed class, it doesn't have too much code in each function, and therefore it shouldn't be that hard to scan the header and find the functions.
Also, the functions should be documented with a comment header, which would also aid in finding the function.
IMHO, when you have methods that take more than two pages, that's a sign that you're giving that method too much functionallity.
Often when I find bugs in code, 95% of the time it's in large functions. Because these funtions are so big, it's easier to add bugs in them, and they're harder to maintain.
For my clients, I never put implementation in the header unless the entire implementation and declaration takes less than one page.
It's really not that pratical with anything bigger.
But I can see why some developers would like to see class declaration and implementation in the same place.
I can also see why most C++ programmers prefer seperation.
There are advantages and disadvantages to both methods.
>>experience that there are very few features that Java has, that you can't duplicate in C++.
If you don't consider reflection or cross-platform binary compatibility a feature :)
>>IMHO, Java is just a restricted version of C++
No more so than C++ is a restricted version of Assembler.
Don't get me wrong - I love C++ and I love Java, but unless I'm doing high-performance bare-metal development, I'll take the productivity gains of Java over C++ anyday. Still after 15 years of doing C++ it's hard to give it up, if for no other reason that it was just so d**m hard to learn in the first place!
Not looking for a flame war - just my opinion...
If you don't consider reflection or cross-platform binary compatibility a feature :)
>>IMHO, Java is just a restricted version of C++
No more so than C++ is a restricted version of Assembler.
Don't get me wrong - I love C++ and I love Java, but unless I'm doing high-performance bare-metal development, I'll take the productivity gains of Java over C++ anyday. Still after 15 years of doing C++ it's hard to give it up, if for no other reason that it was just so d**m hard to learn in the first place!
Not looking for a flame war - just my opinion...
>>If you don't consider reflection or cross-platform binary compatibility a feature :)
I didn't say there are NO features. I said very few.
>>No more so than C++ is a restricted version of Assembler.
I agree
>>I'll take the productivity gains of Java over C++ anyday
I can get more productivity using C++ than using Java (If on single target platform).
If targetting multiple platforms, than I can see the productivity gain using Java.
>>but unless I'm doing high-performance bare-metal development
Even when high performance is not an issue, I still see Java running way too slow for my taste.
Just using Java IDE's make my teeth grain waiting for each window to popup.
I know it's only a split second delay, but I prefer having a GUI that's instantaneous, than using something that crawls along between each window.
I also don't like that you don't get the full OS look and feel when using most Java applications.
The only way I would recommend using Java as a front-end, is if the application was very simple, and didn't have that many complex sub windows.
I didn't say there are NO features. I said very few.
>>No more so than C++ is a restricted version of Assembler.
I agree
>>I'll take the productivity gains of Java over C++ anyday
I can get more productivity using C++ than using Java (If on single target platform).
If targetting multiple platforms, than I can see the productivity gain using Java.
>>but unless I'm doing high-performance bare-metal development
Even when high performance is not an issue, I still see Java running way too slow for my taste.
Just using Java IDE's make my teeth grain waiting for each window to popup.
I know it's only a split second delay, but I prefer having a GUI that's instantaneous, than using something that crawls along between each window.
I also don't like that you don't get the full OS look and feel when using most Java applications.
The only way I would recommend using Java as a front-end, is if the application was very simple, and didn't have that many complex sub windows.
>>... a well designed class, it doesn't have too much code in each function...it shouldn't be that hard to scan...
But if the class does anything more than expand slightly upon as base class, then it will surely have several or dozens of methods. Even if they are small, that means you need to scan to the end of a multiple-page file just to see the last of the member functions and the curly bracket that closes the class definition.
In my C++ code, I go out of my way to avoid putting implementation code in the header. Even tiny accessor functions go in the CPP file so I never have to look in two different places to find the code. If I am worried about function-call overhead inefficiency, I mark the method as inline.
But if the class does anything more than expand slightly upon as base class, then it will surely have several or dozens of methods. Even if they are small, that means you need to scan to the end of a multiple-page file just to see the last of the member functions and the curly bracket that closes the class definition.
In my C++ code, I go out of my way to avoid putting implementation code in the header. Even tiny accessor functions go in the CPP file so I never have to look in two different places to find the code. If I am worried about function-call overhead inefficiency, I mark the method as inline.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
JKR, thanks again for the help. And the rest of you, I also thank. I have issued the promissed 250 to JKR and split
an additional 250 among the rest of you, thank you all for the comments.
an additional 250 among the rest of you, thank you all for the comments.
ASKER
ifndef TTTG
#define TTTG
#include ...
enum ETTT
{
...
};
enum ISet
{
...
};
class TTT
{
private:
...
public:
...
};
#endif
//Functions here
Is this wrong, bad practice, if so why?