Errors, bugs, questions - page 1892
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
Another question.
The work of a tread.
please explain what a protector is in programming
Yes, here is an example demonstrating your question:
and output:First, we check the unresolved cast from the bottom up and get NULL. This is correct.
Then we create a CLASS2 object, assign a reference to it to its parent class (here it's important to understand that dynamically the environment knows that CLASS2 object's original type is stored in its meta-information). Then (just your question) dynamically cast (with conversion right checking based on source object's metainformation) from reference CLASS1 to CLASS2.
We check the result of casting and write it into variable i = 1. Finally we output the value of i, referring to the originally created object.
Everything works correctly and according to the specification (including dynamic_cast spec in C++ itself).
Thanks for the clarification, I kinda got it in MQL for type conversion)) But I don't know what for we need dynamic_cast if we can't cast from the bottom upwards anyway and we can do without dynamic_cast from the top downwards? Maybe there are some subtleties here and I don't understand them?
Re-read the code and my explanation again, please.
It also demonstrates how dynamically cast can safely raise the cast from the bottom up based on the meta-information of the originally created object. If an object was created from a descendant, then converted to a parent class reference, then based on the metainformation(the original object is actually a descendant) you can safely convert that reference to a descendant.
Typically used when objects of various descendants are stacked in an array/list of references to the parent class, and then retrieved and safely cast to one or the other descendant. If the conversion yields NULL, it means the object is not fetched by the descendant and shouldn't be handled.
Re-read the code and my explanation again, please.
It also demonstrates how dynamically cast can safely raise the cast from the bottom up based on the meta-information of the originally created object. If an object was created from a descendant, then converted to a parent class reference, then based on the metainformation(the original object is actually a descendant) you can safely convert that reference to a descendant.
Typically used when objects of various descendants are stacked in an array/list of references to the parent class, and then retrieved and safely cast to one or the other descendant. If the conversion yields NULL, it means the object is not fetched by descendant and it shouldn't be handled.
I read the code, but isn't this:
CLASS2 *my_ptr2=dynamic_cast<CLASS2 *>(my_ptr);isn't analogous to this:
I cannot grasp the very subtlety of using dynamic_cast, except that when executing code using dynamic_cast we will not get an error because dynamic_cast returns NULL in case of error
I read the code, but isn't this:
isn't similar to this:
I can't grasp the subtlety of using dynamic_cast, except that we won't get an error when executing code using dynamic_cast because dynamic_cast returns NULL in case of error
I recommend to read C++ dymanic_cast specification on google.
It is a trivial thing.
When giving out PC resources in cludes crashes when starting the game - the game"Call of Duty: BlackOpsIII" crashes - 1 agent was involved. The priority of the agent was minimal - the memory consumed 3.5 gigabytes of 16 - in general there should be no problems. With non-active agents the game played fine. Generally tested on the compatibility of agents with other programs?
For some reason I thought at once that perhaps the bug in the game and connected it with the peculiarities of work on 64 bit machines when the program is loaded into the address space > 4 GB
For some reason immediately came the idea that perhaps a bug in the game and connected it to the peculiarities of working on 64-bit machines, when the program is loaded into the address space > 4 GB
I.e. to check this hypothesis I need to fill RAM more than 4 gigabytes and run the game - I'll try when my son plays it.