MQL5의 미래 - MQL5+ 또는 MQL6 - 페이지 11

새 코멘트
 
Alexey Kozitsyn :

모든 것이 이미 파악되었습니다. NULL 상수를 사용합니다.

비밀을 하나 말하겠습니다. 이미 구현되었습니다. 마우스 휠을 클릭해야 십자형이 나타납니다.

그리고 이것은 오랫동안 가능했습니다. 탐색기에서 표시기가 이미 연결된 창으로 표시기를 끕니다.

IMHO, 가장 필요한 것은 아닙니다.

네비게이터, 즐겨찾기, 템플릿, 프로필이 있습니다. 모든 것을 사용자 정의할 수 있습니다. 터미널에서 도움말을 읽고 새로운 것을 많이 발견하세요!

열거는 코드를 더 읽기 쉽게 만들고 상수를 제거하며 대신 사람에게 친숙한 엔터티를 넣는 데 사용됩니다.

예를 들어, ENUM_DAY_OF_WEEK 열거형 값을 사용하여 MqlDateTime 구조의 day_of_week 값과 비교할 수 있습니다. 저것들. 다음과 같이 작성할 수 있습니다.

그리고 당신은 다르게 쓸 수 있습니다:

SUNDAY는 값이 0인 int 유형의 명명된 상수입니다.

코드를 읽는 사람이 어떻게 더 명확해질 것이라고 생각합니까?

시원한! 네비게이터 감사합니다! 그에게 충분한 관심을 기울이지 않았습니다. 나는 일반적으로 공간을 차지하지 않도록 끕니다. 비록 짧지만 읽어보세요. 칠면조를 차트 창으로 끌어다 놓는 것과 관련하여 아무 것도 없습니다. 추측하는 것은 가능하지만 시도를 해보는 것은 가능합니다 ....)))

열거의 의미를 설명해 주셔서 감사합니다! 그러나 MQL은 기본적으로 C ++를 사용한 추적 문서이고 이에 대한 도크가 많이 있기 때문에 신속하게 처리했습니다. 그러나 도움말 및 불완전한 기사에 많은 오타가 있습니다. 이것은 좋지 않습니다.

결과. 잘 작성된 도움말을 사용하면 포럼에 있는 인형의 어리석은 질문을 피할 수 있습니다!

NULL 부분에서는 0입니다. 많이 사용됩니다. 그러나 변수의 최대값은 극히 드물며 거의 없습니다. 예를 들어, 변수는 지표를 분석한 후 BUY, SELL 또는 NOTHING의 세 가지 상태를 저장합니다. 기성 상수 POSITION_TYPE_BUY, POSITION_TYPE_SELL 을 사용하는 경우 그 중 하나는 0입니다. 모든 유형으로 일반화하면 EMPTY_VALUE가 NULL보다 더 유명할 것이라고 확신합니다.))

 
Alexander Puzanov :

매우 유용한 또 다른 응용 프로그램이 있습니다. 예를 들어:

그리고 사용자는 "구매만", "판매만" 등 댓글에 작성한 항목 중 4개 항목을 선택할 수 있는 드롭다운 목록을 받습니다. Pts는 사용자 설정 창에 표시기 세트, 기간, 조건 세트 등을 나열하는 데 편리합니다.

그렇지! 이 경우 프로그램에서 사용자가 입력한 값을 확인하는 메커니즘을 단순화하는 추가할 수 있습니다. 저것들. 이들 모두(올바른 값)가 처음에 설명됩니다.
 
agvozdezkiy :

NULL 부분에서는 0이며 많이 사용됩니다. 예를 들어, 변수는 지표를 분석한 후 BUY, SELL 또는 NOTHING의 세 가지 상태를 저장합니다. 기성 상수 POSITION_TYPE_BUY, POSITION_TYPE_SELL 을 사용하는 경우 그 중 하나는 0입니다.

문제 없습니다. 다음과 같이 할 수 있습니다.

 #define VALUE_EMPTY - 1        // Пустое значение для числовых типов данных
#define STR_VALUE_EMPTY ""    // Пустое значение для строкового типа

그리고 원하는 곳에 두세요.

 
Alexey Kozitsyn :

문제 없습니다. 다음과 같이 할 수 있습니다.

그리고 원하는 곳에 두세요.

이 모든 것은 이해할 수 있습니다. 나는 그것에 대해 말하는 것이 아니다.
 
agvozdezkiy :
이 모든 것은 이해할 수 있습니다. 나는 그것에 대해 말하는 것이 아니다.

그럼 무슨 말인지 설명해? 사전 정의된 모든 데이터 유형 에 대한 단일 상수에 대해? 이것이 구현될 가능성은 거의 없습니다.

 
Renat Fatkhullin :

불행히도 숙련된 프로그래머만이 그러한 경고의 유용성과 중요성을 이해합니다.

글쎄, 나는 다른 모든 사람들이 컴파일러의 이러한 수준의 도움을 즐기고 실수를 수정하도록 권장합니다. 이것은 잠재적인 오류의 실제 위치이며 초보 개발자가 배우는 것이 중요합니다.

네임스페이스를 만들 것인가? 그러면 문제가 해결될 것입니다.
 

