MQL5 The compiler does not distinguish between a class and a pointer to it - page 11

New comment
 
Ilya Malev:

This one: (* ) is not needed here.

* is needed in the µl only when the operations =, ==, !=, !& or || are applied directly to the * pointer

IMHO it's exactly what you need, so that you don't forget what you're dealing with (an object or a pointer to it).

Ilya Malev:

(If you want to remove it again and pretend it never existed)))

So, yes. Further development with pointers will lead to a complete clone of C++.

Perhaps they will go in the direction of C# where "managed code" has no pointers but everything has an object, even the common types bool int double, etc.

 
Ilya Malev:

And also, by the way, it may well be that since all official channels (forum, help, documentation) are silent about the operator *, perhaps the admins are thinking about removing it again, and pretend that it never existed))) So it is dangerous to rely on its use in general at the moment imho.

The silence is probably because 99.9% of users do not care about it all. Why bother their brains with unnecessary information? And those who needed it, asked for it and got it.

You also did not care about this feature until now, didn't you? And now you're desperately starting to make excuses why you didn't know about it ;) What difference does it make when it was introduced: immediately or after months? You still wouldn't have known about it if I hadn't told you )

 

Hmmm... Maybe there are pointers to the array as well ? I'll have to check it out... I miss them so much...

 
Georgiy Merts:

Hmmm... Maybe there are pointers to the array as well ? I'll have to check it out... I miss them so much...

No. You have to put arrays in classes, they have pointers.

 
Ilya Baranov:

No. You have to put arrays into classes, they have pointers to them.

Yes, alas.

Actually, CArray derived classes are quite handy for me. The only thing I want pointers to arrays for is indicators, they pass references to arrays, and I have to "drag" these references through the whole hierarchy of objects, which is very inconvenient...

I once suggested either making pointers to arrays, or to make an indicator function that would use pointers to Standard Library arrays, rather than array links, but alas, I was rejected on the grounds that "if we allow pointers to arrays, it will be possible to use uninitialized arrays", although the developers don't have such fears with objects... Yeah, well, I'll leave that to their conscience.

 
Georgiy Merts:

2. MQL doesn't have to delete what it didn't select. Dmitriy was right above - create an object - delete it. I don't like the practice of "rubbish collector" in C#, when objects are deleted not when I want them to, but when the collector wants them to.

The C# scavenger will never remove a live object or a pointer. Its purpose is to remove trash from the corpse heap and sometimes defragment it.

 
Alexey Volchanskiy:

Never a C# assembler will delete a live object or a pointer. Its purpose is to remove corpse trash from the heap and sometimes defragment it.

I'm not saying that the rubbish collector will delete a live object or a pointer. What I'm saying is that it will delete it when it wants to. And this, in my opinion, is not good.

I can work with or without deletion. And I can even make smartpoints... Nevertheless, I think that the deletion of objects must be possible and the person who created it must delete the object.

That's the kind of old-school old timer I am.

 
SemenTalonov:

Probably, they will go in the direction of C# where "managed code" has no pointers and everything has an object, even simple types bool int double, etc.

Yes, but they still leave the possibility of working with pointers in unmanaged code. True, such code has distribution restrictions.

 
Georgiy Merts:

I'm not saying that the rubbish collector will delete a live object or a pointer. What I'm saying is that it will delete it when it wants to. And this, in my opinion, is not good.

I can work with or without deletion. And I can even make smartpoints... But, nevertheless, I think that objects should be deleted, and the one who created it should delete it.

That's the kind of old-school old timer I am.

Georges, would you give an example, I don't understand you. Is that what you mean? I guess you can make smartpoints yourself.

bool first = false;

int Foo()
{
  int i;
  if(!first)
  {
     first = true; 
     i = 123;
  }
  return i;   
}

// И ты будешь надеятся, что i сохранит свое значение между сотней вызовов Foo? Может да (очень редко, если Foo вызывается 100 раз подряд), а может и нет.
 
Alexey Volchanskiy:

Georges, would you give me an example, I don't understand you. Is that what you mean? It is probably possible to make smartpoints yourself.

No. It's clear that in this case the variable must be deleted on exit from the block.

I'm talking about objects created by new:

CMyObj* pmoObject  = new CMyObject;

The C# standard specifies:"Both value-type objects, such as structures, and reference-type objects, such as classes, are destroyed automatically, but value-type objects are destroyed when the context containing them is destroyed, while reference-type objects are destroyed by the rubbish collector indefinitely after the last reference to them is removed."

Here, I don't like this "indefinite time". Although, I'll even concede that the rubbish collector can delete an object much more efficiently than I can, by deleting the object in the destructor of the class which created it.

1...45678910111213
New comment