-7

File : A.cpp

void A::increment()
{
    i++;
}

int A::get_i()
{
    return i;
}

File : A.hpp

#ifndef HEAD_H
#define HEAD_H
class A
{
private:
    int i;
public:
    void increment();
    int get_i();
};
#endif

I have a java background and I am moving to C++ from it. I am stuck to the idea of keeping one class per file to have a clean code. However I don like the idea of using the scope resolution operator which makes it look ugly taking away the class definition from the class.

Is there any way I can have keep the class definition within the class construct ?

NOTE: I already visited this and this which does not answer my question.

Community
  • 1
  • 1
vikkyhacks
  • 3,190
  • 9
  • 32
  • 47
  • Self-inclusion? I think you copied both files wrong... Anyway, nothing hinders you from having the whole class definition inline in most cases, but stronger coupling and longer compile-times. Thus it is strongly discouraged. – Deduplicator Jun 06 '14 at 17:15
  • 9
    When in Rome, do as the Romans do. – n. m. could be an AI Jun 06 '14 at 17:18
  • 1
    This would be covered in any beginner C++ book. In fact most books will teach you how to have a single class definition *before* they teach you separation into source/header files. – JBentley Jun 06 '14 at 17:25
  • And as pointed out above, your code is wrong - you've got the same code in both files. – JBentley Jun 06 '14 at 17:26
  • 2
    I disagree with the logic that keeping one class per file is cleaner. By doing that, you're forcing any reader of your code to wade through all the irrelevant (to them) implementation details to figure out the interface they should use. With separation, you put interface and documentation in a header (the parts the *users* of your code want) and the implementation in the source. C++ doesn't do this perfectly, but you can come close if you use [pimpl](http://en.wikipedia.org/wiki/Opaque_pointer). – JBentley Jun 06 '14 at 17:34
  • Also, just a little note: `class` members are `private` by default, so the way you've written your header file you do not need the `private` keyword at the top. However, it is more traditional to place your `public` members at the top, and `private` at the bottom. This goes back to what I said in my last comment - so that readers of the code can straight away see the parts they care about (the `public` interface`) and ignore the `private` implementation details which C++ forces you to put in the header. – JBentley Jun 06 '14 at 17:39

2 Answers2

2

Yes, you can define it inline in the header. You can then #include all of the code

class A
{
    void increment()
    {
        i++;
    }
};

However, this comes with a consequence. If you make a change to the implementation, every file which included that header (to use the file) must be completely recompiled.

This is one of those cases where one should not assume that language A is just language B with some minor changes. The header/implementation pattern using two files is a very important part of C++, and you will have a lot of trouble trying to pretend it is Java and using Java's one-file methodology.

Cort Ammon
  • 10,221
  • 31
  • 45
  • Alternatively you can use the `inline` keyword to put the implementations in the header after the class definition, but I felt this was a clearer notation for someone coming from java. – Cort Ammon Jun 06 '14 at 17:18
0

Although it is not very DRYish I suppose the separated definition and implementation is how it is usually done in C++.

Anyway you could move all your classes code to your header file, but you'd end up with an increased compile time, for every cpp file that uses A would compile the whole code. This would also increase your binaries' size. If you had many classes using many other classes you might end up with a blown-up compilation time and size, many many times it would be if you did it the C++ way. (If your linker is not very clever, but I suppose all of the optimization is done while compilation)

You could also move all your class definition to the cpp file, but I guess this would mess things up even more in virtually every nontrivial case.

Paul Kertscher
  • 9,416
  • 5
  • 32
  • 57