• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 315
  • Last Modified:

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?
0
List244
Asked:
List244
  • 6
  • 4
  • 4
  • +5
7 Solutions
 
jkrCommented:
One difference is that if you need that class definition in more than one source files, you might get a 'symbols multiply defined' error from the linker if you're not careful[¹]. Basically, the class declarations provided in the header file describe the operations on that class, including the functionality does not really increase readability.

[¹] Can be prevented using 'header guards':
#ifndef MYFILE_H
#define MYFILE_H

// ...
#endif
0
 
List244Author Commented:
Well for example, my class looks like:

ifndef TTTG
#define TTTG

#include ...

enum ETTT
{
      ...
};
enum ISet
{
      ...
};

class TTT
{
private:
      ...
public:
      ...
};

#endif

//Functions here

Is this wrong, bad practice, if so why?
0
 
jkrCommented:
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.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
List244Author Commented:
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?
0
 
DeanHorakCommented:
Another reason to keep you class's implementation (.cpp) separate from the header file (.h) is that it allows you to enforce encapsulation. You can distribute libraries containing your classes along with the header files needed to use them, without exposing your implementation methods.

This may or may not be important to your particular project.

However you can imagine if, for instance, you are a framework developer, you may want to keep the application developers from tinkering with the implementation of the framework classes. By simply providing them with the library of framework classes and header files, the application developers can use the framework without being able to alter it.
0
 
DeanHorakCommented:
Looks like jkr made the same point before I got it posted :(
0
 
List244Author Commented:
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.
0
 
jkrCommented:
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.
0
 
AxterCommented:
>>I am just curious of the dangers of doing it the way I am.

It's not dangerous.  Danger is not a real issue.  The real issue is encapsulation.

If this is code you want to reuse, and you really really want to keep the class declaration and class implementation in the same code, you can add #ifdef to exclude the implementation from other *.cpp files.
Example:

//foofoo.h header file

#ifndef FOOFOO_H_
#define FOOFOO_H_

class foofoo
{
public:
  void SomeFunction(int x)
#ifdef FOOFOO_INCLUDE_IMP_
  {
        std::cout << "Hello foofoo" << std::endl;
  }
#else
    ;
#endif

};

#endif //FOOFOO_H_


//Your foofoo.cpp file
#define FOOFOO_INCLUDE_IMP_
#include "foofoo.h"

0
 
AxterCommented:
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.
0
 
DanRollinsCommented:
When I first saw Java code, I couldn't figure out why they'd want to put so much implementation in the headers... outside of encapsulization, I think it is mainly a style issue -- who wants to see pages of source code breaking up what should really be a clean declaration?  Who wants to have entire functions indented that way?

The hassle of having two source files is easily mitigated in an IDE programming environment like Visual C++ -- a one-keystroke macro can bring up the .h version of a .cpp file (or vice versa).  Another trick is to put the name of the other file in a comment at the top.  Then you can right-click it and select "Open Document blahblah.cpp"
0
 
DeanHorakCommented:
>> 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.
0
 
AxterCommented:
>>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.
0
 
AxterCommented:
>>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++
0
 
Carl TawnSystems and Integration DeveloperCommented:
One reason for seperating the declaration and definition is to aid other developers. 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. Other developers generally don't need to see the implementation or want to wade through it all to see how to use it.
0
 
AxterCommented:
>>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.
0
 
DeanHorakCommented:
>>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...
0
 
AxterCommented:
>>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.
0
 
DanRollinsCommented:
>>... 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.
0
 
Prashant SabnekarAVPCommented:
>>>list224
There are many advantages in seperating source and header files,
1. You can create a library of your s/w an sell it, so that nobody will be able to look into the code(your .cpp file, because now it is a library eg: file.dll). And nobody can copy your logic.
2. When you handle large projects as I do with hundreds of classes, you get problem in including one file into another.
3. More over list224 it is a method being followed by the industry, and I advise you to follow the same because you also want I thing to be in the industry. Initially you may find some inconvinience but you will be addicted to it slowly.

Regards
Prashant Sabnekar
0
 
PaulCaswellCommented:
Hi List244,

I use a hybrid of the two techniques.

For stuff like simple operator overloading I usually put the implementation in the header but in the class itself but only if its a one or two liner:

    // 3x3x3 array of compass points
    T p[3][3][3];

    // Create/Destroy
    CCube(void) {memset (p,0,sizeof(p));};
    ~CCube(void) {};

    // Inline access of named ones.
    inline T * up() { return &p[1][2][1]; };
    inline T * down() { return &p[1][0][1]; };
    inline T * left() { return &p[0][1][1]; };
    inline T * right() { return &p[2][1][1]; };
    inline T * fore() { return &p[1][1][2]; };
    inline T * back() { return &p[1][1][0]; };

    // The id is the center unit.
    inline T * id() { return &p[1][1][1]; };

    // Access of the correct pointer using -1..+1 access.
    inline T* d(int x, int y, int z) { return &p[x+1][y+1][z+1]; };
    // Access of the correct pointer using -1..+1 access.
    inline T* d(CPt d) { return &p[d.x+1][d.y+1][d.z+1]; };

};

This way you can not only inline but you can make the user comfortable with how to use the object.

More complex work is usually less effective in the header but only because the compile process begins to crawl.

I dont think there is anything actually wrong with doing it your way. It wont hurt the code in any way as far as I know. The biggest problem you are likely to come across is if you want to reuse the code later in a much larger project. Then, if you find it necessary to move the implementation into a .cpp file it gets fiddly and error-prone and that can be a pain.

Paul
0
 
List244Author Commented:
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.
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 6
  • 4
  • 4
  • +5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now