13.3 과부하 해결. 과부하 해결은 호출의 인수가 될 표현식 목록과 호출 컨텍스트를 기반으로 호출할 수 있는 후보 함수 세트가 주어지면 호출할 최상의 함수 를 선택하기 위한 메커니즘입니다. 최상의 함수에 대한 선택 기준은 인수의 수, 인수가 후보 함수의 매개변수 유형 목록과 얼마나 잘 일치하는지, 객체가 암시적 객체 매개변수와 얼마나 잘 일치하는지(비정적 멤버 함수의 경우) 및 특정 기타입니다. 후보 함수의 속성 [ 참고: 과부하 해결에 의해 선택된 기능은 컨텍스트에 적합하다는 보장이 없습니다. 함수의 액세스 가능성과 같은 다른 제한은 호출 컨텍스트에서 잘못된 형식으로 사용할 수 있습니다.
저것들. 다음과 같이 작동해야 합니다.
class A { };
class B
{
A _a[];
public :
A * operator []( uint i) { return &_a[i]; }
const A * operator []( uint i) const { return &_a[i]; }
};
voidOnStart ()
{
B b1;
const B b2;
b1[ 0 ]; // []
b2[ 0 ]; // [] const
}
13.3 과부하 해결. 과부하 해결은 호출의 인수가 될 표현식 목록과 호출 컨텍스트를 기반으로 호출할 수 있는 후보 함수 세트가 주어지면 호출할 최상의 함수 를 선택하기 위한 메커니즘입니다. 최상의 함수에 대한 선택 기준은 인수의 수, 인수가 후보 함수의 매개변수 유형 목록과 얼마나 잘 일치하는지, 객체가 암시적 객체 매개변수와 얼마나 잘 일치하는지(비정적 멤버 함수의 경우) 및 특정 기타입니다. 후보 함수의 속성 [ 참고: 과부하 해결에 의해 선택된 기능은 컨텍스트에 적합하다는 보장이 없습니다. 함수의 액세스 가능성과 같은 다른 제한은 호출 컨텍스트에서 잘못된 형식으로 사용할 수 있습니다.
여기에 확신이 필요하지 않습니다. 오버로드된 메서드가 적용되는 간단한 순서가 있어야 합니다. 저것들. 과부하를 해결하는 작업은 딜레마를 만드는 것이 아니라 가장 적합한 방법을 선택하는 것입니다. 액세스 한정자가 삭제되면 테이블의 첫 번째 메서드가 사용되거나 컴파일러 구현에 따라 다르지만 여기에는 모호성이 없습니다.
이제 입력 매개변수가 다른 2개의 메소드가 있는 경우, 예를 들면 다음과 같습니다.
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
우리는 수년 동안 이 한계를 안고 살았습니다.
라는 질문이 처음으로 제기되었습니다.
이것은 일종의 엄격한 제한입니다. 오늘날의 근거는 무엇입니까? 그리고 여러 캐릭터에서 클러스터를 설정하는 것이 얼마나 편리한가요? 12개의 다른 매개변수를 생성하시겠습니까? 편안해?
테스트 에이전트 와 교환 프로토콜의 정당화.
문자 묶음을 설정하려면 해당 묶음을 텍스트 파일에 작성하고 #property tester_file을 사용하여 전달합니다.
하지만 한번 의 테스트로 테스트 에이전트에게도 전달되어 제한 없이 작동합니다.
그리고 정적 입력에도 제한이 있는 이유는 에이전트에 전혀 전달할 수 없습니다.
버그가 아니더라도 개선을 위한 요청으로 받아들이시기 바랍니다.
컴파일러 버그. 여기에서는 모든 것이 모호하지 않지만 모호성 오류가 발생합니다. 첫 번째 방법이 가장 적절하다고 할 수 있습니다. C++에서 확인했습니다.
올바른 것은 어떻게 결정됩니까?
테스트 에이전트 와 교환 프로토콜의 정당화.
문자 묶음을 설정하려면 해당 묶음을 텍스트 파일에 작성하고 #property tester_file을 사용하여 전달합니다.
이것이 최종 사용자 제품에 어떻게 적합합니까? 이전에는 제한이 정당화되었을 수 있지만 전송된 다른 양의 데이터를 기반으로 하면 의심스럽습니다. 제한을 늘려도 비호환성 위협이 발생하지 않습니다.
올바른 것은 어떻게 결정됩니까?
C ++ 표준에 대해 이야기하면 다음과 같습니다.
13.3 과부하 해결. 과부하 해결은 호출의 인수가 될 표현식 목록과 호출 컨텍스트를 기반으로 호출할 수 있는 후보 함수 세트가 주어지면 호출할 최상의 함수 를 선택하기 위한 메커니즘입니다. 최상의 함수에 대한 선택 기준은 인수의 수, 인수가 후보 함수의 매개변수 유형 목록과 얼마나 잘 일치하는지, 객체가 암시적 객체 매개변수와 얼마나 잘 일치하는지(비정적 멤버 함수의 경우) 및 특정 기타입니다. 후보 함수의 속성 [ 참고: 과부하 해결에 의해 선택된 기능은 컨텍스트에 적합하다는 보장이 없습니다. 함수의 액세스 가능성과 같은 다른 제한은 호출 컨텍스트에서 잘못된 형식으로 사용할 수 있습니다.
저것들. 다음과 같이 작동해야 합니다.
C ++ 표준에 대해 이야기하면 다음과 같습니다.
13.3 과부하 해결. 과부하 해결은 호출의 인수가 될 표현식 목록과 호출 컨텍스트를 기반으로 호출할 수 있는 후보 함수 세트가 주어지면 호출할 최상의 함수 를 선택하기 위한 메커니즘입니다. 최상의 함수에 대한 선택 기준은 인수의 수, 인수가 후보 함수의 매개변수 유형 목록과 얼마나 잘 일치하는지, 객체가 암시적 객체 매개변수와 얼마나 잘 일치하는지(비정적 멤버 함수의 경우) 및 특정 기타입니다. 후보 함수의 속성 [ 참고: 과부하 해결에 의해 선택된 기능은 컨텍스트에 적합하다는 보장이 없습니다. 함수의 액세스 가능성과 같은 다른 제한은 호출 컨텍스트에서 잘못된 형식으로 사용할 수 있습니다.
저것들. 다음과 같이 작동해야 합니다.
b2의 경우 완전한 고유성이 있습니다. b1 - 아니요.
올바른 것은 어떻게 결정됩니까?
음, 분명히 호출 서명과 가장 잘 일치하는 것입니다. 이 예에서는 상수가 아닌 객체의 메서드를 요청하므로 ceteris paribus를 호출해야 합니다.
두 메서드 모두에 대해 int 형식의 인수를 만들어 거기에서 캐스팅을 제거하면 정상적으로 컴파일됩니다. 저것들. MQL의 개그는 바로 캐스팅 때문입니다. 이 캐스팅은 효과가 없어야 합니다. 그는 동일하다
b2의 경우 완전한 고유성이 있습니다. b1 - 아니요.
여기에 확신이 필요하지 않습니다. 오버로드된 메서드가 적용되는 간단한 순서가 있어야 합니다. 저것들. 과부하를 해결하는 작업은 딜레마를 만드는 것이 아니라 가장 적합한 방법을 선택하는 것입니다. 액세스 한정자가 삭제되면 테이블의 첫 번째 메서드가 사용되거나 컴파일러 구현에 따라 다르지만 여기에는 모호성이 없습니다.
이제 입력 매개변수가 다른 2개의 메소드가 있는 경우, 예를 들면 다음과 같습니다.
C++로 돌아가면 동일한 벡터에 다음이 포함됩니다.
따라서 완전히 정상입니다.
이것이 최종 사용자 제품에 어떻게 적합합니까? 이전에는 제한이 정당화되었을 수 있지만 전송된 다른 양의 데이터를 기반으로 하면 의심스럽습니다. 제한을 늘려도 비호환성 위협이 발생하지 않습니다.
최적화 캐시에서 MT5와 MT4 모두에서 문자열 매개변수가 항상 63자로 잘렸다는 사실부터 시작하겠습니다.
이벤트를 전달할 때 문자열도 63자를 초과할 수 없습니다.
즉, 외부에서 들어오는 것은 제한적입니다.
최종 사용자를 위한 제품의 경우. 판매자는 제한 사항을 고려해야 합니다. 그리고 그가 그것을 모른다면 판매하기 전에 제품을 충분히 테스트하지 않았습니다.