Errors, bugs, questions - page 2415

New comment
 

This restriction has been lived with for many years.

The question has arisen for the first time ever

 
Stanislav Korotky:

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.

 
Alexey Navoykov:

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?

 
Slava:

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.

 
fxsaber:

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:

class A { };

class B
{
  A _a[];
 public:
        A * operator[](uint i)       { return &_a[i]; }
  const A * operator[](uint i) const { return &_a[i]; }  
};

void OnStart()
{
  B b1;
  const B b2;
  b1[0]; // []
  b2[0]; // [] const
}
 
Andrey Pogoreltsev:

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.

 
fxsaber:

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.

 
fxsaber:

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:

class B
{
  A _a[];
 public:
        A * operator[](int i)  {...}
        A * operator[](bool i) {...}  
};
B b;
b[0];    // ok
b[true]; // ok
b[0 u];   // ambiguous call to overloaded function

Going back to C++, the same vector has one:

reference       operator[]( size_type pos );
const_reference operator[]( size_type pos ) const;

So this is a perfectly normal situation.

 
Stanislav Korotky:

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

1...240824092410241124122413241424152416241724182419242024212422...3190
New comment