Alexey, mql이 C와 유사하다면 절대적으로 동일해야 하고 왼쪽으로 한 단계, 오른쪽으로 한 단계 - 실행해야 하는 이유를 손가락으로 설명해 주십시오.
개발자들이 부주의하게 그렇게 해서? 그러나 모든 언어는 주기와 조건을 기반으로 합니다. 다른 모든 것은 트레일러에 있습니다. 어떤 이유에서인지 아무도 다른 언어가 OOP 또는 C와 비슷한 면에서 유사할 것을 요구하지 않습니다.
그것은 완전한 정체성에 관한 것이 아닙니다. 요점은 구현된 기능이 정확하고 일관되게 작동해야 한다는 것입니다. 그러나 먼저 다른 언어가 작동하는 다른 언어를 보여주라고 소리칩니다. 그들에게도 청구하십시오. 그리고 그들이 다르게(올바르게) 작동하는 C++의 예를 제공한 후 MQL이 C++가 아니며 동일해서는 안 된다고 말하면서 이전 백파이프를 시작합니다. 당신은 이미 결정
>> 예, 물론 그것들로 dynamic_cast를 할 수는 없지만 그렇게 자주 필요한 것은 아닙니다. 주요 임무는 기능으로의 이전입니다.
예, 왜 하지 않습니까, 문제를 알고 있습니다) 그러나 주요 악몽이 나타납니다. 컴파일 단계에서 캐스팅 오류를 감지하지 못합니다. :)
예, 일반적인 경우에는 여전히 의미가 없습니다. 결국 상속 체인은 무엇이든 될 수 있습니다. 최소한 Interface<CBase>, 최소한 Interface<C<B<A<CBase>>>>, 셀 수 없이 많은 옵션이 있습니다. CBase를 가능한 모든 옵션으로 순차적으로 캐스팅해야 하는데 이는 비현실적입니다.
클래스 개체 자체에 인터페이스에 대한 정보 저장을 구현하려고 했던 것을 기억합니다. 그리고 기존 인터페이스 패드에 추가하여 우리 패드에서 래퍼로 작동할 독립적인 인터페이스 클래스를 만듭니다. 예, 그제서야 이것이 모두 불필요하고 불필요하다는 결론에 도달했습니다. 기본 클래스를 인터페이스로 캐스팅할 실질적인 필요성을 보지 못했습니다. 그것은 단지 일종의 비논리적입니다. 유일한 옵션은 클래스가 디버깅 목적으로 주어진 인터페이스를 지원하는지 확인하는 것입니다. 그러나 이렇게 하려면 캐스팅이 필요하지 않습니다.
나는 "스택 오버플로"에 반응했습니다)
바퀴벌레인듯...따라서 이것은 컴파일러가 아니지만 이미 런타임에 있습니다. 그리고 컴파일러는 응답해야 합니다.
VS 2010에서 이것을 시도했습니다.
컴파일 오류가 발생합니다. 오류 1 오류 LNK2001: 해결되지 않은 외부 기호 "public: virtual int __thiscall A::f2(void)"
그리고 Metaeditor는 침묵합니다. 안좋다.
이것이 컴파일러가 응답하는 방식입니다.
VS 2010에서 이것을 시도했습니다.
컴파일 오류가 발생합니다. 오류 1 오류 LNK2001: 해결되지 않은 외부 기호 "public: virtual int __thiscall A::f2(void)"
메타에디터는 침묵합니다. 안좋다.
Alexey, mql이 C와 유사하다면 절대적으로 동일해야 하고 왼쪽으로 한 단계, 오른쪽으로 한 단계 - 실행해야 하는 이유를 손가락으로 설명해 주십시오.
개발자들이 부주의하게 그렇게 해서? 그러나 모든 언어는 주기와 조건을 기반으로 합니다. 다른 모든 것은 트레일러에 있습니다. 어떤 이유에서인지 아무도 다른 언어가 OOP 또는 C와 비슷한 면에서 유사할 것을 요구하지 않습니다.
Alexey, mql이 C와 유사하다면 절대적으로 동일해야 하고 왼쪽으로 한 단계, 오른쪽으로 한 단계 - 실행해야 하는 이유를 손가락으로 설명해 주십시오.
개발자들이 부주의하게 그렇게 해서? 그러나 모든 언어는 주기와 조건을 기반으로 합니다. 다른 모든 것은 트레일러에 있습니다. 어떤 이유에서인지 아무도 다른 언어가 OOP 또는 C와 비슷한 면에서 유사할 것을 요구하지 않습니다.
또는 이 모든 것이 코드 작성을 더 쉽게 만들거나 단축하거나 최소한 오류로부터 보호할 수 있는 예를 보여줄 수 있습니까? 그리고 조언자나 지표에서 추상적 기능이 아니라 거래 현실에 최대한 가깝게 하십시오.
안 돼요. 남자들은 그들의 환상을 현실로 끌어내려는 것뿐입니다.
안 돼요. 남자들은 그들의 환상을 현실로 끌어내려는 것뿐입니다.
사실이야 그러나 저는 오랫동안 대안 옵션을 사용해 왔습니다. 저는 처음에 모든 인터페이스를 중간 템플릿 클래스로 설계했습니다.
따라서 이러한 인터페이스에서 상속 체인을 생성할 수 있습니다. 네, 물론 그것들로 dynamic_cast를 할 수는 없지만 그렇게 자주 필요한 것은 아닙니다. 주요 임무는 기능으로의 이전입니다.자세히 읽어보니 흥미로운 움직임이 보이네요. 나는 이것을 전에 생각하지 않았다 =) 나도 내 여가 시간에 실험 할 것입니다 ...
저에게는 환상을 현실로 끌어들이는 매우 유용한 직업입니다. 이것이 개발의 의미입니다!
그리고 가장 중요한 것은 - 유익합니다! 개발자들은 마침내 우리의 말을 듣고 모두가 수년 동안 비틀거렸던 이 버그를 수정하기로 결정했습니다.
그러나 포럼의 일부 회원의 파괴적인 입장은 물론 놀라운 일입니다. 그리고 그들 자신은 발전하지 않으며 놀라운 인내로 다른 사람들을 방해하려고합니다.
>> 예, 물론 그것들로 dynamic_cast를 할 수는 없지만 그렇게 자주 필요한 것은 아닙니다. 주요 임무는 기능으로의 이전입니다.
예, 왜 하지 않습니까, 문제를 알고 있습니다) 그러나 주요 악몽이 나타납니다. 컴파일 단계에서 캐스팅 오류를 감지하지 못합니다. :)
>> 예, 물론 그것들로 dynamic_cast를 할 수는 없지만 그렇게 자주 필요한 것은 아닙니다. 주요 임무는 기능으로의 이전입니다.
예, 왜 하지 않습니까, 문제를 알고 있습니다) 그러나 주요 악몽이 나타납니다. 컴파일 단계에서 캐스팅 오류를 감지하지 못합니다. :)
예, 일반적인 경우에는 여전히 의미가 없습니다. 결국 상속 체인은 무엇이든 될 수 있습니다. 최소한 Interface<CBase>, 최소한 Interface<C<B<A<CBase>>>>, 셀 수 없이 많은 옵션이 있습니다. CBase를 가능한 모든 옵션으로 순차적으로 캐스팅해야 하는데 이는 비현실적입니다.
클래스 개체 자체에 인터페이스에 대한 정보 저장을 구현하려고 했던 것을 기억합니다. 그리고 기존 인터페이스 패드에 추가하여 우리 패드에서 래퍼로 작동할 독립적인 인터페이스 클래스를 만듭니다. 예, 그제서야 이것이 모두 불필요하고 불필요하다는 결론에 도달했습니다. 기본 클래스를 인터페이스로 캐스팅할 실질적인 필요성을 보지 못했습니다. 그것은 단지 일종의 비논리적입니다. 유일한 옵션은 클래스가 디버깅 목적으로 주어진 인터페이스를 지원하는지 확인하는 것입니다. 그러나 이렇게 하려면 캐스팅이 필요하지 않습니다.