첫 번째 경우 Array[int]에 대한 호출이 = 연산의 왼쪽 매개변수로 사용되며 이중 변수가 아니고 두 번째 경우 오른쪽으로 호출되므로 이러한 오류가 발생하지 않아야 합니다. 왼쪽 매개변수는 double 유형의 변수입니다 .
당신은 듣지 않습니다, 그것은 아무것도 해서는 안 됩니다 - 유형에 의한 오버로딩은 금지되어 있으며 이것은 C ++ 표준에 명확하게 작성되어 있습니다.
Certain function declarations cannot be overloaded:
- Function declarations that differ only in the return type, the exception specification ( 18.4 ), or both
cannot be overloaded.
아무 것도 하지 않아야 합니다. 유형별 오버로딩은 금지되어 있으며 이는 C ++ 표준에 명시적으로 작성되어 있습니다.
가능한 원인은 위에서 언급했습니다. 따라서 operator[]가 유효하지 않습니다.
기준이 아니라 상식에 입각한 논리에 대해 답변을 드렸습니다. "가능성 있는" 원인에 대한 귀하의 정의는 내 주장을 무효화하지 않습니다. 컨텍스트에서 명시적으로 정의된 특정 유형에 대한 캐스팅 작업이 오버로드되기 때문에 입력 작업(암시적 포함)을 오버로드할 가능성은 인용한 표준과 모순되지 않습니다.
제가 제 자신을 너무 명확하게 표현하지 않았을 수도 있지만, 이 설명을 통해 더 명확해졌으면 합니다.
추신 물론 제 가상의 코드는 기준에 어긋납니다. 그러나 정말로 해독해야 하는 경우(주제 과정에서 질문을 더 정확하게 공식화하는 방법을 스스로 알아냈기 때문에) 코드는 다음과 같아야 합니다.
class Array{
public :
Array * operator [] ( int i){ id = i; returnGetPointer ( this ); }
doubleoperatordouble (){ return data[i]; }
Array * operator =( double d){ data[id]=d; returnGetPointer ( this ); }
private :
double data[ 10 ];
int id;
};
intOnStart (){
Array array;
double d= 123.456 ;
array[ 5 ]=d;
d=array[ 5 ];
}
pavlick_ : 그것이 모순되는 이유는 프로에서 꽤 유효합니다. 그리고 µl에는 독이 없습니다.
처음에는 반환 유형이 다른 두 개의 동일한 operator[] 함수가 있었기 때문입니다(두 번째 버전에서 이 문제를 수정했습니다). 이것은 표준에 의해 금지되어 있습니다. 그리고 (암시적으로 포함하여) 유형을 캐스팅하는 것이 금지된 것은 아니며, 아직 구현하지 못했을 뿐입니다. mql5의 급속한 발전을 감안할 때 조만간 구현될 것이라고 확신합니다. 특히 나 말고 다른 누군가가 포럼에서 이것을 주목한다면...
서로 다른 반환 유형을 가진 두 개의 동일한 operator[] 함수가 있기 때문입니다. 이것은 표준에 의해 금지되어 있습니다. 그리고 (암시적으로 포함하여) 유형을 캐스팅하는 것이 금지된 것은 아니며, 아직 구현하지 못했을 뿐입니다. mql5의 급속한 발전을 고려할 때 조만간 구현될 것이라고 확신합니다. 특히 나 말고 다른 누군가가 포럼에서 이것을 주목한다면...
정상이지만 mql5에서는 아직 작동하지 않습니다. 우리는 mql5의 혁신을 따르고 희망합니다. 사용자 정의 형식을 일반 배열과 같은 방식으로 작동할 수 없기 때문에 배열 개체를 적절하게 구현하는 것이 불가능하다는 것이 개인적으로 오랫동안 개인적으로 괴롭혀온 것입니다. 자신만의 배열을 만들고 처음부터 내장 배열과 같은 유용성을 가지지 못하는 결함이 있는 것으로 판명되었습니다.
정상이지만 mql5에서는 아직 작동하지 않습니다. 우리는 mql5의 혁신을 따르고 희망합니다. 사용자 정의 형식을 일반 배열과 같은 방식으로 작동할 수 없기 때문에 배열 개체를 적절하게 구현하는 것이 불가능하다는 것이 개인적으로 오랫동안 개인적으로 괴롭혀온 것입니다. 자신만의 배열을 만들고 처음부터 내장 배열과 같은 유용성을 가지지 못하는 결함이 있는 것으로 판명되었습니다.
글쎄요, 나는 큰 기적을 기대하지 않습니다. 언어가 더 이상 개발되지 않고 있습니다. 나는 그들이 캐스트 연산자를 추가할지 의심합니다. 정말로 나를 짜증나게 하는 것은 이것을 할 수 없다는 것입니다:
class Q {};
Q q;
// что то делаем и решаем переинициализировать q
q = Q(); // ошибка, нужно извратиться:
Q temp;
q = temp;
아마도 컴파일 단계에서 템플릿 불일치 오류가 생성되어야 합니다.
하지만 배열 객체가 있는 상황에서
첫 번째 경우 Array[int]에 대한 호출이 = 연산의 왼쪽 매개변수로 사용되며 이중 변수가 아니고 두 번째 경우 오른쪽으로 호출되므로 이러한 오류가 발생하지 않아야 합니다. 왼쪽 매개변수는 double 유형의 변수입니다 .
당신은 듣지 않습니다, 그것은 아무것도 해서는 안 됩니다 - 유형에 의한 오버로딩은 금지되어 있으며 이것은 C ++ 표준에 명확하게 작성되어 있습니다.
가능한 원인은 위에서 언급했습니다. 따라서 operator[]가 유효하지 않습니다.
아무 것도 하지 않아야 합니다. 유형별 오버로딩은 금지되어 있으며 이는 C ++ 표준에 명시적으로 작성되어 있습니다.
가능한 원인은 위에서 언급했습니다. 따라서 operator[]가 유효하지 않습니다.
기준이 아니라 상식에 입각한 논리에 대해 답변을 드렸습니다. "가능성 있는" 원인에 대한 귀하의 정의는 내 주장을 무효화하지 않습니다. 컨텍스트에서 명시적으로 정의된 특정 유형에 대한 캐스팅 작업이 오버로드되기 때문에 입력 작업(암시적 포함)을 오버로드할 가능성은 인용한 표준과 모순되지 않습니다.
제가 제 자신을 너무 명확하게 표현하지 않았을 수도 있지만, 이 설명을 통해 더 명확해졌으면 합니다.
추신 물론 제 가상의 코드는 기준에 어긋납니다. 그러나 정말로 해독해야 하는 경우(주제 과정에서 질문을 더 정확하게 공식화하는 방법을 스스로 알아냈기 때문에) 코드는 다음과 같아야 합니다.
연산자 type() 도입에 찬성한다면 훌륭합니다. 플러스에서 들여쓰기를 하는 경우 특정 문제를 해결하는 데 반대합니다(반환 유형으로 오버로드 허용). 메시지).
네. 결과적으로 이것은 타이핑 연산자의 도입을 위한 것입니다. 그것은 내가 지점의 초기 게시물에서 설정한 문제를 정확히 해결하기 때문에 보다 "전통적인" 방식으로만(표준에 적합하고 일반적으로 더 정확할 것입니다).
추신 물론 제 가상의 코드는 기준에 어긋납니다.
그것이 모순되는 이유는 프로에서 꽤 유효합니다. 그리고 µl에는 독이 없습니다.
처음에는 반환 유형이 다른 두 개의 동일한 operator[] 함수가 있었기 때문입니다(두 번째 버전에서 이 문제를 수정했습니다). 이것은 표준에 의해 금지되어 있습니다. 그리고 (암시적으로 포함하여) 유형을 캐스팅하는 것이 금지된 것은 아니며, 아직 구현하지 못했을 뿐입니다. mql5의 급속한 발전을 감안할 때 조만간 구현될 것이라고 확신합니다. 특히 나 말고 다른 누군가가 포럼에서 이것을 주목한다면...
서로 다른 반환 유형을 가진 두 개의 동일한 operator[] 함수가 있기 때문입니다. 이것은 표준에 의해 금지되어 있습니다. 그리고 (암시적으로 포함하여) 유형을 캐스팅하는 것이 금지된 것은 아니며, 아직 구현하지 못했을 뿐입니다. mql5의 급속한 발전을 고려할 때 조만간 구현될 것이라고 확신합니다. 특히 나 말고 다른 누군가가 포럼에서 이것을 주목한다면...
나는 마지막 코드에 대해 이야기하고 있습니다. 정상입니다.
나는 마지막 코드에 대해 이야기하고 있습니다. 정상입니다.
정상이지만 mql5에서는 아직 작동하지 않습니다. 우리는 mql5의 혁신을 따르고 희망합니다. 사용자 정의 형식을 일반 배열과 같은 방식으로 작동할 수 없기 때문에 배열 개체를 적절하게 구현하는 것이 불가능하다는 것이 개인적으로 오랫동안 개인적으로 괴롭혀온 것입니다. 자신만의 배열을 만들고 처음부터 내장 배열과 같은 유용성을 가지지 못하는 결함이 있는 것으로 판명되었습니다.
정상이지만 mql5에서는 아직 작동하지 않습니다. 우리는 mql5의 혁신을 따르고 희망합니다. 사용자 정의 형식을 일반 배열과 같은 방식으로 작동할 수 없기 때문에 배열 개체를 적절하게 구현하는 것이 불가능하다는 것이 개인적으로 오랫동안 개인적으로 괴롭혀온 것입니다. 자신만의 배열을 만들고 처음부터 내장 배열과 같은 유용성을 가지지 못하는 결함이 있는 것으로 판명되었습니다.
글쎄요, 나는 큰 기적을 기대하지 않습니다. 언어가 더 이상 개발되지 않고 있습니다. 나는 그들이 캐스트 연산자를 추가할지 의심합니다. 정말로 나를 짜증나게 하는 것은 이것을 할 수 없다는 것입니다:
하지만 말하는 것은 소용이 없다고 생각합니다.
글쎄요, 나는 큰 기적을 기대하지 않습니다. 언어가 더 이상 개발되지 않고 있습니다. 나는 그들이 캐스트 연산자를 추가할지 의심합니다. 정말로 나를 짜증나게 하는 것은 이것을 할 수 없다는 것입니다:
하지만 말을 해도 소용이 없는 것 같아요.
문제가 무엇인지 명확하지 않습니다. 개체의 초기화를 Init() 유형의 별도 메서드, 아마도 가상 메서드로 이동하는 것이 가능하지 않습니까?