누군가 전문가가 "증거"로 compex 라이브러리를 게시할 것으로 기대합니까? ;) 여기 시장에서 팔 수 없는 준비된 것에 대한 링크를 게시할 수 있지만, 만약 내가 그렇게 한다면 Alain은 나를 차버릴 것입니다 ;) 내 프로필을 방문하거나 벽 사진을 보고 아이디어를 얻을 수 있습니다. 나 오후.
또 다른 플랫폼? 이렇게 강력한 컴파일러가 있는 다른 플랫폼은 찾을 수 없습니다. 별말씀을요.
@James Cater - 귀하의 의견에 감사드립니다.
MT 외에 다른 플랫폼이 있습니다. 컴파일러가 다소 강력하기만 하면 간단한 코드를 작성할 수 있는 한 정말 상관없습니다.
당신이 여기서 놓치고 있는 것은 교육입니다. 우리 모두는 여전히 배우고 있으며, 일부는 다른 것보다 더 먼 길에 있습니다. 내가 아는 한 이것은 대회가 아니라 지식과 지원을 교환하는 장소입니다.
그건 그렇고, 나는 이 포럼의 누구도 백만 줄짜리 프로그램을 작성할 것이라고 믿지 않습니다.
Alain Verleyen : 포인트를 놓쳤습니다. Dirk. 전문가가 아닌 사람들은 간단하고 명확한 코드 예제를 원하는데, 사실 이것이 이 주제의 목표였습니다. 그러나 그것은 전문가의 이해를 완전히 넘어선 것 같습니다.
당신은 열쇠가 모든 언어에서 발생한다고 말했습니다. 최신 언어는 "코더" 그룹에 추가할 수 있는 지식이 적은 사람들을 위해 단순화하려고 합니다. 가장 좋은 예는 의사 언어 HTML입니다. 그리고 그것은 큰 실수입니다. MT5가 개발되었을 때 많은 "뉴비"들은 OOP 스타일이 어려웠기 때문에 비난했습니다. 그러나 진실은 모든 직업에 전문가가 있다는 것입니다. 플랫폼을 개선하려면 플랫폼이 복잡합니다. 더 많은 기능은 더 많은 유연성을 제공합니다. 코딩 지식이 없는 사람들이 코딩을 하도록 하십시오 재앙이 될 것이다.
길이 프로젝트 정보는 코더에 따라 다릅니다. 내 라이브러리는 MQL 언어의 중간 크기입니다. 다른 것들은 생성 도구를 위한 작은 라이브러리만 필요합니다. 제 경우에는 시간을 절약하고 향후 개발을 단순화하기 위해 프레임워크를 만드는 데 시간을 보내는 것을 선호합니다. 복잡한 UI를 만들거나 다른 프로젝트에 코드를 재사용하는 것이 더 현명한 방법입니다.
당신은 열쇠가 모든 언어에서 발생한다고 말했습니다. 최신 언어는 "코더" 그룹에 추가할 수 있는 지식이 적은 사람들을 위해 단순화하려고 합니다. 가장 좋은 예는 의사 언어 HTML입니다. 그리고 그것은 큰 실수입니다. MT5가 개발되었을 때 많은 "뉴비"들은 OOP 스타일이 어려웠기 때문에 비난했습니다. 그러나 진실은 모든 직업에 전문가가 있다는 것입니다. 플랫폼을 개선하고 싶다면 플랫폼이 복잡합니다. 더 많은 기능은 더 많은 유연성을 제공합니다. 코딩 지식이 없는 사람들이 코딩을 하도록 하십시오 재앙이 될 것이다.
길이 프로젝트 정보는 코더에 따라 다릅니다. 내 라이브러리는 MQL 언어의 중간 크기입니다. 다른 것들은 생성 도구를 위한 작은 라이브러리만 필요합니다. 제 경우에는 시간을 절약하고 향후 개발을 단순화하기 위해 프레임워크를 만드는 데 시간을 보내는 것을 선호합니다. 복잡한 UI를 만들거나 다른 프로젝트에 코드를 재사용하는 것이 더 현명한 방법입니다.
나는 이 주제를 모두 읽었고 흥미롭지만 기계 코드가 절차적이지 않습니까? 그래서 고급 언어와 OOP가 포함되어 결국 컴파일러에서 절차적으로 번역됩니다. 모든 언어가 절차적 기계어로 번역된다면 모든 것이 절차적 방식으로 수행될 수 있다고 말할 수 있습니다. 프로그래머가 기술을 습득하면 내가 틀렸다면 누군가 저를 고쳐주세요.
Mrluck07 : 나는 이 주제를 모두 읽었고 흥미롭지만 기계 코드가 절차적이지 않습니까? 그래서 고급 언어와 OOP가 포함되어 결국 컴파일러에서 절차적으로 번역됩니다. 모든 언어가 절차적 기계어로 번역된다면 모든 것이 절차적 방식으로 수행될 수 있다고 말할 수 있습니다. 프로그래머가 기술을 습득하면 내가 틀렸다면 누군가 저를 고쳐주세요.
모든 것은 이론적으로 절차적으로 수행될 수 있습니다. 실용적이지 않습니다. 벽돌은 수천 개의 모래 입자로 만들어지므로 벽돌 없이 모래만으로 집을 지을 수 있습니다. 그러나 벽돌이 있으면 아무도 시도하지 않습니다.
비행기는 날개, 바퀴, 좌석, 컴퓨터 등 기성품 부품으로 만들어집니다. 모두 금속이나 플라스틱 또는 유리로 끝이 만들어집니다. 그러나 아무도 순수한 유리, 플라스틱 및 금속으로 비행기를 만들지 않을 것입니다.
일반적인 논쟁의 경우(Alain과 다른 사람들에 대한 응답으로): CArrayObj - 객체 배열을 가져오세요. 이것만으로도 OO의 힘이 무엇인지 답하기에 충분합니다(이는 이보다 훨씬 더 많습니다). 예를 들어 표시기와 같은 모든 개체의 배열을 저장할 수 있습니다. 그리고 전혀 노력하지 않고 이 모든 다양한 지표에 대해 복잡한 작업을 수행하십시오. 예를 들어 표시기 버퍼 가 교차되는 시점을 알고 싶다면 이제 CIndicator에 메서드를 넣으면 됩니다. 등등. 절차상 어떻게 하시겠습니까?
모든 것은 이론적으로 절차적으로 수행될 수 있습니다. 실용적이지 않습니다. 벽돌은 수천 개의 모래 입자로 만들어지므로 벽돌 없이 모래만으로 집을 지을 수 있습니다. 그러나 벽돌이 있으면 아무도 시도하지 않습니다.
비행기는 날개, 바퀴, 좌석, 컴퓨터 등 기성품 부품으로 만들어집니다. 모두 금속이나 플라스틱 또는 유리로 끝이 만들어집니다. 그러나 아무도 순수한 유리, 플라스틱 및 금속으로 비행기를 만들지 않을 것입니다.
일반적인 논쟁의 경우(Alain과 다른 사람들에 대한 응답으로): CArrayObj - 객체 배열을 가져오세요. 이것만으로도 OO의 힘이 무엇인지 답하기에 충분합니다(이는 이보다 훨씬 더 많습니다). 예를 들어 표시기와 같은 모든 개체의 배열을 저장할 수 있습니다. 그리고 전혀 노력하지 않고 이 모든 다양한 지표에 대해 복잡한 작업을 수행하십시오. 예를 들어 표시기 버퍼 가 교차되는 시점을 알고 싶다면 이제 CIndicator에 메서드를 넣으면 됩니다. 등등. 절차상 어떻게 하시겠습니까?
그리고 이것은 전략, 거래, 거래, 신호 등 모든 측면에서 수행할 수 있습니다.
이 주제는 의도적으로 도발적이었지만 주요 질문(절차적 코드는 할 수 없는 OOP는 무엇을 할 수 있는지)에 대한 대답은 아무것도 아닙니다.
OOP는 확실히 벽돌을 만들고 사용하는 유일한 방법은 아닙니다. 그것들은 적어도 절차적 코드에서보다 OOP에서 나쁜 코드를 생성하는 많은 방법입니다(그리고 아마도 더 많은 방법일 것입니다). 실제로 "표준"과는 거리가 먼 Metaquotes에서 제공하는 "표준 라이브러리"를 살펴보십시오.
OOP 대 절차는 쓸모없고 끝없는 논쟁입니다. 더 유용한 것은 "품질 코드를 생성하는 방법? OOP가 있거나 없는, 절차가 있거나 없는, 프로그래밍 패러다임이 있거나 없는"입니다. 목조 주택 한 채를 짓는 것이 필요하다면 벽돌은 필요하지 않지만 훌륭하고 견고하며 신뢰할 수 있는 주택에는 벽돌이 필요합니다.
모든 것은 이론적으로 절차적으로 수행될 수 있습니다. 실용적이지 않습니다. 벽돌은 수천 개의 모래 입자로 만들어지므로 벽돌 없이 모래만으로 집을 지을 수 있습니다. 그러나 벽돌이 있으면 아무도 시도하지 않습니다.
비행기는 날개, 바퀴, 좌석, 컴퓨터 등 기성품 부품으로 만들어집니다. 모두 금속이나 플라스틱 또는 유리로 끝이 만들어집니다. 그러나 아무도 순수한 유리, 플라스틱 및 금속으로 비행기를 만들지 않을 것입니다.
일반적인 논쟁의 경우(Alain과 다른 사람들에 대한 응답으로): CArrayObj - 객체 배열을 가져오세요. 이것만으로도 OO의 힘이 무엇인지 답하기에 충분합니다(이는 이보다 훨씬 더 많습니다). 예를 들어 표시기와 같은 모든 개체의 배열을 저장할 수 있습니다. 그리고 전혀 노력하지 않고 이 모든 다양한 지표에 대해 복잡한 작업을 수행하십시오. 예를 들어 표시기 버퍼 가 교차되는 시점을 알고 싶다면 이제 CIndicator에 메서드를 넣으면 됩니다. 등등. 절차상 어떻게 하시겠습니까?
그리고 이것은 전략, 거래, 거래, 신호 등 모든 측면에서 수행할 수 있습니다.
귀하의 예에서 OO를 코딩하고 컴파일을 클릭하면 기계어 코드가 생성됩니다. 그러나 이 기계어 코드는 절차적입니까? 나는 정말로 대답을 모른다, 여기 누군가가 알고 있습니까? 기계 코드가 절차적 코드인 경우 OO를 더 높은 수준의 언어로만 호출할 수 있습니다. 그러면 코딩이 더 쉬워지지만 특별한 것은 없으므로 숙련된 C 프로그래머는 OO 프로그래머와 동일한 작업을 수행할 수 있습니다. 더 최적화되었습니다. 그래서 내 질문은 ex 코드가 절차 적입니까?
누군가 전문가가 "증거"로 compex 라이브러리를 게시할 것으로 기대합니까? ;) 여기 시장에서 팔 수 없는 준비된 것에 대한 링크를 게시할 수 있지만, 만약 내가 그렇게 한다면 Alain은 나를 차버릴 것입니다 ;) 내 프로필을 방문하거나 벽 사진을 보고 아이디어를 얻을 수 있습니다. 나 오후.
또 다른 플랫폼? 이렇게 강력한 컴파일러가 있는 다른 플랫폼은 찾을 수 없습니다. 별말씀을요.
@James Cater - 귀하의 의견에 감사드립니다.
MT 외에 다른 플랫폼이 있습니다. 컴파일러가 다소 강력하기만 하면 간단한 코드를 작성할 수 있는 한 정말 상관없습니다.
당신이 여기서 놓치고 있는 것은 교육입니다. 우리 모두는 여전히 배우고 있으며, 일부는 다른 것보다 더 먼 길에 있습니다. 내가 아는 한 이것은 대회가 아니라 지식과 지원을 교환하는 장소입니다.
그건 그렇고, 나는 이 포럼의 누구도 백만 줄짜리 프로그램을 작성할 것이라고 믿지 않습니다.
포인트를 놓쳤습니다. Dirk. 전문가가 아닌 사람들은 간단하고 명확한 코드 예제를 원하는데, 사실 이것이 이 주제의 목표였습니다. 그러나 그것은 전문가의 이해를 완전히 넘어선 것 같습니다.
당신은 열쇠가 모든 언어에서 발생한다고 말했습니다. 최신 언어는 "코더" 그룹에 추가할 수 있는 지식이 적은 사람들을 위해 단순화하려고 합니다. 가장 좋은 예는 의사 언어 HTML입니다. 그리고 그것은 큰 실수입니다. MT5가 개발되었을 때 많은 "뉴비"들은 OOP 스타일이 어려웠기 때문에 비난했습니다. 그러나 진실은 모든 직업에 전문가가 있다는 것입니다. 플랫폼을 개선하려면 플랫폼이 복잡합니다. 더 많은 기능은 더 많은 유연성을 제공합니다. 코딩 지식이 없는 사람들이 코딩을 하도록 하십시오 재앙이 될 것이다.
길이 프로젝트 정보는 코더에 따라 다릅니다. 내 라이브러리는 MQL 언어의 중간 크기입니다. 다른 것들은 생성 도구를 위한 작은 라이브러리만 필요합니다. 제 경우에는 시간을 절약하고 향후 개발을 단순화하기 위해 프레임워크를 만드는 데 시간을 보내는 것을 선호합니다. 복잡한 UI를 만들거나 다른 프로젝트에 코드를 재사용하는 것이 더 현명한 방법입니다.
당신은 열쇠가 모든 언어에서 발생한다고 말했습니다. 최신 언어는 "코더" 그룹에 추가할 수 있는 지식이 적은 사람들을 위해 단순화하려고 합니다. 가장 좋은 예는 의사 언어 HTML입니다. 그리고 그것은 큰 실수입니다. MT5가 개발되었을 때 많은 "뉴비"들은 OOP 스타일이 어려웠기 때문에 비난했습니다. 그러나 진실은 모든 직업에 전문가가 있다는 것입니다. 플랫폼을 개선하고 싶다면 플랫폼이 복잡합니다. 더 많은 기능은 더 많은 유연성을 제공합니다. 코딩 지식이 없는 사람들이 코딩을 하도록 하십시오 재앙이 될 것이다.
길이 프로젝트 정보는 코더에 따라 다릅니다. 내 라이브러리는 MQL 언어의 중간 크기입니다. 다른 것들은 생성 도구를 위한 작은 라이브러리만 필요합니다. 제 경우에는 시간을 절약하고 향후 개발을 단순화하기 위해 프레임워크를 만드는 데 시간을 보내는 것을 선호합니다. 복잡한 UI를 만들거나 다른 프로젝트에 코드를 재사용하는 것이 더 현명한 방법입니다.
그래서 사람이 지식을 얻을 수 없습니까?
절차적 대 OOP는 쓸모없는 논쟁입니다. 3년 전에 이미 논의되었으며 내 대답은 완전히 유효합니다. 여기에 더 이상 언급된 내용은 없습니다.
MQL5 Wizard 로 OOP의 큰 잠재력을 볼 수 있습니다. 이러한 도구를 절차적 프로그래밍으로 개발 하는 것은 실현 가능하지만 매우 어려울 것입니다 .
OOP를 사용해야 합니다.
이제부터 위의 경우에 OOP를 더 잘 사용해야 하는 이유와 방법을 보여주는 코드 예제 없이는 구체적이지 않은 게시물을 수락하지 않을 것입니다.
절차적 대 OOP는 쓸모없는 논쟁입니다. 3년 전에 이미 논의되었으며 내 대답은 완전히 유효합니다. 여기에 더 이상 언급된 내용은 없습니다.
OOP를 사용해야 합니다.
이제부터 위의 경우에 OOP를 더 잘 사용해야 하는 이유와 방법을 보여주는 코드 예제 없이는 구체적이지 않은 게시물을 수락하지 않을 것입니다.
나는 이 주제를 모두 읽었고 흥미롭지만 기계 코드가 절차적이지 않습니까? 그래서 고급 언어와 OOP가 포함되어 결국 컴파일러에서 절차적으로 번역됩니다. 모든 언어가 절차적 기계어로 번역된다면 모든 것이 절차적 방식으로 수행될 수 있다고 말할 수 있습니다. 프로그래머가 기술을 습득하면 내가 틀렸다면 누군가 저를 고쳐주세요.
모든 것은 이론적으로 절차적으로 수행될 수 있습니다. 실용적이지 않습니다.
벽돌은 수천 개의 모래 입자로 만들어지므로 벽돌 없이 모래만으로 집을 지을 수 있습니다.
그러나 벽돌이 있으면 아무도 시도하지 않습니다.
비행기는 날개, 바퀴, 좌석, 컴퓨터 등 기성품 부품으로 만들어집니다. 모두 금속이나 플라스틱 또는 유리로 끝이 만들어집니다. 그러나 아무도 순수한 유리, 플라스틱 및 금속으로 비행기를 만들지 않을 것입니다.
일반적인 논쟁의 경우(Alain과 다른 사람들에 대한 응답으로): CArrayObj - 객체 배열을 가져오세요. 이것만으로도 OO의 힘이 무엇인지 답하기에 충분합니다(이는 이보다 훨씬 더 많습니다). 예를 들어 표시기와 같은 모든 개체의 배열을 저장할 수 있습니다.
그리고 전혀 노력하지 않고 이 모든 다양한 지표에 대해 복잡한 작업을 수행하십시오. 예를 들어 표시기 버퍼 가 교차되는 시점을 알고 싶다면 이제 CIndicator에 메서드를 넣으면 됩니다. 등등. 절차상 어떻게 하시겠습니까?
그리고 이것은 전략, 거래, 거래, 신호 등 모든 측면에서 수행할 수 있습니다.
모든 것은 이론적으로 절차적으로 수행될 수 있습니다. 실용적이지 않습니다.
벽돌은 수천 개의 모래 입자로 만들어지므로 벽돌 없이 모래만으로 집을 지을 수 있습니다.
그러나 벽돌이 있으면 아무도 시도하지 않습니다.
비행기는 날개, 바퀴, 좌석, 컴퓨터 등 기성품 부품으로 만들어집니다. 모두 금속이나 플라스틱 또는 유리로 끝이 만들어집니다. 그러나 아무도 순수한 유리, 플라스틱 및 금속으로 비행기를 만들지 않을 것입니다.
일반적인 논쟁의 경우(Alain과 다른 사람들에 대한 응답으로): CArrayObj - 객체 배열을 가져오세요. 이것만으로도 OO의 힘이 무엇인지 답하기에 충분합니다(이는 이보다 훨씬 더 많습니다). 예를 들어 표시기와 같은 모든 개체의 배열을 저장할 수 있습니다.
그리고 전혀 노력하지 않고 이 모든 다양한 지표에 대해 복잡한 작업을 수행하십시오. 예를 들어 표시기 버퍼 가 교차되는 시점을 알고 싶다면 이제 CIndicator에 메서드를 넣으면 됩니다. 등등. 절차상 어떻게 하시겠습니까?
그리고 이것은 전략, 거래, 거래, 신호 등 모든 측면에서 수행할 수 있습니다.
이 주제는 의도적으로 도발적이었지만 주요 질문(절차적 코드는 할 수 없는 OOP는 무엇을 할 수 있는지)에 대한 대답은 아무것도 아닙니다.
OOP는 확실히 벽돌을 만들고 사용하는 유일한 방법은 아닙니다. 그것들은 적어도 절차적 코드에서보다 OOP에서 나쁜 코드를 생성하는 많은 방법입니다(그리고 아마도 더 많은 방법일 것입니다). 실제로 "표준"과는 거리가 먼 Metaquotes에서 제공하는 "표준 라이브러리"를 살펴보십시오.
OOP 대 절차는 쓸모없고 끝없는 논쟁입니다. 더 유용한 것은 "품질 코드를 생성하는 방법? OOP가 있거나 없는, 절차가 있거나 없는, 프로그래밍 패러다임이 있거나 없는"입니다. 목조 주택 한 채를 짓는 것이 필요하다면 벽돌은 필요하지 않지만 훌륭하고 견고하며 신뢰할 수 있는 주택에는 벽돌이 필요합니다.
모든 것은 이론적으로 절차적으로 수행될 수 있습니다. 실용적이지 않습니다.
벽돌은 수천 개의 모래 입자로 만들어지므로 벽돌 없이 모래만으로 집을 지을 수 있습니다.
그러나 벽돌이 있으면 아무도 시도하지 않습니다.
비행기는 날개, 바퀴, 좌석, 컴퓨터 등 기성품 부품으로 만들어집니다. 모두 금속이나 플라스틱 또는 유리로 끝이 만들어집니다. 그러나 아무도 순수한 유리, 플라스틱 및 금속으로 비행기를 만들지 않을 것입니다.
일반적인 논쟁의 경우(Alain과 다른 사람들에 대한 응답으로): CArrayObj - 객체 배열을 가져오세요. 이것만으로도 OO의 힘이 무엇인지 답하기에 충분합니다(이는 이보다 훨씬 더 많습니다). 예를 들어 표시기와 같은 모든 개체의 배열을 저장할 수 있습니다.
그리고 전혀 노력하지 않고 이 모든 다양한 지표에 대해 복잡한 작업을 수행하십시오. 예를 들어 표시기 버퍼 가 교차되는 시점을 알고 싶다면 이제 CIndicator에 메서드를 넣으면 됩니다. 등등. 절차상 어떻게 하시겠습니까?
그리고 이것은 전략, 거래, 거래, 신호 등 모든 측면에서 수행할 수 있습니다.
귀하의 예에서 OO를 코딩하고 컴파일을 클릭하면 기계어 코드가 생성됩니다. 그러나 이 기계어 코드는 절차적입니까? 나는 정말로 대답을 모른다, 여기 누군가가 알고 있습니까? 기계 코드가 절차적 코드인 경우 OO를 더 높은 수준의 언어로만 호출할 수 있습니다. 그러면 코딩이 더 쉬워지지만 특별한 것은 없으므로 숙련된 C 프로그래머는 OO 프로그래머와 동일한 작업을 수행할 수 있습니다. 더 최적화되었습니다. 그래서 내 질문은 ex 코드가 절차 적입니까?