OOP를 배우기 시작했고 다음 장애물을 넘을 수 없습니다. 예를 들어 다음 스크립트는 다음과 같습니다.
CSum result;
voidOnStart ()
{
//---
}
//+----------------------------------------+class CSum
{
public :
int Calculate( int A, int B);
};
//---int CSum::Calculate( int A, int B)
{
return (A+B);
}
"CSum 결과" 줄 없이 컴파일러는 오류를 발생시키지 않습니다. 그리고 다음과 같은 오류가 발생합니다.
Lone_Irbis : 하지만 더 말해 주세요. 전역 변수 시스템을 활용하는 것이 얼마나 가능하거나 가치가 있습니까? 이런 식으로 무언가에 과부하가 걸리거나 어떤 종류의 한계에 부딪힐 수 있습니까? 200개의 변수(테스트가 필요한 코드에 따라 약 절반이 입력으로 바뀌었다가 다시 돌아옴)와 전역 수준에서 약 12.5개의 작은 배열이 있다고 가정해 보겠습니다. 많은 것입니까 아니면 적은 것입니까? ^^' 그리고 시스템을 완성하는 과정에서 2~3배 더 늘어난다면? 그리고 너무 몰두하고 싶지 않다면 서로의 작업 결과가 필요한 많은 하위 시스템 간에 데이터를 교환하는 더 쉬운 방법이 있습니까?
아뇨, 그럴 가치가 없습니다. 전역 변수는 다른 용도로 사용됩니다. 클래스를 사용하여 하위 시스템을 설명합니다. 그리고 일반적으로 배열과 전역 변수의 사용을 거부하는 것이 좋습니다.
paladin800 : Ps, 효과가 있었다. 함수를 배치하는 것과 유사하게 코드 끝에 클래스를 배치했습니다. 나는 그런 순서가 학급에 중요할 것이라고 기대하지 않았다.
예, 순서가 중요합니다. 가장 어려운 경우는 두 클래스가 동시에 서로를 사용하는 경우입니다. 그런 다음 우리가 먼저 삽입한 클래스가 무엇이든 두 번째 클래스는 컴파일러에 알려지지 않고 오류를 생성합니다. 이 경우 클래스 선언은 필수입니다. 귀하의 경우 CSum을 별도의 파일(예: Sum.mqh)로 분리하고 #include "Sum.mqh" 지시문과 함께 포함하는 것이 좋습니다.
C-4 : 아뇨, 그럴 가치가 없습니다. 전역 변수는 다른 용도로 사용됩니다. 클래스를 사용하여 하위 시스템을 설명합니다. 그리고 일반적으로 배열과 전역 변수의 사용을 거부하는 것이 좋습니다.
물론, 나는 클래스를 알아내는 것이 현명할 것이라는 것을 이해합니다 ... 그러나 그것들 없이는 더 친숙하고 어쨌든 작동하는 것처럼 보인다는 점을 감안할 때 여전히 어떻게 든 게으릅니다. 그러나 궁금한 점은 무엇입니까? 코드가 한 작성자에 의해 독점적으로 작성되고 특정 프로그램 외부의 누구에게도 유용하지 않을 것이라는 것이 확실히 알려져 있다면? 어쨌든 누군가를 위해 / 누군가와 함께 / 판매용으로 글을 쓰는 경우에만 수업을 귀찮게하는 것이 항상 합리적이지만 취미로 자신을 위해서는 큰 차이가 없을 것입니다. 미학과 "예상된 대로" 일반에 더하여 이러한 모든 계급 구조에 들어갈 실용적인 감각이 있습니까? 성능? 다른 것?
Lone_Irbis : 물론, 나는 클래스를 알아내는 것이 현명할 것이라는 것을 이해합니다 ... 그러나 그것들 없이는 더 친숙하고 어쨌든 작동하는 것처럼 보인다는 점을 감안할 때 여전히 어떻게 든 게으릅니다. 그러나 궁금한 점은 무엇입니까? 코드가 한 작성자에 의해 독점적으로 작성되고 특정 프로그램 외부의 누구에게도 유용하지 않을 것이라는 것이 확실히 알려져 있다면? 어쨌든 누군가를 위해 / 누군가와 함께 / 판매용으로 글을 쓰는 경우에만 수업을 귀찮게하는 것이 항상 합리적이지만 취미로 자신을 위해서는 큰 차이가 없을 것입니다. 미학과 "예상된 대로" 일반에 더하여 이러한 모든 계급 구조에 들어갈 실용적인 감각이 있습니까? 성능? 다른 것?
정반대. 주문 작성 시 고객이 소스 코드를 요구하는 경우가 많습니다. 그리고 여기에서 클래스에서 함수를 가져와 소스 코드에 삽입해야 합니다. 그럼에도 불구하고 고객은 작업을 하나의 파일로 전송하고 고객에게 전송된 작업에 사용되지 않는 기능이 엄청나게 많은 라이브러리의 산을 끌어오지 않는 것이 좋습니다. 즉, 구조화 된 프로그래밍을 사용하는 것이 좋습니다.
자신의 경우 OOP를 사용하는 것이 좋습니다. 모든 것이 거기에 있으며 소스를 전송할 때 귀찮게 할 필요가 없습니다.
정반대. 주문 작성 시 고객이 소스 코드를 요구하는 경우가 많습니다. 그리고 여기에서 클래스에서 함수를 가져와 소스 코드에 삽입해야 합니다. 그럼에도 불구하고 고객은 작업을 하나의 파일로 전송하고 고객에게 전송된 작업에 사용되지 않는 기능이 엄청나게 많은 라이브러리의 산을 끌어오지 않는 것이 좋습니다. 즉, 구조화 된 프로그래밍을 사용하는 것이 좋습니다.
자신의 경우 OOP를 사용하는 것이 좋습니다. 모든 것이 거기에 있으며 소스를 전송할 때 귀찮게 할 필요가 없습니다.
흠... 글쎄요, 아마도 그렇습니다 :) 즉, 원칙은 물론 매력적으로 보입니다... 이론상. 특히 구조와 클래스 없이는 단일 파일을 가질 수 없다는 점을 고려하면 더욱 그렇습니다. 문제는 제가 주로 호기심에 글을 쓰고 제 임의의 이론을 테스트하고 끝없는 자전거를 발명한다는 것입니다. 동시에, 아이디어를 구현하는 데 필요한 시작 사항만 연구합니다. 이 모든 것은 교육적이고 실험적인 Expert Advisor의 틀 내에서 발생합니다. 처음에는 Martin이 가장 단순했지만 이제는 다기능 스캘퍼(지금도 이론적으로 수익성이 있음)입니다. 그래서 어느 시점에서 로봇은 너무 진부해졌습니다. >.> 대부분의 시간이 적절한 코드 조각을 찾기 위해 마우스 휠을 어리석게 스크롤하기 시작했을 때 별도의 파일(현재 13개의 플러그인 조각)로 자르는 "기발한" 아이디어가 떠올랐습니다. , 공통 개념에 따라 기능을 그룹화하기만 하면 됩니다. 글쎄, 여기 뉴스 파서, 거기에 레벨 처리, 무스 컨트롤러가 있는 또 다른 파서, 별도의 통계 등이 있습니다. 그러나 그 당시 OOP를 다루려는 나의 열정은 더 이상 충분하지 않았습니다 ...
즉, 내 문제는 분명히 마음에 오는 모든 아이디어를 붙잡고 기존 로봇 위에 다소 혼란스러운 순서로 마무리한다는 것입니다. 결과는 다소 이상하고 다양한 모드와 그 조합의 모든 종류의 스위치로 가득 차 있으며 그 중 많은 부분이 미완성 상태로 방치되어 있습니다. 그림은 많은 시간이 걸리지 않도록 입력에서 제거해야 하는 수백 개의 전역 변수 로 보완되며 테스터의 시각화 도우미의 시작 부분에 각인됩니다. 물론, 산더미 같은 쓰레기와 버려진 아이디어나 재작업된 아이디어의 기초가 있습니다.
그리고 나서, 이 모든 쓰레기 더미를 치우고 모든 것을 수업에 밀어넣을 때인 것 같습니다(그리고 먼저 OOP에 대한 최소한 하나의 기사를 끝까지 읽어야 합니다. 그 과정에서 잠들지 않고) ... 하지만 어쨌든 앞으로의 작업은 혼란스럽고 음, 시작하는 이 모든 것의 잠재적인 의미와의 관계입니다. 즉, 모든 것을 클래스로 묶는 것은 그렇게 방대한 작업이 아닌 것 같습니다 ... 그러나 예를 들어, 모든 비공개 / 보호를 불필요하게 무시하고 모든 것을 공개적으로 어리석게 버린다면 의미가 있습니까? 어떻게든 이 모든 것이 하나의 로봇에 모인다면 몇 개의 .mph 폴더, 각각 12개의 일반 기능을 갖는 것보다 더 나은 점은 무엇입니까?
초기화, 연결, 항상 필요한 데이터 수집에 가장 필요한 모든 작업이 이미 등록된 단일 템플릿을 만드는 것이 좋습니다. 등. ...
예상치 못한 아이디어가 떠올랐습니다. 템플릿을 로드하고 이름을 바꾸고 이 특정 아이디어와 관련된 내용만 작성합니다. 그리고 어떤 상황에서든 동일한 데이터를 반환하는 모든 코드에서 항상 사용하는 함수를 클래스에 넣습니다. 그리고 모든 것이 즉시 제자리에 들어갈 것입니다. 그리고 여전히 디렉토리를 구조화하는 것이 가능합니다. \experts\ create (저를 위해) Orders 폴더에는 다른 고객에 속한 모든 파일도 별도의 폴더에 추가합니다. Ideas, Tests 등의 폴더가 있습니다.
불행히도 공식적으로 OOP를 공부 했더라도 OOP 프로그램을 구축할 수는 없습니다. 여기에서는 오히려 이 접근의 철학을 깊이 파고들 필요가 있는데, 이것은 형식적 지식을 습득한 다음의 다음 단계이다. 그래서 그것은 밝혀졌지만 당신은 그것을 필요로합니까? 그러나 최선의 방법에 대해 질문하면 선택한 경로가 최적이 아니라고 생각합니다. 어쨌든 선택은 당신의 몫입니다.
OOP를 배우기 시작했고 다음 장애물을 넘을 수 없습니다. 예를 들어 다음 스크립트는 다음과 같습니다.
"CSum 결과" 줄 없이 컴파일러는 오류를 발생시키지 않습니다. 그리고 다음과 같은 오류가 발생합니다.
무슨 일이야. 클래스의 개체를 올바르게 선언한 것 같습니다.
OOP를 배우기 시작했고 다음 장애물을 넘을 수 없습니다. 예를 들어 다음 스크립트는 다음과 같습니다.
"CSum 결과" 줄 없이 컴파일러는 오류를 발생시키지 않습니다. 그리고 다음과 같은 오류가 발생합니다.
무슨 일이야. 클래스의 개체를 올바르게 선언한 것 같습니다.
하지만 더 말해 주세요. 전역 변수 시스템을 활용하는 것이 얼마나 가능하거나 가치가 있습니까? 이런 식으로 무언가에 과부하가 걸리거나 어떤 종류의 한계에 부딪힐 수 있습니까? 200개의 변수(테스트가 필요한 코드에 따라 약 절반이 입력으로 바뀌었다가 다시 돌아옴)와 전역 수준에서 약 12.5개의 작은 배열이 있다고 가정해 보겠습니다. 많은 것입니까 아니면 적은 것입니까? ^^' 그리고 시스템을 완성하는 과정에서 2~3배 더 늘어난다면? 그리고 너무 몰두하고 싶지 않다면 서로의 작업 결과가 필요한 많은 하위 시스템 간에 데이터를 교환하는 더 쉬운 방법이 있습니까?
CSum 유형의 변수(결과) - CSum에 대한 설명이 작성되기 전에 선언됩니다. 이는 컴파일러가 아직 이 유형을 알지 못함을 의미합니다. 파일의 맨 처음에 CSum을 삽입하십시오.
Ps, 효과가 있었다. 함수를 배치하는 것과 유사하게 코드 끝에 클래스를 배치했습니다. 나는 그런 순서가 학급에 중요할 것이라고 기대하지 않았다.
아뇨, 그럴 가치가 없습니다. 전역 변수는 다른 용도로 사용됩니다. 클래스를 사용하여 하위 시스템을 설명합니다. 그리고 일반적으로 배열과 전역 변수의 사용을 거부하는 것이 좋습니다.
물론, 나는 클래스를 알아내는 것이 현명할 것이라는 것을 이해합니다 ... 그러나 그것들 없이는 더 친숙하고 어쨌든 작동하는 것처럼 보인다는 점을 감안할 때 여전히 어떻게 든 게으릅니다. 그러나 궁금한 점은 무엇입니까? 코드가 한 작성자에 의해 독점적으로 작성되고 특정 프로그램 외부의 누구에게도 유용하지 않을 것이라는 것이 확실히 알려져 있다면? 어쨌든 누군가를 위해 / 누군가와 함께 / 판매용으로 글을 쓰는 경우에만 수업을 귀찮게하는 것이 항상 합리적이지만 취미로 자신을 위해서는 큰 차이가 없을 것입니다. 미학과 "예상된 대로" 일반에 더하여 이러한 모든 계급 구조에 들어갈 실용적인 감각이 있습니까? 성능? 다른 것?
정반대. 주문 작성 시 고객이 소스 코드를 요구하는 경우가 많습니다. 그리고 여기에서 클래스에서 함수를 가져와 소스 코드에 삽입해야 합니다. 그럼에도 불구하고 고객은 작업을 하나의 파일로 전송하고 고객에게 전송된 작업에 사용되지 않는 기능이 엄청나게 많은 라이브러리의 산을 끌어오지 않는 것이 좋습니다. 즉, 구조화 된 프로그래밍을 사용하는 것이 좋습니다.
자신의 경우 OOP를 사용하는 것이 좋습니다. 모든 것이 거기에 있으며 소스를 전송할 때 귀찮게 할 필요가 없습니다.
정반대. 주문 작성 시 고객이 소스 코드를 요구하는 경우가 많습니다. 그리고 여기에서 클래스에서 함수를 가져와 소스 코드에 삽입해야 합니다. 그럼에도 불구하고 고객은 작업을 하나의 파일로 전송하고 고객에게 전송된 작업에 사용되지 않는 기능이 엄청나게 많은 라이브러리의 산을 끌어오지 않는 것이 좋습니다. 즉, 구조화 된 프로그래밍을 사용하는 것이 좋습니다.
자신의 경우 OOP를 사용하는 것이 좋습니다. 모든 것이 거기에 있으며 소스를 전송할 때 귀찮게 할 필요가 없습니다.
흠... 글쎄요, 아마도 그렇습니다 :) 즉, 원칙은 물론 매력적으로 보입니다... 이론상. 특히 구조와 클래스 없이는 단일 파일을 가질 수 없다는 점을 고려하면 더욱 그렇습니다. 문제는 제가 주로 호기심에 글을 쓰고 제 임의의 이론을 테스트하고 끝없는 자전거를 발명한다는 것입니다. 동시에, 아이디어를 구현하는 데 필요한 시작 사항만 연구합니다. 이 모든 것은 교육적이고 실험적인 Expert Advisor의 틀 내에서 발생합니다. 처음에는 Martin이 가장 단순했지만 이제는 다기능 스캘퍼(지금도 이론적으로 수익성이 있음)입니다. 그래서 어느 시점에서 로봇은 너무 진부해졌습니다. >.> 대부분의 시간이 적절한 코드 조각을 찾기 위해 마우스 휠을 어리석게 스크롤하기 시작했을 때 별도의 파일(현재 13개의 플러그인 조각)로 자르는 "기발한" 아이디어가 떠올랐습니다. , 공통 개념에 따라 기능을 그룹화하기만 하면 됩니다. 글쎄, 여기 뉴스 파서, 거기에 레벨 처리, 무스 컨트롤러가 있는 또 다른 파서, 별도의 통계 등이 있습니다. 그러나 그 당시 OOP를 다루려는 나의 열정은 더 이상 충분하지 않았습니다 ...
즉, 내 문제는 분명히 마음에 오는 모든 아이디어를 붙잡고 기존 로봇 위에 다소 혼란스러운 순서로 마무리한다는 것입니다. 결과는 다소 이상하고 다양한 모드와 그 조합의 모든 종류의 스위치로 가득 차 있으며 그 중 많은 부분이 미완성 상태로 방치되어 있습니다. 그림은 많은 시간이 걸리지 않도록 입력에서 제거해야 하는 수백 개의 전역 변수 로 보완되며 테스터의 시각화 도우미의 시작 부분에 각인됩니다. 물론, 산더미 같은 쓰레기와 버려진 아이디어나 재작업된 아이디어의 기초가 있습니다.
그리고 나서, 이 모든 쓰레기 더미를 치우고 모든 것을 수업에 밀어넣을 때인 것 같습니다(그리고 먼저 OOP에 대한 최소한 하나의 기사를 끝까지 읽어야 합니다. 그 과정에서 잠들지 않고) ... 하지만 어쨌든 앞으로의 작업은 혼란스럽고 음, 시작하는 이 모든 것의 잠재적인 의미와의 관계입니다. 즉, 모든 것을 클래스로 묶는 것은 그렇게 방대한 작업이 아닌 것 같습니다 ... 그러나 예를 들어, 모든 비공개 / 보호를 불필요하게 무시하고 모든 것을 공개적으로 어리석게 버린다면 의미가 있습니까? 어떻게든 이 모든 것이 하나의 로봇에 모인다면 몇 개의 .mph 폴더, 각각 12개의 일반 기능을 갖는 것보다 더 나은 점은 무엇입니까?
초기화, 연결, 항상 필요한 데이터 수집에 가장 필요한 모든 작업이 이미 등록된 단일 템플릿을 만드는 것이 좋습니다. 등. ...
예상치 못한 아이디어가 떠올랐습니다. 템플릿을 로드하고 이름을 바꾸고 이 특정 아이디어와 관련된 내용만 작성합니다. 그리고 어떤 상황에서든 동일한 데이터를 반환하는 모든 코드에서 항상 사용하는 함수를 클래스에 넣습니다. 그리고 모든 것이 즉시 제자리에 들어갈 것입니다. 그리고 여전히 디렉토리를 구조화하는 것이 가능합니다. \experts\ create (저를 위해) Orders 폴더에는 다른 고객에 속한 모든 파일도 별도의 폴더에 추가합니다. Ideas, Tests 등의 폴더가 있습니다.
이렇게 하면 스스로 정리할 수 있습니다.