Doerk Hilger : 프로그래밍 GUI는 프로그래머로서 내가 가장 많이 한 일이었습니다. if then else에 의해 여러 방향으로 통신해야 하는 완전한 GUI를 코딩하는 것은 불가능합니다. 코드를 읽을 수 없게 되고 결국에는 너무 느려서 목표에 도달하지 못하게 될 만큼 많은 문이 필요합니다. 사실.
나는 당신이 틀렸다는 것을 증명하기 위해 절차적 언어로 GUI를 구축하지 않을 것입니다. 하지만 나는 의심의 여지 없이 할 수 있었다.
그건 그렇고 OOP에서 읽을 수 없고 훨씬 느린 코드를 쉽게 코딩할 수 있습니다. 아시다시피 Metaquotes 표준 라이브러리 는 이에 대한 좋은 증거입니다.
CPU가 OOP에 대해 아무것도 모르는 상황 때문에 포인터와 복잡한 배열을 사용하지 않고도 모든 것을 코딩할 수 있습니다. 그러나 그것은 터무니없다. 또한 10,000명을 고용하여 필름에 내 스크린 콘텐츠를 실시간으로 그리고 벽에 라이트 프로젝터로 순차적으로 비출 수 있습니다. 이것도 목표달성인가요?
Windows 운영 체제가 좋은 GUI를 제공한다는 데 동의하십니까? 내가 아는 한 OOP가 아닌 C. 절차 언어로 작성되었습니다.
복잡한 프로그램이 OOP로만 구축될 수 있다고 생각한다면 당신은 잘못된 Dirk입니다. OOP로 코딩하는 것이 더 나은 이유를 설명해야 합니다.
Doerk Hilger : 어 어서 ;) 별로 ;) 네이티브가 뭔가 이상하게 일을 할 수 있다면, 그 포인터가 있지만 MQL에는 제한이 있습니다. 그렇다면 ... 코드는 터무니없게 될 것입니다.
함수 포인터는 이미 MQL5에 도입되었으며 MQL4도 이 기능을 지원할 것입니다. 절차 코드는 OOP가 주류가 되기 전에 수년 동안 유일한 코딩 방법이었기 때문에 터무니없지 않을 것입니다. 절차 코드는 일반적으로 유사한 OOP에 비해 더 복잡하고 이해하기 어려워 보입니다. 그게 전부입니다.
Windows 운영 체제가 좋은 GUI를 제공한다는 데 동의하십니까? 내가 아는 한 OOP가 아닌 C. 절차 언어로 작성되었습니다.
복잡한 프로그램이 OOP로만 구축될 수 있다고 생각한다면 당신은 잘못된 Dirk입니다. OOP로 코딩하는 것이 더 나은 이유를 설명해야 합니다.
전적으로 어셈블러에서 GUI를 코딩했습니다. 그러나 어셈블러에서는 포인터로 작업할 수 있고 C에서는 포인터로 작업할 수 있으며 물론 Windows의 기본은 OOP가 아니지만 기본 방식으로 void 포인터를 지원하지 않는 MQL에 대해 이야기합니다. if then else로 복잡한 GUI를 코딩할 수 있습니다. 최소한 성능 저하 없이 사용할 수 있는 결과는 아닙니다.
그리고 이 답변에는 이미 질문이 포함되어 있습니다. 왜 OOP가 더 나은지, "더 나은"은 여전히 잘못된 형용사입니다. OOP 메서드는 이러한 포인터의 사용을 구현하지만 이를 처리하도록 강요하지 않습니다. 내부적으로 OOP는 함수 및 변수 포인터에 대한 다차원 배열로 실현됩니다. 그런 것들을 코딩하려고 하는 것은 당신이 이미 가지고 있는 것만큼 부드럽게 굴러가지 않을 바퀴를 재발명하는 것과 아주 같습니다.
전적으로 어셈블러에서 GUI를 코딩했습니다. 그러나 어셈블러에서는 포인터로 작업할 수 있고 C에서는 포인터로 작업할 수 있으며 물론 Windows의 기본은 OOP가 아니지만 기본 방식으로 void 포인터를 지원하지 않는 MQL에 대해 이야기합니다. if then else로 복잡한 GUI를 코딩할 수 있습니다. 최소한 성능 저하 없이 사용할 수 있는 결과는 아닙니다.
그리고 이 답변에는 이미 질문이 포함되어 있습니다. 왜 OOP가 더 나은지, "더 나은"은 여전히 잘못된 형용사입니다. OOP 메서드는 이러한 포인터의 사용을 구현하지만 이를 처리하도록 강요하지 않습니다. 내부적으로 OOP는 함수 및 변수 포인터에 대한 다차원 배열로 실현됩니다. 그런 것들을 코딩하려고 하는 것은 당신이 이미 가지고 있는 것만큼 부드럽게 굴러가지 않을 바퀴를 재발명하는 것과 아주 같습니다.
저는 GUI 전문가가 아니므로 더 이상 논쟁하지 않겠습니다. 나는 당신의 요점을 얻었습니다. OOP는 그렇지 않으면 덜 효율적이거나 너무 많은 작업을 의미하는 복잡한 소프트웨어를 만들 수 있습니다.
1) 예를 들어 Java가 마음에 들지 않습니다. 존재 여부와 관계없이 이름이 무엇인지 모르고 어쨌든 직접 코딩해야하는지 여부를 모르는 함수 에 대해 시간의 99 %를 검색했기 때문입니다 ...
2) mq4나 Perl과 같은 언어와 같은 스크립트를 작성하는 데 필요한 것보다 더 많이 작성해야 하기 때문에 C++를 좋아하지 않습니다.
3) 다른 사람의 코드를 이해하면 파일에서 파일로 건너뛸 수 있기 때문에 C++가 마음에 들지 않습니다. 왜냐하면 2,3줄의 함수만 찾을 수 있기 때문에 무엇을, 어떻게 s.th를 찾는 것이 정말 어렵습니다. 계산됩니다. 물론 "계산 중지"와 같은 설명이 있지만 calc.-procedure도 다른 파일의 여러 기능으로 분할됩니다.
4) 열거형 및 열거형 변수 배열에 대해 전혀 문제가 없습니다. 상상한 실제 물체를 코딩할 필요가 없습니다. GUI는 그것을 재사용하는 쉬운 방법을 위해 객체로 코딩될 수 있는 다른 많은 것들로 구성되어 있기 때문에 다른 문제일 수 있습니다. 그러나 EA에는 얼마나 많은 다른 개체가 필요합니까? 포지션을 위한 하나? 다양한 '객체'(GUI)가 있으면 도움이 될 수 있지만 여기에서는 볼 수 없습니다.
coringajoker : 나는 코드 어셈블을 하는 사람을 정말 존경합니다. 당신은 하드웨어 자체가 어떻게 작동하는지에 대한 좋은 지식이 있어야 합니다.
나는 더 이상 그것을 코딩하지 않지만 과거에는 주로 주로. Intel 80x86 칩에서는 시각적 성능 측면에서 진정한 우위를 점할 수 있는 유일한 기회였습니다. 물론 더 이상 자세히 필요하지 않더라도 절대 놓치고 싶지 않은 기본 지식이지만 결국에는 코드에서 어떤 일이 발생하는지 항상 알고 있으며 이를 이점으로 사용하는 방법을 알고 있습니다. 실행 속도 보기.
예 "좋았던" 옛날 ;) ... 하지만 역시 변수도 없었고, 실제 기능 도 없었고, if then else도 없었고 레지스터, 스택, 인터럽트 및 메모리 주소만 있었습니다. 미친놈아 :)
OOP는 재사용 가능한 작은 부분으로 코드를 분할하는 도구입니다. 그러나 가장 좋은 부분은 템플릿입니다. 이 기능을 사용하면 코드를 단순화할 수 있습니다. 가장 좋은 예는 배열 클래스입니다. Java에서는 유형에 대한 클래스를 작성했습니다 . C++ 및 Mql5에서는 프리미티브와 객체를 혼합할 때 중복 코드를 줄이고 일부 문제를 우회할 수 있습니다.
추신: ASM에 관해서는 오래된 학교입니다. 나는 처음으로 보호 모드 컴파일러를 사용하기 전에 그것을 사용했고 재미있는 오버패스 제한이었습니다. 선택기가 있는 64K 세그먼트는 그 당시 코더의 악몽이었습니다. 잘못된 위치에 글을 쓸 때마다 컴퓨터를 재부팅했습니다. :)
프로그래밍 GUI는 프로그래머로서 내가 가장 많이 한 일이었습니다. if then else에 의해 여러 방향으로 통신해야 하는 완전한 GUI를 코딩하는 것은 불가능합니다. 코드를 읽을 수 없게 되고 결국에는 너무 느려서 목표에 도달하지 못하게 될 만큼 많은 문이 필요합니다. 사실.
나는 당신이 틀렸다는 것을 증명하기 위해 절차적 언어로 GUI를 구축하지 않을 것입니다. 하지만 나는 의심의 여지 없이 할 수 있었다.
그건 그렇고 OOP에서 읽을 수 없고 훨씬 느린 코드를 쉽게 코딩할 수 있습니다. 아시다시피 Metaquotes 표준 라이브러리 는 이에 대한 좋은 증거입니다.
...
CPU가 OOP에 대해 아무것도 모르는 상황 때문에 포인터와 복잡한 배열을 사용하지 않고도 모든 것을 코딩할 수 있습니다. 그러나 그것은 터무니없다. 또한 10,000명을 고용하여 필름에 내 스크린 콘텐츠를 실시간으로 그리고 벽에 라이트 프로젝터로 순차적으로 비출 수 있습니다. 이것도 목표달성인가요?
Windows 운영 체제가 좋은 GUI를 제공한다는 데 동의하십니까? 내가 아는 한 OOP가 아닌 C. 절차 언어로 작성되었습니다.
복잡한 프로그램이 OOP로만 구축될 수 있다고 생각한다면 당신은 잘못된 Dirk입니다. OOP로 코딩하는 것이 더 나은 이유를 설명해야 합니다.
어 어서 ;) 별로 ;) 네이티브가 뭔가 이상하게 일을 할 수 있다면, 그 포인터가 있지만 MQL에는 제한이 있습니다. 그렇다면 ... 코드는 터무니없게 될 것입니다.
나는 OOP가 더 짧은 코딩 방식인지 의심스럽다.
Windows 운영 체제가 좋은 GUI를 제공한다는 데 동의하십니까? 내가 아는 한 OOP가 아닌 C. 절차 언어로 작성되었습니다.
복잡한 프로그램이 OOP로만 구축될 수 있다고 생각한다면 당신은 잘못된 Dirk입니다. OOP로 코딩하는 것이 더 나은 이유를 설명해야 합니다.
전적으로 어셈블러에서 GUI를 코딩했습니다. 그러나 어셈블러에서는 포인터로 작업할 수 있고 C에서는 포인터로 작업할 수 있으며 물론 Windows의 기본은 OOP가 아니지만 기본 방식으로 void 포인터를 지원하지 않는 MQL에 대해 이야기합니다. if then else로 복잡한 GUI를 코딩할 수 있습니다. 최소한 성능 저하 없이 사용할 수 있는 결과는 아닙니다.
그리고 이 답변에는 이미 질문이 포함되어 있습니다. 왜 OOP가 더 나은지, "더 나은"은 여전히 잘못된 형용사입니다. OOP 메서드는 이러한 포인터의 사용을 구현하지만 이를 처리하도록 강요하지 않습니다. 내부적으로 OOP는 함수 및 변수 포인터에 대한 다차원 배열로 실현됩니다. 그런 것들을 코딩하려고 하는 것은 당신이 이미 가지고 있는 것만큼 부드럽게 굴러가지 않을 바퀴를 재발명하는 것과 아주 같습니다.
전적으로 어셈블러에서 GUI를 코딩했습니다. 그러나 어셈블러에서는 포인터로 작업할 수 있고 C에서는 포인터로 작업할 수 있으며 물론 Windows의 기본은 OOP가 아니지만 기본 방식으로 void 포인터를 지원하지 않는 MQL에 대해 이야기합니다. if then else로 복잡한 GUI를 코딩할 수 있습니다. 최소한 성능 저하 없이 사용할 수 있는 결과는 아닙니다.
그리고 이 답변에는 이미 질문이 포함되어 있습니다. 왜 OOP가 더 나은지, "더 나은"은 여전히 잘못된 형용사입니다. OOP 메서드는 이러한 포인터의 사용을 구현하지만 이를 처리하도록 강요하지 않습니다. 내부적으로 OOP는 함수 및 변수 포인터에 대한 다차원 배열로 실현됩니다. 그런 것들을 코딩하려고 하는 것은 당신이 이미 가지고 있는 것만큼 부드럽게 굴러가지 않을 바퀴를 재발명하는 것과 아주 같습니다.
제 작은(!) 경험으로 인한 개인적인 취향일 뿐입니다!
1) 예를 들어 Java가 마음에 들지 않습니다. 존재 여부와 관계없이 이름이 무엇인지 모르고 어쨌든 직접 코딩해야하는지 여부를 모르는 함수 에 대해 시간의 99 %를 검색했기 때문입니다 ...
2) mq4나 Perl과 같은 언어와 같은 스크립트를 작성하는 데 필요한 것보다 더 많이 작성해야 하기 때문에 C++를 좋아하지 않습니다.
3) 다른 사람의 코드를 이해하면 파일에서 파일로 건너뛸 수 있기 때문에 C++가 마음에 들지 않습니다. 왜냐하면 2,3줄의 함수만 찾을 수 있기 때문에 무엇을, 어떻게 s.th를 찾는 것이 정말 어렵습니다. 계산됩니다. 물론 "계산 중지"와 같은 설명이 있지만 calc.-procedure도 다른 파일의 여러 기능으로 분할됩니다.
4) 열거형 및 열거형 변수 배열에 대해 전혀 문제가 없습니다. 상상한 실제 물체를 코딩할 필요가 없습니다. GUI는 그것을 재사용하는 쉬운 방법을 위해 객체로 코딩될 수 있는 다른 많은 것들로 구성되어 있기 때문에 다른 문제일 수 있습니다. 그러나 EA에는 얼마나 많은 다른 개체가 필요합니까? 포지션을 위한 하나? 다양한 '객체'(GUI)가 있으면 도움이 될 수 있지만 여기에서는 볼 수 없습니다.
5) 마지막으로 MQ5는 여전히 고객 틱에 대한 백테스트를 실행할 수 없습니다 .
나는 코드 어셈블을 하는 사람을 정말 존경합니다. 당신은 하드웨어 자체가 어떻게 작동하는지에 대한 좋은 지식이 있어야 합니다.
나는 더 이상 그것을 코딩하지 않지만 과거에는 주로 주로. Intel 80x86 칩에서는 시각적 성능 측면에서 진정한 우위를 점할 수 있는 유일한 기회였습니다. 물론 더 이상 자세히 필요하지 않더라도 절대 놓치고 싶지 않은 기본 지식이지만 결국에는 코드에서 어떤 일이 발생하는지 항상 알고 있으며 이를 이점으로 사용하는 방법을 알고 있습니다. 실행 속도 보기.
예 "좋았던" 옛날 ;) ... 하지만 역시 변수도 없었고, 실제 기능 도 없었고, if then else도 없었고 레지스터, 스택, 인터럽트 및 메모리 주소만 있었습니다. 미친놈아 :)
OOP는 재사용 가능한 작은 부분으로 코드를 분할하는 도구입니다. 그러나 가장 좋은 부분은 템플릿입니다. 이 기능을 사용하면 코드를 단순화할 수 있습니다. 가장 좋은 예는 배열 클래스입니다. Java에서는 유형에 대한 클래스를 작성했습니다 . C++ 및 Mql5에서는 프리미티브와 객체를 혼합할 때 중복 코드를 줄이고 일부 문제를 우회할 수 있습니다.
추신: ASM에 관해서는 오래된 학교입니다. 나는 처음으로 보호 모드 컴파일러를 사용하기 전에 그것을 사용했고 재미있는 오버패스 제한이었습니다. 선택기가 있는 64K 세그먼트는 그 당시 코더의 악몽이었습니다. 잘못된 위치에 글을 쓸 때마다 컴퓨터를 재부팅했습니다. :)