몇 년 전에 포럼에서 "순수한 가상 방법"이라는 주제가 이미 제기되었습니다.

저것들. C ++의 개념에서 본문이 없는 가상 메서드는 자손에서 반드시 재정의되어야 합니다.

 virtual void Func1() = 0 ;

또한 이러한 메서드를 포함하는 클래스는 자동으로 추상화됩니다. 컴파일러도 이를 추적합니다. (글쎄, 이것은 보호 범위에서 생성자를 숨길 수 있지만 표준을 완전히 준수하기 위한 것입니다)

이제 "순수한 가상 방법"의 동작이 심각하게 부족합니다. 이러한 기능이 없으면 라이브러리나 프레임워크를 적절하게 준비하여 옆에 제공하는 것이 불가능합니다. 자신의 자식 클래스(무작위가 아니라 다른 클래스에 내장됨)를 만들고 친절하게 전체를 실행합니다. 상호 작용. 이제 상속된 메서드의 구현을 입력하지 않고 컴파일러가 삼켜 nifiga가 작동하지 않습니다. 상위 클래스의 소스를 파헤쳐 볼까요?

인터페이스의 개념은 OOP의 기본 개념 중 하나입니다. 따라서 MQL6이 아닌 5에서 그러한 것을 구현하고 싶습니다.

그건 그렇고, 가상 기능 문서 에서 오류는 - 

Виртуальная функция, как и обычная функция, должна иметь исполняемое тело. При вызове семантика ее точно такая же, как и у остальных функций.

예시:

 class Base {
private :
         int a;
public :
         virtual int Func1();
};


class Second: public Base {
public :
         int Func2() {
                 return 0 ;
        };      
};

int OnInit () {

        Base* base = new Base();
        Second* foo = new Second();
   return ( INIT_SUCCEEDED );
}

가상 함수 Func1 에는 실행 가능한 본문이 없으며 값을 반환하지도 않지만 오류 없이 컴파일됩니다.

 
Igor Volodin :

몇 년 전에 포럼에서 "순수한 가상 방법"이라는 주제가 이미 제기되었습니다.

저것들. C ++의 개념에서 본문이 없는 가상 메서드는 자손에서 반드시 재정의되어야 합니다.

또한 이러한 메서드를 포함하는 클래스는 자동으로 추상화됩니다. 컴파일러도 이를 추적합니다. (글쎄, 이것은 보호 범위에서 생성자를 숨길 수 있지만 표준을 완전히 준수하기 위한 것입니다)

이제 "순수한 가상 방법"의 동작이 심각하게 부족합니다. 이러한 기능이 없으면 라이브러리나 프레임워크를 적절하게 준비하여 옆에 제공하는 것이 불가능합니다. 자신의 자식 클래스(무용이 아니라 기어처럼 다른 클래스에 내장됨)를 만들고 친절하게 전체를 실행합니다. 상호 작용. 이제 상속된 메서드의 구현을 입력하지 않고 컴파일러가 삼켜 nifiga가 작동하지 않습니다. 상위 클래스의 소스를 파헤쳐 볼까요?

인터페이스의 개념은 OOP의 기본 개념 중 하나입니다. 따라서 MQL6이 아닌 5에서 그러한 것을 구현하고 싶습니다.

그건 그렇고, 가상 기능 문서 에서 오류는 -

예시:

가상 함수 Func1 에는 실행 가능한 본문이 없으며 값을 반환하지도 않지만 오류 없이 컴파일됩니다.

1. 순수 가상 기능이 곧 추가될 예정입니다.

2. 귀하의 예에서 Func1 호출은 어디에 있습니까? 부름이 없습니다. 신체의 존재를 통제할 수 없습니다.

 
Slawa :

1. 순수 가상 기능이 곧 추가될 예정입니다.

2. 귀하의 예에서 Func1 호출은 어디에 있습니까? 부름이 없습니다. 신체의 존재를 통제할 수 없습니다.

VS 2015는 다음과 같이 말했습니다.

심각성 암호 설명 프로젝트 파일 라인 억제 상태

오류 LNK2001 해결되지 않은 외부 기호 "public: virtual int __thiscall Base::Func1(void)"(?Func1@Base@@UAEHXZ) 테스트CPP코드 C:\MyP\AvForex\trunk\TestCPPCode\TestCPPCode.obj 하나

오류 LNK1120 해결되지 않은 외부 항목 1개 테스트CPP코드 C:\MyP\AvForex\trunk\MQL4FilesForFormatting2015\Debug\TestCPPCode.exe 하나

 
Alexey Volchanskiy :

VS 2015는 다음과 같이 말했습니다.

심각성 암호 설명 프로젝트 파일 라인 억제 상태

오류 LNK2001 해결되지 않은 외부 기호 "public: virtual int __thiscall Base::Func1(void)"(?Func1@Base@@UAEHXZ) 테스트CPP코드 C:\MyP\AvForex\trunk\TestCPPCode\TestCPPCode.obj 하나

오류 LNK1120 1개의 해결되지 않은 외부 테스트CPP코드 C:\MyP\AvForex\trunk\MQL4FilesForFormatting2015\Debug\TestCPPCode.exe 하나

소스 코드 표시
1...45678910111213
새 코멘트