Calling parent function

Using Arduino Programming Questions
1

I am trying to implement a call for a parent class function without success.

the base class is :

class Base
{
    
    
public:
    
    Base();
     child *children;
    float theDelegate(char *arg);

Then the child needs to declare its parent with :

class child: public Base
{
    
    
public:
...

But in order for the child to see Base , I must include the Base class in the child (other wise I get an error that he does not know Base)

but this #include "Base.hpp" , will cause an error on the Base, since they include each other.

(error is on line child *children; saying unknown type name Child" ).

How can i resolve this ?

2

gil22:
(error is on line child *children; saying unknown type name Child" ).

Check your capilatization, unless you typed that from memory and didn't copy+paste.

Do you have include guards in your header files? They are a must for exactly this reason.

Children do not necessarily have to be a derived type of the parent. A little less abstraction and a lit more specifics can help use see if this is an example of the X-Y problem.

You must include base.hpp in child.hpp, but do not include child.hpp in Base.hpp. Simply add a forward declaration of the child class above the base class in base.hpp:

class child;

That's it.

3

If I remove the include of the child from the parent I get errors because obviously he can not see it now , even if I add the "class child"

class Base;


class Base
{
    
    
public:

    Child *child;

....
.cpp
    child =new child(built);   // ** error - allocation of incomplete type child
4

gil22:

class Child;  //  <-- !!! Like this here !!!

class Base
{
   
   
public:

Child *child;

....
.cpp
    child =new child(built);  // ** error - allocation of incomplete type child

Also, your capilization seems to be all over the place. Are you class names in uppercase, or the object names? Fix it. C++ is sensitive to that.

5

Ok I still struggle with errors , maybe you can spot what it is, so , there is the parent class :

parent .h

class Child;


class Parent
{
    
    
public:
    
    Parent();
    int sendData(char*cmd);
    EEprom *eeprom;
    Child *intepreter;

The Parent .m :

Parent:: Parent()
{
    
    char *builts[]={"me","you",NULL };
    eeprom=new EEprom();
    intepreter=new Child(built);   /// if I remove the include there is error here !
  
 }

The the child is like this (.h)

#include "Parent.hpp"


class Child  : public Parent

Removing the include child , from the parent , will cause parent to not recognise when I try to construct the child.

6

To fix your immediate problem, #include "child.h" in parent.cpp (not the header, the source file).

There may be a deeper issue though. What are these classes doing? Does Child need to inherit from Parent? Currently, this example is very abstract so I can't help you with that.

I don't mean this to be rude, but since you are having this much trouble with such a basic thing like what headers are supposed to be included in which files, I don't have any confidence that you understand what inheritance is for and are using it properly. You may be confusing the Base->Derived relationship that inheritance is for with the Parent->Child relationship that is implemented in a different way. Children of a class do not have to be a derived type of the class.

The common term for this is the "X-Y" problem. In short, you want to do X, and think Y is the way to do it, so you ask questions about Y. However, all the good help in the world won't matter if Y isn't a proper way to do X.

You're telling us Y. Tell us X instead, and we can help make the proper class design for what you want to do.

7

The fact that you need to make that kind of circular reference is a good indication that your class hierarchy is seriously flawed, and you need to put more thought into how you abstract things. Data/information flow should be one direction.

Regards,
Ray L.

8

RayLivingston:
The fact that you need to make that kind of circular reference is a good indication that your class hierarchy is seriously flawed, and you need to put more thought into how you abstract things. Data/information flow should be one direction.

Regards,
Ray L.

I think that statement is quite a lot stronger than it needs to be. There are perfectly valid reasons why you might have circular calling references like that.

For example, at my job we have a particular piece of software that uses what is called a utility file that contains interpreted instructions that direct the program to perform certain sequences of events. The file contains a numbered sequence of steps, and each set has a set of goto fields that say which step number to go to next depending on the result of the step.

To help programmatically generate these files, I created my own program with separate classes called utility, step, and goto_field.

For the goto field, I created 3 different ways of referring addressing the step that would be converted to the proper step number when it was written out to file: absolute (Step #), relative (next step, or 3 steps back), and pointer (this specific step, no matter where it may be rearranged in the list).

So suppose I have a goto_field referring to a step by its pointer, and the step it's pointing to is deleted in the course of the utility object. I now have a dangling pointer to something that no longer exists. How do I fix that?

The easiest way I came up to do it was to have the step class track all the goto_fields that were pointing to it. When the goto field pointed to the step, it called a step::register_reference function that added a pointer to itself to the step's list. When it no longer pointed to that step (or was destroyed) it unregistered the reference.

In step's destructor, I have it loop through all the references in the list and call the set_invalid() function to set the goto's reference pointer to nullptr.

So step is calling functions on goto_field pointers, and goto_fields are calling functions on step pointers.