First it's always very helpful when you indent your code. You can use the code box button <> to help you out.

Second subclass usually means a derived class. So for instance:

 

class A
{
	......
};

class B : public A
{
    .....
};

So here B is a subclass of A.

What you have are two instances of class A which are members of class Main. Of course you can name them subclass1 and subclass2 if you want but there is probably a better choice of names.

Finally, I'm not sure where you intend to put the actual integer. All I can see is pointers to integers. You could put the integer in Main itself, like this:

struct A
{
   int* p;

   void init(int * ap)
   {
      p = ap;
   }
}; 

struct Main 
{
   int iInt;

   A subclass1, subclass2;

   void init()
   {
      subclass1.init(&iInt);
      subclass2.init(&iInt);
   }

};

Now you can actually have a place for your number.  Also you might want to use constructors instead of init functions. Sometimes init functions come in handy in odd cases but here you really don't need them. So that gives us:

#include <iostream>

struct A
{
   int* p;

   A(int * ap)
   {
      p = ap;
   }
}; 

struct Main 
{
   int iInt;

   A member1, member2;

   Main(int iVal) : iInt(iVal), member1(&iInt), member2(&iInt)
   {
   }

};


int main()
{
   Main clMain(666);

   std::cout << "member1 value = " << *clMain.member1.p << std::endl;
   std::cout << "member2 value = " << *clMain.member2.p << std::endl << std::endl;

   clMain.iInt = 444;

   std::cout << "member1 value = " << *clMain.member1.p << std::endl;
   std::cout << "member2 value = " << *clMain.member2.p << std::endl;

   return 0;
}

Which outputs:

member1 value = 666
member2 value = 666

member1 value = 444
member2 value = 444

I'm not really commenting your design here. There might be some better way of doing what you are trying to do.

Well just add a level of de-referencing and you would get:

#include <iostream>

struct A
{
   int **p;

   A(int **ap)
   {
      p = ap;
   }
}; 

struct Main 
{
   int* p;

   A member1, member2;

   Main() : p(0), member1(&p), member2(&p)
   {
   }

   void SetVal(int *pVal)
   {
      p = pVal;
   }

};


int main()
{
  
   Main clMain;

   int *pVal1 = new int(666);

   clMain.SetVal(pVal1);

   std::cout << "member1 value = " << **clMain.member1.p << std::endl;
   std::cout << "member2 value = " << **clMain.member2.p << std::endl << std::endl;

   int *pVal2 = new int(444);

   clMain.SetVal(pVal2);

   std::cout << "member1 value = " << **clMain.member1.p << std::endl;
   std::cout << "member2 value = " << **clMain.member2.p << std::endl;

   delete pVal1;
   delete pVal2;

   return 0;
}

You can and probably should use smart pointers for this.  However I loath the C++ standard library shared_ptr because it creates extra objects you woudn't need if you simply implement a reference counted object base class. This can cause a major performance hit.

5 minutes ago, _WeirdCat_ said:

as for that conversion thing i dont know yet, but for the post above, i cant call main class from a subclass due to circular reference thing, i could obviously bypass that, but thats not the point, still searching for legit solution

It this case you don't need to. You have a pointer in each of the instances of A  to the int *p in Main. I thought that was the whole point.  Also you can in fact call members of Main in class A. You just need to break things up into .h and .cpp files.

Many times when there is communications it is best to work on layers.

From your description where you have two windows that need to share data, one option is to have each window draw any data that is given to it through a pointer. Then a different system can provide both windows with a pointer. That separate system can also respond to input events and notify windows when there is something new or different to draw.

This type of composition is common in user interfaces and handled with ownership.  An individual button, an individual text box, an individual icon, each of them knows how to draw one thing. They are put into a bigger container control that tells each button and text box what to do.  That bigger control might be placed inside another window, controlled by the application. The individual icons might be reused in many places, and the application might forward update events to any number of windows and to any number of UI controls, but the individual UI controls don't need to know or care about others that use the data.

It looks like you also have discovered the critical issue of understanding object lifetimes. Controlling object lifetimes is a critical part of software engineering, and doing it wrong results in crashes (when something isn't there any more) and resource leaks (when it wasn't properly cleaned up).  Having a reliable hierarchy helps with lifetimes, since a parent can assure a child object that it will not assign the value until after it is valid, and it will notify the child before modifying or destroying objects that have been assigned.