-3

I am trying to have a class in one file and use that class in many files. I am very confused... I don't want a messy code having half the class in one file and half the class in another.

app_core.cpp: (here we have the class)

class s1
{
    private:
        int gx;

    public:
        int gx(int x,int y)
        {
            gx = x;
        }
};

app1.cpp: (here we use the class)

#include "app_core.cpp"
class s1;

int show()
{
    s1 new_s;
    cout << new_s.gx(8, 7);
}

app2.cpp: (here we use the class)

#include "app_core.cpp"
class s1;

int show()
{
    s1 new_s;
    cout << new_s.gx(18, 17);
}

How to archive something like the above?

JoeFrom
  • 11
  • 3

5 Answers5

2

In C++ when you #include something, the included file is more or less "pasted" in the place of that directive.

There's a concept called translation unit which indicates a code unit which gets compiled and might, in the future, be referenced by other units (at linking time).

What you want is to write a translation unit and give other translation units the information on how to access that data. That is the purpose of a header file.

A .h file (.h by convention, you might call it whatever you like) is a set of declarations like

File s1class.h

class s1
{
    private:
        int gxd;

    public:
        int gx(int x,int y)
        {
            gxd = x;
            return x;
        }
};

and

app1.cpp:

#include"s1class.h"

//... use s1 class

app2.cpp:

#include"s1class.h"

//... use s1 class

Just notice one thing: you should never violate the One Definition Rule, you can declare as many times as you want something (as long as they're consistent declarations) but you CANNOT define more than once a symbol (e.g. a function). (small note: #pragma once directives and similar stuff can help you avoid re-declaring symbols more than once and make your life easier when including a header multiple times in multiple places).

So in the above code the "gx" function is defined into your header file.. that function should exist just once per translation unit where it is used.

In that particular case it is used to create the translation units for app1.cpp and app2.cpp. It should violate the ODR, right? It won't instead since a member function for a class is implicitly inlined, that means it is "stitched" into the caller's body thus being integrated part of the caller's identity.

The alternative is to just declare stuff in the header file and implement them in a related cpp file:

s1class.h

#pragma once

class s1
{
private:
  int gxd;

public:
  int gx(int x,int y);
};

s1class.cpp

#include "s1class.h"

int s1::gx(int x,int y)
{
  gxd = x;
  return x;
}

and proceed as above: by just including the header file in order to use it at link time (when the symbols are resolved).

Marco A.
  • 43,032
  • 26
  • 132
  • 246
  • Is there any drawback using the 1st example? – JoeFrom Feb 06 '14 at 09:50
  • When "inlining" there's always a benefit and a drawback: http://stackoverflow.com/a/145841/1938163 . To summarize you're not inlining the function for sure but the compiler will have the final decision.. you're just marking it as "inlineable". If it gets inlined the code will be faster (since you don't have to call a function, you just execute something immediately) but it will also grow in size (more redundant code instead of a function in a single place). You usually mark inline functions as such when you have small performance-critical methods. – Marco A. Feb 06 '14 at 09:52
  • Last question: why use the example 2 when you can use the example 1, given that file size is not an issue? I mean, example 2 is more complex and time consuming to work with? – JoeFrom Feb 06 '14 at 09:57
  • It is usually a good practice to split implementation and definition. For code like templates you will probably have to use the first approach (there's an extra step called instantiation point). Also: it reduces coupling and **compilation time** since if you change something in the header with the code.. well.. all translation units will have to be recompiled. If you use a declaration-only .h file and you change something in the cpp file.. no big deal and the compilation times will be shorter. – Marco A. Feb 06 '14 at 10:00
1

You can use headers. app1.h:

class s1
{
    private:
        int gx;

    public:
        int gx(int x,int y)
        {
            gx = x;
        }
};

app2.cpp:

#include"app1.h"
//...

also the file app1.h should be with your compiled file
or else add address like 

#include "D:\app1.h"
//...

if your file app1.h is in D: drive

Mukul Kumar
  • 315
  • 1
  • 5
  • 16
Bardia Heydari
  • 777
  • 9
  • 24
0

First, it is very bad style to include a cpp file. In theory, you could write all the code from app_core.cpp into a header such as app_core.h. While this works in most cases, it can lead to unnecessarily long compile times. If you really want to do it, though, you have to leave out the class s1; from both .cpp files.

If the split between header and source is what you meant by the "messy code", then I'm sorry but no, there is no general way to achieve that.

anderas
  • 5,744
  • 30
  • 49
  • Other than slow compilation, what drawback `In theory, you could write all the code from app_core.cpp into a header such as app_core.h` got? – JoeFrom Feb 06 '14 at 09:46
  • This is basically the main drawback. Also, all functions defined inside the class body will be implicitly declared as `inline`, but that shouldn't be that much of a problem. This is only a hint to the compiler, though. But you will run into trouble trying to define a static member variable this way, because it basically has to be declared in a .cpp file so that the compiler and linker know where the single instance of that variable is defined. – anderas Feb 06 '14 at 09:51
0

Build a header file.

app1.h

class s1
{
    private:
        int gx;

    public:
        int gx(int x,int y)
};

app1.cpp

#include "app1.h"

int s1::gx(int x,int y)
{
    gx = x;
}

app2.cpp

#include "app1.h"
// your code that calls s1 methods
Marik
  • 119
  • 5
0

I think this could solve your "problem": put your class in a header, and implement it in the header (this is called, e.g. for libraries "header-only").

#ifndef CLASS1_H
#define CLASS1_H

class s1
{
    private:
        int gx;

    public:
        int gx(int x,int y)
        {
            gx = x;
        }
};
#endif //CLASS1_H

Then, just #include "Class1.h" in every needed .cpp.

There, one class in one file (no separation of declaration and implementation). Just do note that while sometimes convenient, using "header-only" code has its drawbacks:

  • The implementation is now tied to the declaration, which means that any change to the implementation will imply that you must re-compile the code that includes this header.

  • Compilation will take more time, because the compilation unit must see every implementations in the translation unit, rather than just the interfaces.

Contrary to your belief, having one header and one implementation file isn't messy. It has its advantages, and is a widely used practice. But yeah, one of its drawbacks is that you have to manage two files.

JBL
  • 12,588
  • 4
  • 53
  • 84