sending data from one field of a class back to the class

Question

I have one class "A" that contains some field, one of these fiels is a class "Z", so I want to send data from this field(which is a class) to the class "A", when I tried to send data from the class "A" to the "Z" via reference it worked, but now I can't see how can I process data in the reverse way. here's the code:

#ifndef SCREEN_AGENDAVIEW_HPP
#define SCREEN_AGENDAVIEW_HPP

#include <gui_generated/screen_agenda_screen/Screen_agendaViewBase.hpp>
#include <gui/screen_agenda_screen/Screen_agendaPresenter.hpp>
#include <string>

class Screen_agendaView : public Screen_agendaViewBase
{
public:
    Screen_agendaView();
    virtual ~Screen_agendaView() {}
    void Open_Container()override;
    void SendToView(std::string text);
protected:
    CustomContainer_event ce;
};

#endif // SCREEN_AGENDAVIEW_HPP

#include <gui/screen_agenda_screen/Screen_agendaView.hpp>

Screen_agendaView::Screen_agendaView():ce(*this)
{

}
void Screen_agendaView::Open_Container()
{
    customContainer_event1.setVisible(true);
    customContainer_event1.invalidate();
}
void Screen_agendaView::SendToView(std::string text)
{
    Unicode::snprintf(textArea1Buffer, TEXTAREA1_SIZE, "%s", text);
    textArea1.setWildcard(textArea1Buffer);
    textArea1.invalidate();
}

#ifndef CUSTOMCONTAINER_EVENT_HPP
#define CUSTOMCONTAINER_EVENT_HPP

#include <gui_generated/containers/CustomContainer_eventBase.hpp>
#include <gui/screen_agenda_screen/Screen_agendaView.hpp>
#include <string>


class CustomContainer_event : public CustomContainer_eventBase
{
public:
    //CustomContainer_event();
    CustomContainer_event(Screen_agendaView& d);
    virtual ~CustomContainer_event() {}

    virtual void initialize();
    void Save_Note()override;


protected:
    int pos_cursor = 0, shif = 1;
    Screen_agendaView& s;
    std::string text;
};

#endif // CUSTOMCONTAINER_EVENT_HPP

CustomContainer_event::CustomContainer_event(Screen_agendaView& s):s(s)
{

}

void CustomContainer_event::initialize()
{
    CustomContainer_eventBase::initialize();
    flexButton_Shift.setPressed(true);
}

void CustomContainer_event::Save_Note()
{
    for (int i = 0; i <= pos_cursor; i++)
        text += textArea2Buffer[i];
    s.SendToView(text);
}

Answer 1

OP could pass class A's this (as pointer) or *this (as reference) to the constructor of the member var. of type class Z. Hence, class Z could store this pointer or reference as member itself and use it for accessing its "parent" class A instance.

Demo:

#include <iostream>

struct A; // forward declaration

struct Z {
  A &a; // Z holds a reference to the associated instance of A

  Z(A &a): a(a) { } // the associated instance of A is passed in constructor

  void call(); // cannot be implemented before A became a complete type
};

struct A {
  Z z; // A has a member var. of `struct Z` to which it will be associated

  A(): z(*this) { } // A passes *this (the reference of its own) to z

  void callZ()
  {
    std::cout << "A::callZ() called.\n";
    z.call();
  }

  void call()
  {
    std::cout << "A::call() called.\n";
  }
};

// now A is complete and Z::call() can use it to access (public) members of A &a

void Z::call()
{
  std::cout << "Z::call() called.\n";
  a.call();
}

int main()
{
  A a;
  a.callZ();
}

Output:

A::callZ() called.
Z::call() called.
A::call() called.

Live Demo on coliru

A class which stores a reference to another instance doesn't come without dangers. When such relations are designed then the (human) author should have the intended life-times in mind.

In this case, struct Z will be used as member of struct A exclusively. So, the associated instance of A will outlive it's member z.

If an instance of a class stores the reference to another instance which is destroyed before the first then the reference (inside the first) becomes dangling (i.e. referencing something which isn't existing anymore). As long as the reference isn't used nothing bad will happen. But accessing the dangling reference is Undefined Behavior. (It could crash or cause strange effects or (most accidental case) seem to work until something strange happens later.)

Example for wrong usage:

int main()
{
  A *pA = new A();
  Z z(*pA);
  z.call(); // That's OK.
  delete pA;
  z.call(); // :-O BAD! z will call z.a.call() although z.a became dangling!
}

---

This design may cause an additional issue because struct A has to know struct Z to access its members and struct Z has to know struct A. That's a hen-egg-problem and C++ isn't the only effected language.

The solution is a forward declaration, in the above sample

struct A; // forward declaration

A forward declaration forms an incomplete type. It can be used to declare pointers and references. Pointers and references of incomplete types may be used only with certain constraints. E.g. sizeof of the pointer to an incomplete type is allowed because it actually doesn't depend on the type itself. (Pointers have always the same size.) In opposition, accessing the pointee of an incomplete type is not possible (as the pointee is of incomplete type and its contents simply not known as long as the type is incomplete).

Circular dependencies may require that declaration and definition of member functions are separated. In the above sample, it is remarked for Z::call():

// now A is complete and Z::call() can use it to access (public) members of A &a

void Z::call()
{
  std::cout << "Z::call() called.\n";
  a.call();
}

Defining classes in headers (as it is usual in C++ projects) may cause the issue of circular header dependencies.

If a.h declares struct A and z.h declares struct Z one might be attempted to #include "z.h" in a.h as well as #include "a.h" in z.h. This doesn't work. Either this will lead to a recursion or the author was clever enough to use header guards (to prevent duplicated definitions). In the latter case, one of the two involved headers will finally try to use the declaration of the other class in its own declaration and fail.

The solution is again a forward declaration of one involved class in the header of the other instead of the resp. #include. Both C++ sources may then include both header files without harm and provide the implementations which are based on both classes. This will, of course, require that the implementation of the resp. methods isn't done inline but separately done in the C++ source.