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
Technical reference. An example of a "wrapping mechanism" when working with classes (so you don't have to search for it):
https://www.mql5.com/ru/forum/3555/page3#comment_57315
Question. The new operator. The Reference Manual states that new is an operator; however, in the examples, a check is often made after using this operator to make it equal to NULL. For instance:
It is also said that"NULL can be compared to pointers to objects created using the new operator".
So it turns out that the new operator does not always create a new object? Or is checking for equality of a created object to NULL a peculiarity of a developer's style and is not obligatory?
Question. The new operator. The Reference Manual states that new is an operator; however, in the examples, a check is often made after using this operator to make it equal to NULL. For instance:
It is also said that"NULL can be compared to pointers to objects created using the new operator".
So it turns out that the new operator does not always create a new object? Or is checking for equality of a created object to NULL a peculiarity of a developer's style and is not obligatory?
If you create a dynamic object in one place in a program, it is logical that you will destroy it in another place, and it is not certain that all this is within one function, so a simple rule is to check if it exists before using a pointer.
This is correct. But in the examples in the Reference Manual, the check is done immediately after the object is created, i.e. at one place in the program and within one function. And the rule given here is not quite on point. Why should the check be performed right after creation of an object?So it turns out that the new operator does not always create a new object? =(I repeat)=
Here is one more example among many:
This is correct. But in the examples in the Reference Manual, the check is done immediately after the object is created, i.e. in one place in the program and within one function. And the above rule is not applicable here. Why should the check be performed right after the object is created?So it turns out that the new operator doesn't always create a new object (I repeat that)?
Here is one more example among many:
There is such a possibility. In the reference, the first paragraph.
OK. It turns out that the operator's behaviour is that of a function. It may or may not be created.
For example, there wasn't enough memory for an object.
Question. After declaring a virtual function with a certain set of parameters and types in a parent class, is it possible to change the number and types of parameters of corresponding virtual functions in descendant classes?
On the one hand, the Reference Manual states that "a virtual function may be substituted in a derived class. The choice of which function definition to call for the virtual function is made dynamically (at runtime). A typical case is when a base class contains and derived classes have their own versions of that function". On the other hand, the examples given in the Reference Manual refer to cases where virtual functions have different function definition bodies rather than function definition headers .
Question. After declaring a virtual function with a certain set of parameters and their types in a parent class, is it possible to change the number and types of parameters of the corresponding virtual functions in the child classes?