Questions on OOP in MQL5 - page 8
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
do not write delete - everything will work correctly, this sin (I mean superstition)) ) will take over the terminal and will mutter in its log "48 bytes of leaked memory", then "2 objects of type CX left" and "undeleted objects left"
HH: in the indicator template there is no Deinit() - this is annoying
Why not create an object, not a pointer? Then it won't mumble either - the terminal subsystem will track it down and nail it when needed.
It will work without delete, but it's no use. But does the terminal take care of this problem? It only reports memory leaks, but does not devote the same objects.
The terminal will take care of deleting objects created by new in case pointers to them are stacked in an object known to the terminal, e.g. ArrayObj, List, etc...
Why not create an object instead of a pointer? Then it won't mumble either - the terminal subsystem will track it down and nail it when needed.
becausehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Terminal will take care of deleting objects created by new in case pointers to them are stacked in an object known to terminal, e.g. ArrayObj, List, etc...
not always convenient unsupervised destruction, but I'll have to check, maybe I'm wrong - I rarely use CObject
becausehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
This is a very special and grotesquely simplified case. To create an object that cannot be changed, so that to change its fields, you have to nail it down and create a new one...
And if we need to change a couple of object fields and leave other fields with necessary information? IMHO - better to take care of interactivity and manageability of each object (thanks to inheritance), than to sit with a gun and shoot rabbits at every sneeze.
Although, to be fair - sometimes it's faster to kill and create a new one, than to look for desired object among large number and change it. Unless, of course, there's a direct link to it...
Well, this is a very special and grotesquely simplistic case, in my opinion. To create an object which is absolutely unchangeable, so that to change the values of its fields you have to nail it down and give birth to a new one...
And if we need to change a couple of object fields and leave other fields with necessary information? IMHO - better to take care of interactivity and manageability of each object (thanks to inheritance), than to sit with a gun and shoot rabbits at every sneeze.
Although, to be fair - sometimes it's faster to kill and create a new one, than to look for the required one among a large number and change it. Unless, of course, you have a direct link to it...
hmmm, you're way off base.... yes, but not like that ))))
as it's convenient, that's how you should use it! - and these examples from "the first c++ textbook" can be pulled in your experience all your life.... as an example, i took apart a decent part of@fxsaber's code and made myself use #define as much as possible - the codes became not only shorter, but really more readable and eliminated typos - do they teach that much in C++ books? ;)
Although, to be fair - sometimes it's faster to kill and create a new one, than to look for a required one among a large number and change it. Of course, if there's no direct addressing to it...
and about the book basics... According to "good breeding rules" in programming, the following is expected: you must declare a variable and immediately initialize it (this allows you to avoid bugs when debugging), in OOP the constructor serves for these purposes - you created an object and initialize it all
if you need to "pull the entire code after a simple object", you will need a method to re-initialize all the class fields - why duplicate this? - kill/create = result.... but again, it's a matter of taste and religion.
becausehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
not always comfortable with unsupervised destruction, but will have to check, maybe I'm wrong - I rarely use CObject
But you do use lists. And it is the same there. Well unless the flag of memory management FreeMode() isn't reset for the list - in this case the terminal won't trace - all is undertaken by the user. But this situation is needed to be able to change, delete, sort and to do something else with a copy of the list - in fact the list is created with pointers to objects, and if you create a new list a copy of one of the lists, and start to change objects in the new list (there pointers to objects), then in the original list objects will be changed (because we work with pointers). That's to keep the original and fiddle with his copy, then you need to drop the flag of memory management for a copy: FreeMode(false) - then the copy becomes an independent copy, and you can safely work with objects in it, without affecting the original. And remember, that when you unbind list copy from terminal subsystem, then for the deleting of list objects now responsible ourselves. You can either track it and delete it in OnDeinit(), that's in the simplest case and if the copy-list is known to us before, or create an object-list, which always places newly created lists, not known before with the flag of manual memory management. Then the terminal will track this list object and correctly delete the lists stacked in it.
The terminal will take over the deletion of objects created by new in case the pointers to them are stacked in an object known to the terminal, e.g. ArrayObj, List, etc...
Then there will be no leakage message either.
Then there won't be a report of a leak, either.
Yes, it won't. Because there won't be a leak.
If we have created a new object somewhere and received a pointer to it, we must delete this object by the given pointer. It means that we need to track the pointer. For this purpose, the lists or arrays of pointers to objects, offered in SB, are very good. But you can also take care of tracking and controlling of the newly created objects. But, as for me, why write tons of code if it's already provided?
then they should delete this object by this pointer.
But, as for me, why write tons of code if it is already provided?
What tons are we talking about? Everything you missed is reported by the terminal and the place to delete it is also known - OnDeint() .... So this discussion has boiled down to a discussion of a spherical horse in a vacuum? )))
hmm, you've got to be kidding me..... like that, but not like that ))))
as it's convenient, that's how you should use it! - and these examples from "the first s++ textbook" can be pulled in your experience all your life.... as an example, i took apart a decent part of @fxsaber's code and made myself use #define as much as possible - the codes became not only shorter, but really more readable and typo-free - do they teach that much in C++ books? ;)
And about the book basics... Good breeding rules say: proclaim a variable and immediately initialize it (this allows you to avoid bugs when debugging), in OOP the constructor serves for this purpose - you created an object and initialize everything
if you need to "pull the entire code after a simple object", you will need a method to re-initialize all the class fields - why duplicate this? - kill/create = result.... but again, it's a matter of taste and religion.
I'm not talking about complete re-initialization of an object, but partial - when a couple of fields need to be changed and the rest couple of dozens of fields still store the information you need... We may or may not want to change fields, but we need methods of changing them. Unless - again - we are talking about a simple object with one field. If there are two or more - you may already need to change one, leaving the others unchanged.
But maybe we're talking about different things?