MQL4에서 목록, 트리, 그래프를 구현해 보십시오. 그것은 불가능. MQL5에서는 이 작업이 쉽게 수행되며 바퀴를 재발명할 필요도 없지만 C++ 코드를 찾아 최소한의 수정으로 사용합니다. 그리고 클래스 형태로 더 잘 발행하기 위한 예시로 나온 자연스러운 타입입니다. 신경망 , 퍼지 논리 등을 이제 MQL5에서 편안하게 구현할 수 있습니다. 그러나 물론 각 도구는 당면한 작업에 적합해야 하며 OOP는 필요할 때만 사용해야 합니다. 새로운 기능을 욕하는 자들의 외침은 우스꽝스럽습니다. 마음에 들지 않으면 사용하지 마십시오. 아무도 사용하지 않습니다. 함수형 프로그래밍을 사용합니다.
FoxRex : MQL4에서 목록, 트리, 그래프를 구현해 보십시오. 그것은 불가능. MQL5에서는 이 작업이 쉽게 수행되며 바퀴를 재발명할 필요도 없지만 C++ 코드를 찾아 최소한의 수정으로 사용합니다. 그리고 클래스 형태로 더 잘 발행하기 위한 예시로 나온 자연스러운 타입입니다. 신경망, 퍼지 논리 등을 이제 MQL5에서 편안하게 구현할 수 있습니다. 그러나 물론 각 도구는 당면한 작업에 적합해야 하며 OOP는 필요할 때만 사용해야 합니다. 새로운 기능을 욕하는 자들의 외침은 우스꽝스럽습니다. 마음에 들지 않으면 사용하지 마십시오. 아무도 사용하지 않습니다. 함수형 프로그래밍을 사용합니다.
"불가능"과 "어려움"을 혼동하지 마십시오. 절차 적 프로그래밍을 사용하여 해결할 수없는 문제가 없으며 OOP에서 해결할 수 있습니다. 프로그램의 최종 기능을 의미합니다. 그리고 일반적으로 어셈블러로 작성할 수 있습니다. 그렇지 않으면 긴장을 풀고 준비하십시오. :)
OOP는 데이터 및 기능 분리가 추가된 동일한 절차적 프로그래밍을 기반으로 합니다. 예를 들어 OOP에서 "Hello world!" 프로그램을 작성하는 데 시간이 더 오래 걸리지만 대규모 프로젝트 를 더 빠르게 작성할 수 있습니다. 환경 설정. 개인적으로 OOP가 대부분의 경우에 더 편리합니다. 왜냐하면 나는 "좁은" 곳과 "넓은" 곳을 알고 있으며 OOP 프로그래밍(C++, JavaScript, PHP)에 대한 경험이 있습니다. 그러나 짧은 테스트 스크립트를 작성하면 OOP를 사용하지 않습니다.
팁: 실제 작업에서 OOP로 전환하기 전에 두 개의 숫자를 더하는 클래스 작성 등과 같은 간단한 예제를 연습해야 합니다. Vryatli는 OOP에 대한 책을 읽은 후 연습 없이 심각한 프로그램 프로그래밍을 시작하는 것으로 나타났습니다. 그것에 익숙해져야 하고, OOP의 맥락에서 생각하기 시작하고, 클래스로 디자인해야 하는 것과 가치가 없는 것을 확인해야 합니다.
이것은 결과가 아니라 구현이라는 점에 유의하십시오. 우리는 결과(프로그램)를 위해 프로그래밍하고 있습니까, 아니면 프로그램을 구현하기 위해 프로그래밍하고 있습니까? 이 모든 방법 없이도 할 수 있고 배열로 구성하고 값으로 전달할 수 있습니다. 어렵고 힘들지만 가능합니다.
이것은 결과가 아니라 구현이라는 점에 유의하십시오. 우리는 결과(프로그램)를 위해 프로그래밍하고 있습니까, 아니면 프로그램을 구현하기 위해 프로그래밍하고 있습니까? 이 모든 방법 없이도 할 수 있고 배열로 구성하고 값으로 전달할 수 있습니다. 어렵고 힘들지만 가능합니다.
Windows 와 OOP 의 시대에 "태어난" 사람들은 DOS 와 C/Turbo Pascal 이 무엇인지 이해하지 못합니다(저는 이미 Asm에 대해 침묵합니다) ...
이것은 결과가 아니라 구현이라는 점에 유의하십시오. 우리는 결과(프로그램)를 위해 프로그래밍하고 있습니까, 아니면 프로그램을 구현하기 위해 프로그래밍하고 있습니까? 이 모든 방법 없이도 할 수 있고 배열로 구성하고 값으로 전달할 수 있습니다. 어렵고 힘들지만 가능합니다.
어레이가 동적이라면 트레일러에서 수행할 수 있다는 점에 동의합니다. 그러나 이것이 매우 우아한 해결책이 아니라는 것을 인정해야 합니다. 어셈블러에서는 이 작업이 더 쉽습니다. 그리고 OPP는 Windows보다 먼저 태어났습니다. 그리고 그의 아이디어는 내가 PC/XT용 어셈블러로 프로그래밍하는 데 도움이 되었습니다. 그리고 제 첫 프로그래밍 교과서는 Knuth의 세 권으로 된 책입니다.
FoxRex : 어레이가 동적이라면 트레일러에서 수행할 수 있다는 점에 동의합니다. 그러나 이것이 매우 우아한 해결책이 아니라는 것을 인정해야 합니다. 어셈블러에서는 이 작업이 더 쉽습니다. 그리고 OPP는 Windows보다 먼저 태어났습니다. 그리고 그의 아이디어는 내가 PC/XT용 어셈블러로 프로그래밍하는 데 도움이 되었습니다. 그리고 프로그래밍에 대한 나의 첫 번째 교과서는 Knuth의 세 권으로 된 책입니다.
OOP는 큰 프로그램에 적합합니다. 코드가 50줄 미만이면 OOP가 필요하지 않습니다. 그러나 코드가 많으면 주석만으로는 무엇과 관련이 있는지 이해하는 것이 거의 불가능합니다. 계획에 없던 변수 공유, 공포, 혼란으로 오류 확률이 높아집니다. OOP에서는 변수가 메소드(함수)와 함께 컨테이너(클래스) 내부에 저장되어 있는지 확인할 수 있습니다.
OOP로 작성할 수 있고 OOP 없이 작성할 수 없는 태스크는 없습니다. 편의성 때문입니다.)
일반적으로 저는 MQL4를 몇 년 동안 알고 있었고 그 비참함에 계속 놀라움을 금치 못했습니다. 네 번째 MQL은 클래식 C의 기능에 이르기까지 별과는 거리가 멀다. MQL5에서 개발자들은 계속 진행하기로 결정했습니다. 정말 더 많은 기회가 있고 프로그래밍이 정말 쉬워졌습니다. 언어는 더 복잡해졌지만, 그 제품은 학교에서 공부하도록 만들어지지 않았습니다.
내가 실수를 했다 - "OOP로 작성할 수 있고 OOP 없이 작성할 수 없는 작업은 없습니다."
MQL4에서 목록, 트리, 그래프를 구현해 보십시오. 그것은 불가능. MQL5에서는 이 작업이 쉽게 수행되며 바퀴를 재발명할 필요도 없지만 C++ 코드를 찾아 최소한의 수정으로 사용합니다. 그리고 클래스 형태로 더 잘 발행하기 위한 예시로 나온 자연스러운 타입입니다. 신경망, 퍼지 논리 등을 이제 MQL5에서 편안하게 구현할 수 있습니다. 그러나 물론 각 도구는 당면한 작업에 적합해야 하며 OOP는 필요할 때만 사용해야 합니다. 새로운 기능을 욕하는 자들의 외침은 우스꽝스럽습니다. 마음에 들지 않으면 사용하지 마십시오. 아무도 사용하지 않습니다. 함수형 프로그래밍을 사용합니다.
"불가능"과 "어려움"을 혼동하지 마십시오. 절차 적 프로그래밍을 사용하여 해결할 수없는 문제가 없으며 OOP에서 해결할 수 있습니다. 프로그램의 최종 기능을 의미합니다.
그리고 일반적으로 어셈블러로 작성할 수 있습니다. 그렇지 않으면 긴장을 풀고 준비하십시오. :)
OOP는 데이터 및 기능 분리가 추가된 동일한 절차적 프로그래밍을 기반으로 합니다.
예를 들어 OOP에서 "Hello world!" 프로그램을 작성하는 데 시간이 더 오래 걸리지만 대규모 프로젝트 를 더 빠르게 작성할 수 있습니다. 환경 설정.
개인적으로 OOP가 대부분의 경우에 더 편리합니다. 왜냐하면 나는 "좁은" 곳과 "넓은" 곳을 알고 있으며 OOP 프로그래밍(C++, JavaScript, PHP)에 대한 경험이 있습니다.
그러나 짧은 테스트 스크립트를 작성하면 OOP를 사용하지 않습니다.
팁: 실제 작업에서 OOP로 전환하기 전에 두 개의 숫자를 더하는 클래스 작성 등과 같은 간단한 예제를 연습해야 합니다.
Vryatli는 OOP에 대한 책을 읽은 후 연습 없이 심각한 프로그램 프로그래밍을 시작하는 것으로 나타났습니다.
그것에 익숙해져야 하고, OOP의 맥락에서 생각하기 시작하고, 클래스로 디자인해야 하는 것과 가치가 없는 것을 확인해야 합니다.
목록, 트리, 그래프, 포인터가 없는 MQL4에서는 불가능합니다.
이것은 결과가 아니라 구현이라는 점에 유의하십시오.
우리는 결과(프로그램)를 위해 프로그래밍하고 있습니까, 아니면 프로그램을 구현하기 위해 프로그래밍하고 있습니까?
이 모든 방법 없이도 할 수 있고 배열로 구성하고 값으로 전달할 수 있습니다.
어렵고 힘들지만 가능합니다.
이것은 결과가 아니라 구현이라는 점에 유의하십시오.
우리는 결과(프로그램)를 위해 프로그래밍하고 있습니까, 아니면 프로그램을 구현하기 위해 프로그래밍하고 있습니까?
이 모든 방법 없이도 할 수 있고 배열로 구성하고 값으로 전달할 수 있습니다.
어렵고 힘들지만 가능합니다.
Windows 와 OOP 의 시대에 "태어난" 사람들은 DOS 와 C/Turbo Pascal 이 무엇인지 이해하지 못합니다(저는 이미 Asm에 대해 침묵합니다) ...
물론 IMHO이지만....
Windows 와 OOP 의 시대에 "태어난" 사람들은 DOS 와 C/Turbo Pascal 이 무엇인지 이해하지 못합니다(저는 이미 Asm에 대해 침묵합니다) ...
물론 IMHO이지만....
프로그래머가 한 번에 여러 가지 방법으로 문제를 해결할 수 있기 때문에 변경하려면 모든 것을 시도해야 합니다. :)
그래서 asm에서 프로그램을 디버깅하면 우울증에 빠지게 됩니다. :)
이것은 결과가 아니라 구현이라는 점에 유의하십시오.
우리는 결과(프로그램)를 위해 프로그래밍하고 있습니까, 아니면 프로그램을 구현하기 위해 프로그래밍하고 있습니까?
이 모든 방법 없이도 할 수 있고 배열로 구성하고 값으로 전달할 수 있습니다.
어렵고 힘들지만 가능합니다.
어레이가 동적이라면 트레일러에서 수행할 수 있다는 점에 동의합니다. 그러나 이것이 매우 우아한 해결책이 아니라는 것을 인정해야 합니다. 어셈블러에서는 이 작업이 더 쉽습니다. 그리고 OPP는 Windows보다 먼저 태어났습니다. 그리고 그의 아이디어는 내가 PC/XT용 어셈블러로 프로그래밍하는 데 도움이 되었습니다. 그리고 프로그래밍에 대한 나의 첫 번째 교과서는 Knuth의 세 권으로 된 책입니다.
그래서 우리는 "OOP가 편리하다"는 생각에 이르렀습니다. :)
그리고 한 가지 더: "OOP 사용이 불편하시다면 사용하지 마세요" :)
두 가지 간단한 개념 ...
OOP는 큰 프로그램에 적합합니다.
코드가 50줄 미만이면 OOP가 필요하지 않습니다.
그러나 코드가 많으면 주석만으로는 무엇과 관련이 있는지 이해하는 것이 거의 불가능합니다.
계획에 없던 변수 공유, 공포, 혼란으로 오류 확률이 높아집니다.
OOP에서는 변수가 메소드(함수)와 함께 컨테이너(클래스) 내부에 저장되어 있는지 확인할 수 있습니다.
OOP로 작성할 수 있고 OOP 없이 작성할 수 없는 태스크는 없습니다.
편의성 때문입니다.)
OOP는 문제를 해결하는 방법이 아니라 코드를 구조화하는 방법입니다.
프로그램이 "Hello word"보다 커지면 OOP를 사용해야 합니다.
일반적으로 저는 MQL4를 몇 년 동안 알고 있었고 그 비참함에 계속 놀라움을 금치 못했습니다. 네 번째 MQL은 클래식 C의 기능에 이르기까지 별과는 거리가 멀다. MQL5에서 개발자들은 계속 진행하기로 결정했습니다. 정말 더 많은 기회가 있고 프로그래밍이 정말 쉬워졌습니다. 언어는 더 복잡해졌지만, 그 제품은 학교에서 공부하도록 만들어지지 않았습니다.