How to hide member function file while sharing class

Question

I am reading book How to program by Paul Deitel. As per him we can make a file which does not contain member function details.

"To hide the class’s member-function implementation details, the class-implementation programmer would provide the client-code programmer with the header Time.h (which specifies the class’s interface and data members) and the Time object code (i.e., the machine-code instructions that represent Time’s member functions). The client-code programmer is not given Time.cpp, so the client remains unaware of how Time’s member functions are implemented."

I have developed below simple code in dev to test this concept but I don't know after compiling which file is the equivalent to cpp file.

Area Class:

#include<iostream>
using namespace std;
class Area {

    public:
        int square(int);

    private:
        int x;  
};

Source Code Area.cpp which contains member function functionality

#include<iostream>
#ifndef AREA_HH
#define AREA_HH
# include "Area.h"

int Area::square(int x)
{
    return x*x;
}

#endif

Main:

#include<iostream>
#include "Area.h"

using namespace std;

int main ()

{
    Area Obj1;

    cout<<Obj1.square(4);

    return 0;
}

The Files created by Dev are: Area.cpp, Area.o,Area.h,main.cpp,main.o,Makefile.win,layout and exe.

Answer 1

I don't know after compiling which file is the equivalent to cpp file.

It's the file that implements the functions that are declared in the the .h file. In your case, it is "Area.cpp".

Answer 2

You cannot isolate a class from an executable. To share functionality like that you have to build a library instead of an application. To understand why you can't find a single self-contained file that holds your class when building your project you have to understand how building works.

The standard structure of a C++ application sees functionality split across translation units (.cpp files). Those files hold the definitions of functions. In order for those functions to be used from other translation units, the function declarations need to be visible to those units. Because we do not want to include the entirety of every .cpp file we need, we most commonly separate the declarations into a header file (.h or .hpp). For example:

Circle.h :

// This is where you would put an include guard (NOT IN THE CPP FILE)

struct Circle {
    // Note that member variables need to be visible in the header
    float radius;
    float area();
}

---

Circle.cpp

float Circle::area() {
    return 2.0 * PI * radius;
}

---

main.cpp

#include "Circle.h"

int main() {
    Circle c;
    c.radius = 5.0;
    float area = c.area();
}

When the project is built, the compiler will output an object file for each translation unit, eg Circle.o and main.o. Because the compiler works on one translation unit (cpp) at a time, they are not self-contained. For example, in main.o there is a reference to c.area() that has not been resolved. Because the signature of the function was available through the included .h file, the compiler know how to call it but not how to find it. The linker will take all object files and link them into a single executable, eg MyProject.exe.

So in a standard C++ application, there is no "equivalent to cpp file". The intermediate .o is not intended to be shared and included in other projects and MyProject.exe is just an executable.

What you actually need to do is build a library. That is a form of executable that is not a standalone application. Then the final output of the linker is going to be a .dll, .lib, .so or .a (depending on platform and method of linking) which is going to hold all your function implementations in executable (not source) form. Then you can distribute the library alongside your .h files and let people link to that.

Again, there is no "equivalent of cpp" file. The built library will contain all translation units that you specify as inputs because the build process is very similar to the above. The difference is that the output will not be an executable application but rather a library from which functions will be called as needed from another application that links against this library.

There is no unified way to build a library. As you're using an IDE, it's probably going to be an option while creating a new project.

Answer 3

The implementation source code is Area.cpp, and this is compiled to the implementation object code in file Area.o.

If you want to distribute your Area library, you would create a library (Area.a, Area.so, Area.dll or Area.lib, depending on platform and link-style choices), and distribute that along with Area.h.

---

The general rule is any source file %.cpp is compiled to the object file %.o.

Note you already know perfectly well that Area.h and Area.cpp are inputs to the compiler (because you wrote them yourself), and the file timestamps will show which of the files you listed were created by the compiler, and you have a Makefile which either specifies exactly which file is built from which source, or describes the pattern relating input and output filenames ...