Libraries cannot handle circular dependent classes

[SebastianR]

Hello everyone!

For bug let's create a simple setup in any WinCCOA project by creating two library CTRL scripts called A.ctl and B.ctl which can be described as follows:

A.ctl

Code: Select all

#uses "B"

class A
{
  public A()
  {}

  public void print(string s)
  {
    DebugN(s);
  }

  public B giveB()
  {
    B ret = B();
    return ret;
  }
};

B.ctl

Code: Select all

//#uses "A"

class B
{
  public B()
  {}

  public void print(string s)
  {
    DebugTN(s);
  }

  //public A giveA()
  //{
  //  A ret = A();
  //  return ret;
  //}
};

Here we have two classes, where class A depends on class B so far (ignoring the commented out code) for some functionality.
At this point we could also write some code and execute it with the help of a CTRL manager.

test.ctl

Code: Select all

#uses "A"

void main()
{
  A test = A();
  test.print("something");
  
  B test2 = test.giveB();
}

This works fine, but we want to add more functionality.
When we comment in the commented out code from class B, which provides us functionality to acquire an object of the type A, we notice the following when starting the CTRL manager again.

Code: Select all

WCCOActrl    (5), 2019.03.01 10:50:11.843, CTRL, WARNING,    81, Syntax error, D:\Projects\SIS_PV_1.0_RC24\FirstEmptyProject\scripts\libs\B.ctl,   Line: 13
  public A giveA()
           ^
WCCOActrl    (5), 2019.03.01 10:50:11.849, CTRL, WARNING,    81, Syntax error, D:\Projects\SIS_PV_1.0_RC24\FirstEmptyProject\scripts\libs\A.ctl,   Line: 3
class A
^
WCCOActrl    (5), 2019.03.01 10:50:11.855, CTRL, WARNING,    81, Syntax error, test.ctl,   Line: 6
void main()
^

This is a bit odd.
Just in case we actually coded wrong, let's just comment out the giveA() function and it's contents while keeping the #uses statement.

Code: Select all

WCCOActrl    (5), 2019.03.01 10:52:29.887, PARAM,WARNING,     7, Datapoint does not exist, CtrlDbg::init, _CtrlDebug_CTRL_5.Command
WCCOActrl5:["something"]

Our code works again, now let's just add a private field of type A to the B class, this is pretty easy and should not throw an error.

Code: Select all

#uses "A"

class B
{
  private A myField;

  public B()
  {}

  public void print(string s)
  {
    DebugTN(s);
  }

  //public A giveA()
  //{
  //  A ret = A();
  //  return ret;
  //}
};

And when we start our CTRL manager we get the following..

Code: Select all

WCCOActrl    (5), 2019.03.01 10:55:02.090, CTRL, WARNING,    81, Syntax error, D:\Projects\SIS_PV_1.0_RC24\FirstEmptyProject\scripts\libs\B.ctl,   Line: 5
  private A myField;
            ^
WCCOActrl    (5), 2019.03.01 10:55:02.097, CTRL, WARNING,    81, Syntax error, D:\Projects\SIS_PV_1.0_RC24\FirstEmptyProject\scripts\libs\A.ctl,   Line: 3
class A
^
WCCOActrl    (5), 2019.03.01 10:55:02.103, CTRL, WARNING,    81, Syntax error, test.ctl,   Line: 6
void main()
^

It appears that the CTRL manager/interpreter can't resolve this circular dependency for some reason.
When trying to put both classes in the same file, it fails also, because forward declaration doesn't work in CTRL and you have to declare one class before the other, which prohibits the first class to use any member of a type that is defined only after itself.
I would really appreciate if CTRL++ would allow for circular dependencies in some form.

Is this by design?
Is there a way to fix this?
Will a future update address this issue?

[gschijndel]

I guess this is by design.
I would suggest to create at least a new 'interface' class, which defines the needed interface and can be used in the implementations to provide the interface(s). The implementation derives from this 'interface' class and implements the functionality, but the functions 'giveA/B' should return a shared pointer otherwise it will not work.

[SebastianR]

I guess this is by design.
I would suggest to create at least a new 'interface' class, which defines the needed interface and can be used in the implementations to provide the interface(s). The implementation derives from this 'interface' class and implements the functionality, but the functions 'giveA/B' should return a shared pointer otherwise it will not work.

Sounds like it could work... however would you be so kind as do elaborate on how exactly you would go about defining and implementing such 'interface' classes?
I would have to create seperate file (eg "IA.ctl" and "IB.ctl") which contain classes (eg "IA" and "IB" respectively).
Now I would change the uses statements in the original files to use both IA and IB, so I can derive and return the right objects.

However then I don't know how I declare the shared_ptr return type since it needs something like shared_ptr<IA> but this would require me again to have a uses statement towards IA.ctl and vice versa doesn't it?
Wouldn't this just move the problem from the original classes to the 'interface' classes or am I missing something?