Errors, bugs, questions - page 2415
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
This restriction has been lived with for many years.
The question has arisen for the first time ever
This is some kind of draconian restriction. What's the rationale in today's times? And how is it convenient to specify clusters of a bunch of characters? To multiply a dozen different parameters? Is that convenient?
The rationale is in the exchange protocol with the test agent.
To set a bunch of characters, write that bunch to a text file and pass it using #property tester_file
But with a single test, it is also passed to the test agent and works without restriction.
Why is there a restriction for static input too, it can be not passed to the agent at all.
If it's not even a bug, take it as a request for improvement.
Compiler bug. It generates ambiguity error, although everything is unambiguous here.The first method should be called as the most suitable one. Tested in C++.
How is the best-fit method defined?
The rationale is in the exchange protocol with the test agent.
To specify a bunch of characters, write that bunch to a text file and pass it using #property tester_file
How does this fit in with end-user products? The limit may have been justified before, but I doubt it, based on other amounts of data being transmitted. Increasing the limit does not carry the threat of incompatibility.
How is it determined as suitable?
If we're talking about the C++ standard, then:
13.3 Overload resolution. Overload resolution is a mechanism for selecting the best function to call given a list of expressions that are to be the arguments of the call and a set of candidate functions that can be called based on the context of the call. The selection criteria for the best function are the number of arguments, how well the arguments match the parameter-type-list of the candidate function, how well (for non-static member functions) the object matches the implicit object parameter, and certain other properties of the candidate function. [ Note: The function selected by overload resolution is not guaranteed to be appropriate for the context. Other restrictions, such as the accessibility of the function, can make its use in the calling context ill-formed.
In other words, it should work like this:
If we're talking about the C++ standard, then:
13.3 Overload resolution. Overload resolution is a mechanism for selecting the best function to call given a list of expressions that are to be the arguments of the call and a set of candidate functions that can be called based on the context of the call. The selection criteria for the best function are the number of arguments, how well the arguments match the parameter-type-list of the candidate function, how well (for non-static member functions) the object matches the implicit object parameter, and certain other properties of the candidate function. [ Note: The function selected by overload resolution is not guaranteed to be appropriate for the context. Other restrictions, such as the accessibility of the function, can make its use in the calling context ill-formed.
In other words, it should work like this:
For b2, full unambiguity. b1 is not.
How is the appropriate one determined?
In this example, a non-constant object method is requested, so, all other things being equal, it should be called.
If we remove the casting and make an int type argument for both methods, the code will compile normally. So, the issue in MQL is about the casting. This casting must not affect the code because it is identical.
For b2 there is complete unambiguity. b1 is not.
There is no need for unambiguity here. It should simply be the order in which the overloaded methods are applied. I.e. the task of solving overloading is not to create a dilemma, but to choose the best suitable method. Putting aside the access modifier, it is the first method from the table or it depends on the compiler implementation, but there is no ambiguity.
But if there were 2 methods, with different input parameters for example:
Going back to C++, the same vector has one:
So this is a perfectly normal situation.
How does this fit in with end-user products? The limit may have been justified before, but I doubt it, based on other amounts of data being transmitted. Increasing the limit does not carry the threat of incompatibility.
To start with, in the optimization cache, in both MT5 and MT4 string parameters have always been truncated to 63 characters.
When sending events, the string cannot be longer than 63 characters either.
That is, what comes from outside is limited
As for end user products. The vendor has to take the limitations into account. And if he does not know them, then he has not tested his product sufficiently before selling it