MQL5에 대한 피드백
몇 가지 예가 주어질 것입니다.
포인터로 완벽하게 작업할 수 없고 객체로 쉽고 빠르게 작업할 수 없다는 것은 무엇을 의미합니까? 일반적으로 대규모 계획을 개발할 때 이에 대한 문제가 발생하지 않았습니다.
포인터로 작동하는 "전체"(즉, 위험)는 더 이상 현대적이고 관리되고 안전한 언어에서 가능하지 않습니다. 특히 보안과 제어 가능성이 우선되어야 하는 MQL4/MQL5에서는 더욱 그렇습니다.
다른 모든 것은 존재하고 사용 가능합니다. 그리고 안전한 포인터도 있습니다.
아마도 당신은 이해하지 못했지만 자신의 생각을 털어놓았을 것입니다. 이 검증되지 않은 스트림을 호출하는 다른 방법은 없습니다.
포인터로 작동하는 "전체"(즉, 위험)는 더 이상 현대적이고 관리되고 안전한 언어에서 가능하지 않습니다. 특히 보안과 제어 가능성이 우선되어야 하는 MQL4/MQL5에서는 더욱 그렇습니다.
다른 모든 것은 존재하고 사용 가능합니다. 그리고 안전한 포인터도 있습니다.
아마도 당신은 이해하지 못했지만 자신의 생각을 털어놓았을 것입니다. 이 검증되지 않은 스트림을 호출하는 다른 방법은 없습니다.
물론이죠:
https://www.mql5.com/ru/forum/35326
https://www.mql5.com/en/forum/1111/
포인터에 다른 주소를 할당할 수 없는 널리 사용되는 언어의 이름을 말하십시오. 또한 한 유형의 참조를 다른 개체에 대한 동일한 유형의 참조에 할당할 수 없는 관리 언어를 하나 이상 지정하시겠습니까? 언어의 이러한 제한으로 인해 생성자나 복사 기능을 설명 해야 하는 다른 곳은 어디입니까?
그리고 제어 가능성이 가장 중요하다면 다른 제어 언어가 유사한 제한을 부과하지 않는 이유는 무엇입니까?
저에게 개인적으로 무엇보다 중요한 것은 보안과 제어 가능성이 아니라 아이디어를 실현하는 속도입니다. 이는 아이디어 거래의 맥락에서 매우 사실입니다. 이에 동의하지 않는 사람들은 자신의 가치를 과대 평가하거나 특정 결과가 아닌 프로그래밍을 위한 시스템 또는 프로그램입니다.
Renat, 당신은 내가 첫 번째 게시물에서 쓴 모든 것을 알고 있고 보안으로 인한 유연성의 손실을 숨기고 이를 논쟁의 여지가 없는 이점의 순위로 끌어 올렸습니다. 그러나 이것은 전혀 사실이 아닙니다.
Битый указатель (именно указатель как сущность и рабочая единица языка) контролируется системой и безопасно обрабатывается, выдавая при необходимости рантайм ошибку, указывая на ошибку автора. А вот "физическая" ссылка не может быть проконтролирована, да ее и нет в языке (не путайте с передачей параметра по ссылке , где это лишь контролируемый системой метод связи).
위험한 참조를 비활성화하는 것은 현재 C++와 같은 괴물로부터 안전한 언어를 구축하기 위한 첫 번째 단계입니다. 우리는 의도적으로 그리고 의식적으로 링크를 제거했으며 석궁을 제거함으로써 의식적 으로 유연성을 잃었습니다 .
물론이죠:
https://www.mql5.com/ru/forum/35326
https://www.mql5.com/en/forum/1111/
포인터에 다른 주소를 할당할 수 없는 널리 사용되는 언어의 이름을 말하십시오. 또한 한 유형의 참조를 다른 개체에 대한 동일한 유형의 참조에 할당할 수 없는 관리 언어를 하나 이상 지정하시겠습니까? 언어의 이러한 제한으로 인해 생성자나 복사 기능을 설명 해야 하는 다른 곳은 어디입니까?
그리고 제어 가능성이 가장 중요하다면 다른 제어 언어가 유사한 제한을 부과하지 않는 이유는 무엇입니까?
저에게 개인적으로 무엇보다 중요한 것은 보안과 제어 가능성이 아니라 아이디어를 실현하는 속도입니다. 이는 아이디어 거래의 맥락에서 매우 사실입니다. 이에 동의하지 않는 사람들은 자신의 가치를 과대 평가하거나 특정 결과가 아닌 프로그래밍을 위한 시스템 또는 프로그램입니다.
토바리쉬! 언어에 대한 지식 부족을 개발자의 책임으로 전가하지 마십시오. MQL5에서는 다양한 개체를 포인터에 자유롭게 할당하고 이러한 개체를 포인터로 전달할 수 있습니다. MQL5의 C# 및 Java와 같은 다른 최신 언어와 마찬가지로 명시적 유형 제어가 있으며 해당 변환은 동일한 클래스 계층(상속) 내에서만 수행될 수 있습니다. 다시 말하지만, C# 및 Java와 같이 널리 사용되는 다른 언어 에서도 똑같은 동작이 구현됩니다.
Renat, 당신은 내가 첫 번째 게시물에서 쓴 모든 것을 알고 있고 보안으로 인한 유연성의 손실을 숨기고 이를 논쟁의 여지가 없는 이점의 순위로 끌어 올렸습니다. 그러나 이것은 전혀 사실이 아닙니다.
내 발에 총을 쏘게 해줘 이 기능이 없으면 프로그래밍을 제어해야 하지만 구현하고 싶은 아이디어를 제어하고 싶습니다.Renat, 당신은 내가 첫 번째 게시물에서 쓴 모든 것을 알고 있고 보안으로 인한 유연성의 손실을 숨기고 이를 논쟁의 여지가 없는 이점의 순위로 끌어 올렸습니다. 그러나 이것은 전혀 사실이 아닙니다.
내 발에 총을 쏘게 해줘 이 기능이 없으면 프로그래밍을 제어해야 하지만 구현하고 싶은 아이디어를 제어하고 싶습니다. 스스로 교육하고 안전에 대해 더 많이 생각해야 합니다.
나는 아무것도 인정하지 않지만 MQL4/MQL5에서 무엇을, 어떻게, 왜 수행했는지 참조(특정 위치에 대한 명확한 표시 없이도 던져짐)에서 정당화했습니다. 2001년(MQL이 출시되었을 때) 이후 거래 플랫폼용 응용 언어 개발의 실제 경험을 통해 글로벌 결과를 달성하는 데 필요한 것이 무엇인지 명확하게 이해할 수 있습니다.
무한한 속도를 원하십니까? C++로 작성하고 DLL을 포함합니다. 그러나 MQL5에서도 우리는 이미 네이티브 C++ 컴파일러를 따라 잡았습니다. x64 플랫폼용 새로운 MQL5 컴파일러 테스트 - 계산 속도를 2배에서 10배까지 향상시켰습니다!
포인터에 다른 주소를 할당할 수 없는 널리 사용되는 언어의 이름을 말하십시오. 또한 한 유형의 참조를 다른 개체에 대한 동일한 유형의 참조에 할당할 수 없는 관리 언어를 하나 이상 지정하시겠습니까? 언어의 이러한 제한으로 인해 생성자나 복사 기능을 설명 해야 하는 다른 곳은 어디입니까?
표준 라이브러리 https://www.mql5.com/en/docs/standardlibrary 를 살펴보고 Might 및 main 링크와 함께 작동하는 코드(MQL5\Include\*에 있음)를 살펴보십시오.
분명히, 당신은 언어를 전혀 모릅니다.
- www.mql5.com
Renat , 이 스레드를 살펴보십시오.
- www.mql5.com
저는 MQL4를 오랫동안 사용해 왔으며 OOP가 마침내 MQL5에 등장한다는 소식을 듣고 매우 기뻤습니다. 더 유연한 자동 분석 시스템을 더 빨리 작성할 수 있기 때문입니다. 그러나 나는 내가 얼마나 실망했는지에 대한 단어를 찾을 수 없습니다. 포인터로 완벽하게 작업할 수 없고 객체 를 쉽고 빠르게 작업할 수 없다는 사실에 소름이 끼쳤습니다. 특히 95%의 경우에서 쓸모없는 시스템을 개발할 때 그렇습니다. 우리는 모두 MQL로 프로그램을 작성하여 몇 가지 이론을 테스트하고, 이후에 아이디어의 실패를 확인하고 최적화하기 위해 자동 데이터 분석을 수행합니다. 타임스. 우리가 언어를 무시하더라도 이러한 맥락에서 거래 시스템이나 분석 시스템의 개발은 감사할 일이기 때문입니다. 당신은 그것이 차선책이거나 쓸모가 없을 것이라는 것을 알고 작업을 시작합니다. MQL5의 개발자들이 우리 자신에게 총을 쏘는 것은 불가능하지만 간단한 아이디어, 즉 기초적인 것을 구현하는 데 수십 시간이 걸리는 매우 안전한 도구를 우리에게 주었다면 우리는 무엇을 말할 수 있습니까? 연산.
따라서 MQL5 개발자는 Stroustrup의 책을 읽는 동안 흥미로운 단락 하나를 읽고 즉시 MQL5 "제품"을 기억했습니다. 전체 내용을 인용하겠습니다.
"우리가 생각하는(프로그램 작성) 언어와 상상할 수 있는 문제(해결책) 사이의 연결은 매우 가깝습니다. 따라서 프로그래밍 오류를 방지하기 위해 언어의 기능을 제한하는 것은 기껏해야 위험합니다. 자연어의 경우 최소 2개 언어에 대한 지식은 큰 이점이 있습니다. 언어는 프로그래머에게 일련의 개념적 도구를 제공합니다. 이러한 도구가 당면한 작업에 부적절하면 단순히 무시됩니다. 좋은 디자인과 단순히 언어의 특정 기능이 있는지 없는지만으로는 오류가 없다고 보장할 수 없습니다."
따라서 위의 리뷰에 따르면 프로그래밍을 위해 프로그래밍한 것은 MQL이 수행하도록 설계된 목적에 완전히 사용할 수 없습니다. MQL5에서 OOP와 같은 도구를 단순히 무시해야 한다는 사실에 감사합니다.