FIXED: call non-const method for constant object error after updating to build 3440

[f.pap]

I have found a problem in some code that compiled correctly before updating to build 3440.

I have simplified the problem to these few lines of code:

class CA
{
  uint m_a;
  
 public:
  CA(): m_a(0)
  { }

  uint Get() const { return m_a; }

  void Set(uint a) { m_a = a; }
};


class CB
{
  CA m_ca;

 public:
  CB()
  { }

  CA *GetPtr() { Print("non const"); return GetPointer(m_ca); }

  const CA *GetPtr() const { Print("const"); return GetPointer(m_ca); }

  uint Get() const { return GetPtr().Get(); }

  void Set(uint a) { GetPtr().Set(a); }
};


void OnStart()
{
  CB cb;
  
  cb.Get();  
  cb.Set(10);  
}

The error I get is the following:

'Set' - call non-const method for constant object       const.mq5       39      30

This code compiles perfectly on an older release, for example with build 3325, and, launching this script on a EURUSD chart, I obtain:

2022.09.21 22:14:47.270 const (GBPUSD,D1)       const
2022.09.21 22:14:47.271 const (GBPUSD,D1)       non const

demonstrating that it calls the right version (const / non const) of the GetPtr() function.

This problem can be solved by renaming one of the two GetPtr() functions and explicitly calling the const or the non const version, showing that the compiler is no longer able to automatically discriminate between the two.

Is this a bug of the new build?

Thank you for your help.

[William Roeder]

f.pap: This problem can be solved by renaming one of the two GetPtr() functions and explicitly calling the const or the non const version, showing that the compiler is no longer able to automatically discriminate between the two.

Is this a bug of the new build?

There was no way to "discriminate between the two". It should have been caught and not compiled previously.

It is a bug, as it could not have compiled.

[f.pap]

William Roeder #:

There was no way to "discriminate between the two". It should have been caught and not compiled previously.

It is a bug, as it could not have compiled.

Actually, there IS a way to discriminate between the two: the compiler chooses the const overload when the function is called on a const object (or via a reference or pointer to const), it chooses the other overload otherwise.

So the compiler uses the const version of the CA::GetPtr() function with the CB::Get() and the non const version with the CB::Set().

Defining two versions const / non const of the same function, especially the ones returning pointers, is usual practice in other languages, like C++. This also worked perfectly with the previous builds of MT5, because the compiler was able to correctly choose the right version of the function to use, as my script (compiled with build 3325) shows through the strings that are printed and that can be seen in my previous message.

This is the reason why I think that this limitation to function overloading was inadvertently added to the latest build and, in this hypothesis, is to be considered a bug of the latest build.

[f.pap]

Just to inform that this problem has now been fixed, at least in build 3800 but maybe even before.

[Alain Verleyen]

f.pap #:
Just to inform that this problem has now been fixed, at least in build 3800 but maybe even before.

It was fixed a long time ago. It compiles in 3661.