Thanks for replying. I know Java and Node. Overall code is large but only few files are important to change it for the required task, which I already figured out. I was thinking about some kind of visual map which gives me an overall idea about what is going on among those files. And I think the main problem for loosing the motivation is to not knowing the overall flow among the files.

I think you mean JavaScript (JS, based on the ECMA-262 ECMAScript standard) by "Node"?

Files are connected via #include statements. Just imagine thta the file you include is copied right there for now (it does not work like that, but just think it would, because that's how it feels). I will try to put all important things which differ from Java into the following example. Please ask any questions you still have :)

// foo.hpp

// this is a declaration of a class
// it has to be implemented/defined somewhere, but you usually don't do so in the header (.h) files
class Foo
{
  void bar();
}; // <-- all semicolons I write are mandatory! You cannot leave them away

// foo.cpp

#include "foo.hpp" // <-- this will make everything available which is in foo.hpp
#include <iostream> // <-- some header file which makes I/O streams available

// there are namespaces
// one could access cout in the std namespace by writing std::cout
// however, by declaring which namespace to use up front, one can shorten that
use namespace std;

// here you can implement bar, because the declaration from foo.hpp
// was pulled in by the above include
void Foo::bar()
{
  // do sth.

  // i is just an integer. It is _not_ an object and hence has no methods whatsoever
  // in C++, all primitive types are just that and you will have to use operators to work with them!
  // by the way, char* also is just a pointer to a primitive type, so even if it looks like a string,
  // it is just a block of memory with arbitrary data in the size of char * n
  int i = 42;
  cout << "Hello World! " << i << endl; // streams are awesome :)

  // speaking of char*, you could read the data of a char*,
  // but it would only give you the first char! You will have to read on for a given amount of memory locations
  // careful, though! Never read more data than available
  // we already had the Heardbleed bug because of something stupid like reading too much memory...
}

// main.cpp

// in order to use the code, you just need to pull in the declaration in the header file
// the compiler will get all the definitions by itself if it is configured correctly
#include "foo.hpp"

int main()
{
  // `new` will allocate memory, initialize the object there and give you a pointer to it
  auto ptr_foo = new Foo(); // ptr_foo will be a pointer (type: Foo*) to the object in memory
  Foo obj_foo(); // obj_foo is the object directly. It will be initialized right there, just like in Java

  ptr_foo->bar(); // since it's a pointer, you have to use the arrow operator to call methods
  obj_foo.bar(); // but not for the object :)

  // Important: C++ usually is not memory managed and has no GC.
  // So if you allocate memory for which you only have a pointer, you do have to free it
  delete ptr_foo;

  return 0;
  // ptr_foo and obj_foo will be destroyed here (just like in Java)
  // if we hadn't used destroy further up, only the pointer would have been deleted
  // but the memory would still have been reserved and then floated somewhere in RAM
  // with no way to reach it ever again. That's what we call a memory leak
}