Help with OOP - page 4

New comment
 
Vasiliy Sokolov #:

Officially, yes. Unofficially, many things indicate that it does exist:

  • There are no pointers in MQL. Instead, they are replaced by something that looks a lot like them.
  • There is no direct memory allocation in MQL, as in C for example;
  • Programs in MQL are executed by a certain virtual machine. Renat wrote about it briefly and not once;
  • The class instance can be defined that will be freed automatically. So, there is some mechanism that monitors these instances and releases them when necessary. What is that if not a rubbish collector?
  • Any instances initialized through a pointer and not properly freed will be marked as leaked objects on exit. Their number and total size of lost memory will be printed. A program with leaked memory will not even be validated in Market. Hence all objects, even manually allocated ones, are accounted for, known and known to the system. This is one of the classic tasks that the rubbish collector solves.

There is one sufficient and comprehensive indication that there is no rubbish collector in emcool - delete is mandatory after new.

 
Dmitry Fedoseev #:

There is one sufficient and sufficient indication that there is no rubbish collector in emcool - delete is mandatory after new.

As far as I remember, one of the developers acknowledged that there is a rubbish collector. But for the user it "sort of doesn't exist".

Well, about new-delete pair - I'm all for it. In general case, the objects that requested resources must be responsible for them. There are exceptions, like "object factory" - but there it is specifically assumed that the responsibility for the created objects lies with the one who requested these objects from the factory.

I do not like the situation in languages where there is new and delete is not required, as the "system will clean up". This not only potentially reduces performance (when unnecessary objects are not removed yet), but also relaxes the coder, allowing him not to care about the consequences of his actions.

 
Georgiy Merts #:

I really don't like the situation in languages where new is there, but delete is not required, saying "the system will remove unnecessary". This not only potentially reduces performance (when unnecessary objects are not removed yet), but also relaxes the coder, allowing him not to care about the consequences of his actions.

Productivity, on the other hand, is generally improved. Manual removal takes a lot of time in the main thread. + deletion is done element by element. Compare the two versions of the script in this thread, for example. Difference in speed is several times. Memory efficiency also goes up. Because rubbish collector moves objects compacted with each other. If you manage it manually, it creates free memory holes which are not so easy to reuse. Plus, the garbage collector works in a different thread. Basic time is not wasted. All in all, one plus.

 
Vasiliy Sokolov #:

Productivity on the contrary is generally increased. Manual removal requires a considerable amount of time in the main stream. + deletion is done element by element. Compare two versions of the script in this thread, for example. Difference in speed is several times. Memory efficiency also goes up. Because rubbish collector moves objects compacted with each other. If you manage it manually, it creates free memory holes which are not so easy to reuse. Plus, the garbage collector works in a different thread. Basic time is not wasted. All in all, it's just a plus.

Vasily, I'm sorry, but you do not understand at all what you are trying to talk about. Not at all and in no way.

At least read Wikipedia what a rubbish collector is. Its main peculiarity is that it removes objects, communication with which has been lost.

Only in this case it would be called a rubbish collector. Those two scripts are from a different story. God's gift is not to be confused with an egg.

And why would a garbage collector suddenly increase productivity? It is one more padding between the useful code and the hardware, and not a weak one at that.

 
Georgiy Merts #:

As I recall, one of the developers acknowledged that the rubbish collector does exist. But for the user it is 'sort of gone'.

///

This is probably the "garbage collector" which gives a message about memory leakage at the end of work.

Maybe it even deletes abandoned objects. But even if it removes them, there's a big

difference - it only deletes them at the end of the job. And if in a multi-thousand cycle new objects are created?

new objects? The program will be inoperable, not enough memory.

A real assembler deletes lost objects during the programme operation, not

only at the end of the program. That's why a special programming style is allowed.

we can multiply objects under any conditions and in any quantity.

 
Vasiliy Sokolov #:

Productivity on the contrary is generally increased. Manual removal requires a considerable amount of time in the main stream. + deletion is done element by element. Compare two versions of the script in this thread, for example. Difference in speed is several times. Memory efficiency also goes up. Because rubbish collector moves objects compacted with each other. If you manage it manually, it creates free memory holes which are not so easy to reuse. Plus, the garbage collector works in a different thread. Basic time is not wasted. All in all, one plus.

Hmm... And in a rubbish collector, deletion is non-elemental? Not to mention that the other thread, when there are no free cores, is done by the same core, and slows down the main thread.

In my opinion, in the general case, with careful consideration, rubbish removal by the user is always more efficient than removal by the garbage collector. However, if you don't care, the rubbish collector certainly wins.

This is why I don't like the garbage collector, because it encourages this same indifferent treatment of resources.

 
Dmitry Fedoseev #:

This must be the "assembler" that gives the message about memory leaks when the job is finished.

It probably even deletes leftover objects. But even if it deletes them, there is a big

difference - it only deletes them at the end of the job. And if in a multi-thousand cycle new objects are created?

new objects? The program will be inoperable, not enough memory.

A real assembler deletes lost objects during the programme operation, not

only at the end of the program. That's why a special programming style is allowed.

we can multiply objects under any conditions and in any quantity.

That's right. That's why I don't like to work with assembler - the user doesn't pay attention, how many objects he/she has created and where.

Basically, it even simplifies development in some way - you don't have to remember to delete the busy one. Builder finds the moment when the object is no longer referenced, and it removes it. But this position disgusts me. It is because of this position that we have programs that run slower and slower, that need more and more powerful hardware resources for tasks of similar complexity.

 
Dmitry Fedoseev #:

Vasily, I'm sorry, but you don't understand anything at all about what you are trying to argue. Nothing at all and in no way at all.

Dmitry, excuse me, do you know any programming language other than mukl? No, you don't. And you still haven't learned how to work with objects and pointers, it's clear from those few codes and even articles you've published. That's why I cannot even seriously reply to this talentless and frankly stupid comment. Read at last wikipedia, learn what a rubbish collector is and how it is organized, finally read at least once what you are trying to refer to. So far, it all looks like a dog barking at a caravan: senseless and merciless.
 
Georgiy Merts #:

Hmmm... And in the rubbish collector is deletion non-elemental? Not to mention the fact that another thread, when there are no free cores - is done by the same core, and slows down the main thread.

In my opinion, in general, with careful consideration, rubbish removal by the user is always more efficient than removal by the garbage collector. However, if you don't care, the rubbish collector certainly wins.

That's why I don't like the garbage collector, it encourages this same indifferent treatment of resources.

Rather than making assumptions about how a garbage collector works, just compare the speed of automatic object removal to manual removal. All fantasies will vanish at once.

 
Vasiliy Sokolov #:

compare the speeds of automatic object removal and manual object removal.

The answer is preferably right away. There isn't always time for experimentation.

123456789
New comment
Reason: