그건 그렇고, 리더십 경험에 대해. 5년 전, 우리는 mql5 포럼에서 MT5의 전망에 대해 논쟁을 벌였습니다. 그때 저는 시간이 말해줄 것이라고 말했습니다. 5년이 지났고 커뮤니티가 MT5를 거부했음을 알 수 있습니다.
정보가 부족합니다. 우리는 클라이언트 및 구현의 기반을 광고하지 않습니다.
나는 이론 자체가 아니라 실제 적용을 위해 일반 원칙, 이론을 번역하지 않습니다. 동일한 C/C++ 컴파일러에서는 그러한 심각한 "결함"을 찾지 못할 것입니다.
그리고 그들은 그들에 대해 저자에게 보고하기까지 했습니다.
이 경우 "정적 클래스 메서드는 클래스의 내용으로 올라갈 수 있는 권한이 없다"고 말하면 객체를 동적으로 생성할 때 왜 이미 이 권한을 가지고 있습니까?
나는 "우리가 그것을 보호하기 위해 과도하게 사용했습니다. 우리가 고칠 것입니다."라고 말했습니다. 이론상 조건은 간단해 보이지만 실제로는 정적/동적 구현이 다르게 작동하여 불일치가 발생합니다.
그러나 non-static 것이 같은 방식으로 행동한다는 사실은 어떻습니까?
마찬가지로 "비공개는 비공개를 의미합니다" 규칙은 "생성자/소멸자에 대한 예외를 만들라"는 뉘앙스를 압도했습니다. 수정하겠습니다.
언어 구현에 오류가 있으면 글쎄요, 오류입니다. 당신은 전체 품질 관리에 대해 이야기하고 있습니다. 따라서 실제로 MQL4++ 컴파일러의 구현 오류를 제거하여 C++ 컴파일러에서와 같이 오류를 찾기가 거의 어려울 것입니다. 왜냐하면 그러한 제어가 있기 때문입니다. 나는 여전히 파서가 내가 보여준 것과 같은 오류를 제거하는 데 도움이 될 수 있다고 생각하지 않습니다.
맞습니다. 이것은 우리가 처음부터 작성한 컴파일러의 오류/간과입니다. 그래서 이것은 갈퀴를 줍는 일반적인 방법입니다.
전체 품질 관리는 버그에 대한 작업에 대한 체계적인 접근 방식이며 버그를 찾는 데 중점을 둡니다. 그것이 우리가 하고 있는 일입니다. 이에 반해 강압에 반대하며 기술적 수단을 통한 엄격한 통제를 원하지 않는다고 선언한다.
좋아하고 싫어하고의 문제가 아닙니다. 도구가 있습니다. 모든 기능 사용을 거부해야 하는 이유는 무엇입니까?
이 경우 "좋아요"도 아닙니다. 그 점에서 이것은 Myers가 그토록 좋아하는 것입니다. 그리고 어떤 이유로 C ++ 컴파일러에 "고의적인 여행"을 시도했다고 아무도 그를 비난하지 않습니다.
"이것은 C++ 언어가 아니라 특수 MQL4/MQL5 언어입니다. 따라서 모든 것을 지원할 의무는 없습니다."라는 좋은 설명이 있습니다. 그러나 어떤 경우에도 동작은 가장 친숙한 C/C++로 축소됩니다.
이것은 쉬운 일이 아니며 직접 해결되지도 않습니다. 여기서 많은 노력을 기울여야합니다. 대다수의 MQL 사용자는 프로그래머가 아닙니다. 그리고 언어를 디자인할 때, 이것은 상당한 정도로 고려되어야 합니다. 하지만 문제는 확실히 해결되었습니다.
그 문제에 대해서는 이전 MQL4에 구조를 추가하고 MQL4++에 대해 수행된 것처럼 작업 우선 순위와 같은 것을 정리하는 것으로 충분합니다. 이는 합리적인 절충안이 될 것입니다. MT4의 성공은 무엇보다도 언어의 "속임수"가 부족했기 때문입니다. 이제 그렇지 않습니다. 그리고 컴파일러의 구현에 훨씬 더 많은 오류가 있습니다. MQL4++가 이전 MQL4보다 훨씬 더 복잡하고 개발 팀이 많이 변경되었을 가능성이 없기 때문입니다.
나는 여기에 동의하지만 이것은 주로 경쟁자들이 이해할 수없는 일을하고 있다는 사실 때문이라고 생각합니다.
지난 14년 동안 5번의 거래 플랫폼을 처음부터 다시 작성했습니다.
이것은 떨어지는 벽돌을 오래된 당나귀에 싣는 것보다 정말 멋진 것을 만드는 더 좋은 방법입니다. 따라서 MT5와 새로운 MQL5의 출시는 우리에게 앞으로 10년 더 큰 미래를 제공했습니다.
하지만 앉아서 오래된 프로젝트 를 보고 "새롭게 시작해서 실패해도 해고하지 않는다는 게 중요한 것" 이라는 생각을 하며 경영진의 존경을 잃고, 발기부전으로 기록되고 천천히 무대를 떠납니다.
MT4가 나왔을 때 MT3는 지원을 중단하고 매우 빠르게 제공되었습니다. 모두가 MT4로 전환했습니다. MT4 - MT5 쌍의 경우 기간이 길었지만 이러한 일이 발생하지 않았습니다. 그리고 여전히 MT4에 대한 분명한 편견이 있습니다.
컴파일러를 포함하여 MT5에서 MT4로의 개발을 역으로 이식하기도 했습니다. MT4에서 MT3로, 그리고 출시 후 4년이 지난 후에도 무언가가 이전되었습니까?
레나트 : 그리고 그들은 그들에 대해 저자에게 보고하기까지 했습니다.
그러나 차이점이 있습니다. 최신 C/C++ 컴파일러에서 오류를 찾는 것은 MQL4++에서보다 수천 배는 아니더라도 수백 배는 더 어려울 것입니다.
레나트 :
나는 "우리가 그것을 보호하기 위해 과도하게 사용했습니다. 우리가 고칠 것입니다."라고 말했습니다. 이론상 조건은 간단해 보이지만 실제로는 정적/동적 구현이 다르게 작동하여 불일치가 발생합니다.
마찬가지로 "비공개는 비공개를 의미합니다" 규칙은 "생성자/소멸자에 대한 예외 지정" 뉘앙스를 압도했습니다. 이 문제를 해결하겠습니다.
맞습니다. 이것은 우리가 처음부터 작성한 컴파일러의 오류/간과입니다. 그래서 이것은 갈퀴를 줍는 일반적인 방법입니다.
전체 품질 관리는 버그에 대한 작업에 대한 체계적인 접근 방식이며 버그를 찾는 데 중점을 둡니다. 그것이 우리가 하고 있는 일입니다.
여기서 특별한 "엔진"도 필요하지 않은 일반적인 회귀 테스트를 적용하면 충분합니다. 언어의 클래스/구조에 액세스 제어가 있습니다. 컴파일된 MQL 프로그램의 형태로 한 번만 테스트하면 됩니다. 일부는 성공적으로 컴파일되어야 하고, 다른 일부는 일종의 오류와 함께 실패해야 합니다. 이것이 바로 이 특정 장소의 전체 품질 관리입니다. 사실, 액세스 제어의 모든 기능을 다루는 테스트를 먼저 작성해야 합니다...
레나트 : 이에 반해 강압에 반대하며 기술적 수단을 통한 엄격한 통제를 원하지 않는다고 선언한다.
이것은 반대가 아닙니다. 기본적으로 MQL 프로그램용 MQL 컴파일러에서 경고와 일부 C++ 컴파일러에서 언급이라고 하는 것을 모두 활성화할 수 있습니다. 적어도 발언은 끊어야 한다고 "선언"합니다. MQL 프로그램용 MQL 컴파일러에서. 이제 MQL4++ 컴파일러에서 이러한 의미에서 비활성화할 수 있는 것은 없습니다.
특히 MQL 컴파일러 자체의 구현에서는 오류가 너무 쉽게 감지되기 때문에 품질 관리가 부족합니다. MQL 프로그램의 엄격한 품질 관리와 어떤 관련이 있습니까?
레나트 : "이것은 C++ 언어가 아니라 특수 MQL4/MQL5 언어입니다. 따라서 모든 것을 지원할 의무는 없습니다."라는 좋은 설명이 있습니다. 그러나 어떤 경우에도 동작은 가장 친숙한 C/C++로 축소됩니다.
괜찮은. 당신은 모든 것을 지원하지 않습니다. 그러나 지원되는 것에는 그러한 양의 오류가 포함되어서는 안되며 가장 단순한 기본 구성에서도 오류가 포함되어서는 안됩니다.
/******************************************************************************/class A {
private :
class B { };
};
/******************************************************************************/voidOnStart () {
A a;
B b;
}
이것은 오류 없이 컴파일됩니다:
'3.mq4' 3.mq4 1 1
0 error(s), 0 warning(s) 1 1
그러나 C ++에서 이 코드는 두 가지 이유로 컴파일되지 않습니다.
$ clang -c 3 .cpp
3 .cpp: 10 : 3 : error: unknown type name 'B'
B b;
^
1 error generated.
클래스 B는 클래스 A 내에 정의되어 있으므로 OnStart()에서 A::B로 참조해야 합니다.
class A {
private :
class B { };
};
/******************************************************************************/voidOnStart () {
A a;
A::B b;
}
하지만 그게 다가 아닙니다. 수정된 코드는 여전히 C++ 컴파일러에서 컴파일되지 않습니다.
$ clang -c 3 .cpp
3 .cpp: 10 : 6 : error: 'B' is a private member of 'A'
A::B b;
^
3 .cpp: 4 : 9 : note: declared private here
class B { };
^
1 error generated.
어떤 이유로 MQL4++의 액세스 제어는 일반적으로 메서드 및 데이터(클래스 멤버)에 대해 작동하지만 유형에는 작동하지 않습니다.
클래스 B의 범위를 A::B로 지정할 때 MQL4++ 컴파일러는 다음 오류를 생성합니다.
'3.mq4' 3.mq4 1 1
'B' - struct member undefined 3.mq4 12 6
'b' - undeclared identifier 3.mq4 12 8
'b' - some operator expected 3.mq4 12 8
expression has no effect 3.mq4 12 6
3 error(s), 1 warning(s) 4 2
이것이 "구조체 멤버가 정의되지 않은" 이유이기도 합니다.
그리고 다시, C++ 컴파일러는 클래스 내의 유형에 문제가 없습니다. 그리고 MQL4++ 컴파일러는 그렇게 합니다.
이러한 오류는 Myers 싱글톤을 구현하려고 할 때 우연히 발견되었으며 이 경우 아무도 특별히 오류를 찾지 않았습니다. 일부 오류는 내가 발견했고 일부는 토론의 다른 참가자에 의해 발견되었습니다. 이것은 MQL4++에서 프로그래밍할 때 컴파일러 구현 오류를 발견하는 것이 얼마나 쉬운지를 보여줍니다. 그리고 오류를 발견하기 위해 특별히 아무 것도 찾을 필요가 없으며 문제를 해결하려고 시도하는 것으로 충분합니다.
이것들은 모두 MQL4++의 심각한 사용에 대한 중대한 오류임을 강조하겠습니다.
분명히 위에서 언급한 유형의 회귀 테스트는 없습니다. 최소한 간단한 상태 확인의 경우, 최소한 MQL4++ 컴파일러를 확인하기 위한 액세스 제어의 경우입니다. 그렇지 않으면 이미 식별되고 수정되었을 것입니다.
레나트 : 지난 14년 동안 5번의 거래 플랫폼을 처음부터 다시 작성했습니다.
이것은 떨어지는 벽돌을 오래된 당나귀에 싣는 것보다 정말 멋진 것을 만드는 더 좋은 방법입니다. 따라서 MT5와 새로운 MQL5의 출시는 우리에게 앞으로 10년 더 큰 미래를 제공했습니다.
하지만 앉아서 오래된 프로젝트를 보고 "새롭게 시작해서 실패해도 해고하지 않는다는 게 중요한 것" 이라는 생각을 하며 경영진의 존경을 잃고, 발기부전으로 기록되고 천천히 무대를 떠납니다.
혁신적 발전을 통한 적극적인 행동이 가장 중요한 요소라는 점에는 동의하지만 유일한 요소는 아닙니다. 그리고 한 통의 꿀은 연고의 파리로 인해 상할 수 있습니다.
이 연고 중 하나는 분명히 품질이 충분하지 않습니다. 이것 때문에 MQL에서 무언가를 생성하는 포인트가 사라집니다.
새 빌드에서 컴파일되지 않는 칠면조, 올빼미 등의 대규모 데이터베이스가 있는 경우 자세히 살펴보고 "가슴을 흔드는" 것이 좋습니다. 유용한 정보는 남겨두고 시간을 내어 새 빌드를 다시 작성하고 디버그하세요.
어느 순간 질렸다.)
타임 마스터 :
진짜 노련한 프로그래머 또는 그 프로그래머가 되고 싶은 사람들은 항상 혁신을 따르고 버그와 결함은 빵입니다. 좋은 프로그래밍으로 간주되는 오류 없는 코드를 작성하는 것입니다. Metaquotes의 모든 혁신을 탐구할 힘, 시간, 기회 또는 열망이 없다면 유창한 언어를 사용하십시오. DLL이 취소되지 않았습니다. 디버깅된 알고리즘을 연결하십시오.
실제 거래자나 거래자가 되고자 하는 사람들은 어떻게 됩니까? ) MT의 주요 기능인 저렴한 자동 거래는 망각에 빠졌고 수많은 빌드의 끊임없는 혁신 사이에서 사라졌습니다... 프로그래밍에 대한 보다 진지한 접근을 통해 사용할 수 있는 자동 거래 옵션이 있다고 가정해 보겠습니다. 바로 그 MT에는 실제로 잊혀진 작은 계정만 있었습니다. 오늘 저는 MT 도구의 재활에 2시간을 보냈습니다. 분명히 10배는 더 필요합니다. 내가 그것을 필요로 하는지 확신이 서지 않습니다. 아마도 조금 더 파헤칠 것입니다. 오히려 "예전을 위해서"입니다. 원칙적으로 나는 모든 것을 결정했습니다.
MT의 주요 기능인 저렴한 자동 거래는 무수히 많은 빌드의 끊임없는 혁신 속에서 잊혀져 갔고 길을 잃었습니다. 프로그래밍에 대한보다 진지한 접근을 통해 사용할 수있는 자동 거래 옵션이 있다고 가정 해 봅시다. 바로 그 MT에는 실제로 잊혀진 작은 계정만 있었습니다. 오늘 저는 MT 도구의 재활에 2시간을 보냈습니다. 분명히 10배는 더 필요합니다. 내가 그것을 필요로 하는지 확신이 서지 않습니다. 아마도 조금 더 파헤칠 것입니다. 오히려 "예전을 위해서"입니다. 원칙적으로 나는 모든 것을 결정했습니다.
사실, 지금이라도 이전 기능만 사용하면 모든 것이 작동합니다. 일부 작업은 훨씬 더 간단하고 안정적으로 수행할 수 있습니다. 예를 들어 기록의 중단을 고려하면 다음과 같습니다. 그 전에는(µl ++) 중단이 있는 이력을 기반으로 계산하는 기능으로 인해 약간의 "두통"이 발생했습니다. 히스토리의 '꼬리'가 먼저 로드되고 그 다음에 빠진 막대가 안으로 들어간다는 사실) '목발'을 사용해야 했습니다. 이제 모든 것이 훨씬 쉬워졌습니다. 추가 기능을 사용할 수 없으며 이전과 같이 LCL을 이전 / 단순화 된 형태로 사용할 수 없습니다. 예외는 배열 오버플로가 있는 프로그램입니다(인덱스가 잘못 계산되었거나 메모리가 할당되지 않은 경우). 이것이 그들이 보장되지 않고 잘못 작동하는 방식입니다.
그건 그렇고, 리더십 경험에 대해. 5년 전, 우리는 mql5 포럼에서 MT5의 전망에 대해 논쟁을 벌였습니다. 그때 저는 시간이 말해줄 것이라고 말했습니다. 5년이 지났고 커뮤니티가 MT5를 거부했음을 알 수 있습니다.
나는 이론 자체가 아니라 실제 적용을 위해 일반 원칙, 이론을 번역하지 않습니다. 동일한 C/C++ 컴파일러에서는 그러한 심각한 "결함"을 찾지 못할 것입니다.
이 경우 "정적 클래스 메서드는 클래스의 내용으로 올라갈 수 있는 권한이 없다"고 말하면 객체를 동적으로 생성할 때 왜 이미 이 권한을 가지고 있습니까?
나는 "우리가 그것을 보호하기 위해 과도하게 사용했습니다. 우리가 고칠 것입니다."라고 말했습니다. 이론상 조건은 간단해 보이지만 실제로는 정적/동적 구현이 다르게 작동하여 불일치가 발생합니다.
그러나 non-static 것이 같은 방식으로 행동한다는 사실은 어떻습니까?
맞습니다. 이것은 우리가 처음부터 작성한 컴파일러의 오류/간과입니다. 그래서 이것은 갈퀴를 줍는 일반적인 방법입니다.
전체 품질 관리는 버그에 대한 작업에 대한 체계적인 접근 방식이며 버그를 찾는 데 중점을 둡니다. 그것이 우리가 하고 있는 일입니다. 이에 반해 강압에 반대하며 기술적 수단을 통한 엄격한 통제를 원하지 않는다고 선언한다.
좋아하고 싫어하고의 문제가 아닙니다. 도구가 있습니다. 모든 기능 사용을 거부해야 하는 이유는 무엇입니까?
이 경우 "좋아요"도 아닙니다. 그 점에서 이것은 Myers가 그토록 좋아하는 것입니다. 그리고 어떤 이유로 C ++ 컴파일러에 "고의적인 여행"을 시도했다고 아무도 그를 비난하지 않습니다.
이것은 쉬운 일이 아니며 직접 해결되지도 않습니다. 여기서 많은 노력을 기울여야합니다. 대다수의 MQL 사용자는 프로그래머가 아닙니다. 그리고 언어를 디자인할 때, 이것은 상당한 정도로 고려되어야 합니다. 하지만 문제는 확실히 해결되었습니다.
그 문제에 대해서는 이전 MQL4에 구조를 추가하고 MQL4++에 대해 수행된 것처럼 작업 우선 순위와 같은 것을 정리하는 것으로 충분합니다. 이는 합리적인 절충안이 될 것입니다. MT4의 성공은 무엇보다도 언어의 "속임수"가 부족했기 때문입니다. 이제 그렇지 않습니다. 그리고 컴파일러의 구현에 훨씬 더 많은 오류가 있습니다. MQL4++가 이전 MQL4보다 훨씬 더 복잡하고 개발 팀이 많이 변경되었을 가능성이 없기 때문입니다.
나는 여기에 동의하지만 이것은 주로 경쟁자들이 이해할 수없는 일을하고 있다는 사실 때문이라고 생각합니다.
지난 14년 동안 5번의 거래 플랫폼을 처음부터 다시 작성했습니다.
이것은 떨어지는 벽돌을 오래된 당나귀에 싣는 것보다 정말 멋진 것을 만드는 더 좋은 방법입니다. 따라서 MT5와 새로운 MQL5의 출시는 우리에게 앞으로 10년 더 큰 미래를 제공했습니다.
하지만 앉아서 오래된 프로젝트 를 보고 "새롭게 시작해서 실패해도 해고하지 않는다는 게 중요한 것" 이라는 생각을 하며 경영진의 존경을 잃고, 발기부전으로 기록되고 천천히 무대를 떠납니다.
정보가 부족합니다. 우리는 클라이언트 및 구현의 기반을 광고하지 않습니다.
공개된 정보와 이전 버전인 MT4에 대한 지원으로 판단하고 있습니다.
MT4가 나왔을 때 MT3는 지원을 중단하고 매우 빠르게 제공되었습니다. 모두가 MT4로 전환했습니다. MT4 - MT5 쌍의 경우 기간이 길었지만 이러한 일이 발생하지 않았습니다. 그리고 여전히 MT4에 대한 분명한 편견이 있습니다.
컴파일러를 포함하여 MT5에서 MT4로의 개발을 역으로 이식하기도 했습니다. MT4에서 MT3로, 그리고 출시 후 4년이 지난 후에도 무언가가 이전되었습니까?
그리고 그들은 그들에 대해 저자에게 보고하기까지 했습니다.
그러나 차이점이 있습니다. 최신 C/C++ 컴파일러에서 오류를 찾는 것은 MQL4++에서보다 수천 배는 아니더라도 수백 배는 더 어려울 것입니다.
나는 "우리가 그것을 보호하기 위해 과도하게 사용했습니다. 우리가 고칠 것입니다."라고 말했습니다. 이론상 조건은 간단해 보이지만 실제로는 정적/동적 구현이 다르게 작동하여 불일치가 발생합니다.
마찬가지로 "비공개는 비공개를 의미합니다" 규칙은 "생성자/소멸자에 대한 예외 지정" 뉘앙스를 압도했습니다. 이 문제를 해결하겠습니다.
맞습니다. 이것은 우리가 처음부터 작성한 컴파일러의 오류/간과입니다. 그래서 이것은 갈퀴를 줍는 일반적인 방법입니다.
전체 품질 관리는 버그에 대한 작업에 대한 체계적인 접근 방식이며 버그를 찾는 데 중점을 둡니다. 그것이 우리가 하고 있는 일입니다.
여기서 특별한 "엔진"도 필요하지 않은 일반적인 회귀 테스트를 적용하면 충분합니다. 언어의 클래스/구조에 액세스 제어가 있습니다. 컴파일된 MQL 프로그램의 형태로 한 번만 테스트하면 됩니다. 일부는 성공적으로 컴파일되어야 하고, 다른 일부는 일종의 오류와 함께 실패해야 합니다. 이것이 바로 이 특정 장소의 전체 품질 관리입니다. 사실, 액세스 제어의 모든 기능을 다루는 테스트를 먼저 작성해야 합니다...
이에 반해 강압에 반대하며 기술적 수단을 통한 엄격한 통제를 원하지 않는다고 선언한다.
이것은 반대가 아닙니다. 기본적으로 MQL 프로그램용 MQL 컴파일러에서 경고와 일부 C++ 컴파일러에서 언급이라고 하는 것을 모두 활성화할 수 있습니다. 적어도 발언은 끊어야 한다고 "선언"합니다. MQL 프로그램용 MQL 컴파일러에서. 이제 MQL4++ 컴파일러에서 이러한 의미에서 비활성화할 수 있는 것은 없습니다.
특히 MQL 컴파일러 자체의 구현에서는 오류가 너무 쉽게 감지되기 때문에 품질 관리가 부족합니다. MQL 프로그램의 엄격한 품질 관리와 어떤 관련이 있습니까?
"이것은 C++ 언어가 아니라 특수 MQL4/MQL5 언어입니다. 따라서 모든 것을 지원할 의무는 없습니다."라는 좋은 설명이 있습니다. 그러나 어떤 경우에도 동작은 가장 친숙한 C/C++로 축소됩니다.
괜찮은. 당신은 모든 것을 지원하지 않습니다. 그러나 지원되는 것에는 그러한 양의 오류가 포함되어서는 안되며 가장 단순한 기본 구성에서도 오류가 포함되어서는 안됩니다.
클래스/구조의 구성원에 대한 액세스 제어를 지원합니까? 가장 간단한 기본 구성에서 최소한 모든 주요 사례를 오류 없이 지원합니다.
가장 간단한 기본 구성에서 동일한 액세스 제어를 사용합시다.
이것은 오류 없이 컴파일됩니다:
그러나 C ++에서 이 코드는 두 가지 이유로 컴파일되지 않습니다.
클래스 B는 클래스 A 내에 정의되어 있으므로 OnStart()에서 A::B로 참조해야 합니다.
하지만 그게 다가 아닙니다. 수정된 코드는 여전히 C++ 컴파일러에서 컴파일되지 않습니다.
어떤 이유로 MQL4++의 액세스 제어는 일반적으로 메서드 및 데이터(클래스 멤버)에 대해 작동하지만 유형에는 작동하지 않습니다.
클래스 B의 범위를 A::B로 지정할 때 MQL4++ 컴파일러는 다음 오류를 생성합니다.
이것이 "구조체 멤버가 정의되지 않은" 이유이기도 합니다.
그리고 다시, C++ 컴파일러는 클래스 내의 유형에 문제가 없습니다. 그리고 MQL4++ 컴파일러는 그렇게 합니다.
이러한 오류는 Myers 싱글톤을 구현하려고 할 때 우연히 발견되었으며 이 경우 아무도 특별히 오류를 찾지 않았습니다. 일부 오류는 내가 발견했고 일부는 토론의 다른 참가자에 의해 발견되었습니다. 이것은 MQL4++에서 프로그래밍할 때 컴파일러 구현 오류를 발견하는 것이 얼마나 쉬운지를 보여줍니다. 그리고 오류를 발견하기 위해 특별히 아무 것도 찾을 필요가 없으며 문제를 해결하려고 시도하는 것으로 충분합니다.
이것들은 모두 MQL4++의 심각한 사용에 대한 중대한 오류임을 강조하겠습니다.
분명히 위에서 언급한 유형의 회귀 테스트는 없습니다. 최소한 간단한 상태 확인의 경우, 최소한 MQL4++ 컴파일러를 확인하기 위한 액세스 제어의 경우입니다. 그렇지 않으면 이미 식별되고 수정되었을 것입니다.
지난 14년 동안 5번의 거래 플랫폼을 처음부터 다시 작성했습니다.
이것은 떨어지는 벽돌을 오래된 당나귀에 싣는 것보다 정말 멋진 것을 만드는 더 좋은 방법입니다. 따라서 MT5와 새로운 MQL5의 출시는 우리에게 앞으로 10년 더 큰 미래를 제공했습니다.
하지만 앉아서 오래된 프로젝트를 보고 "새롭게 시작해서 실패해도 해고하지 않는다는 게 중요한 것" 이라는 생각을 하며 경영진의 존경을 잃고, 발기부전으로 기록되고 천천히 무대를 떠납니다.
혁신적 발전을 통한 적극적인 행동이 가장 중요한 요소라는 점에는 동의하지만 유일한 요소는 아닙니다. 그리고 한 통의 꿀은 연고의 파리로 인해 상할 수 있습니다.
이 연고 중 하나는 분명히 품질이 충분하지 않습니다. 이것 때문에 MQL에서 무언가를 생성하는 포인트가 사라집니다.
나는 SSE2에 대해 이야기하고 있습니다. 주제에 없을 수도 있지만 즐겁게 듣고 있습니다.
그런 다음 컴퓨터 중 하나를 변경해야하지만 전부는 아니지만 주제에서 산만 해지며 포럼을 읽는 것을 제외하고는 무역이 아니라 개발에 사용하지 않습니다.
안녕하세요 포럼입니다!
MT5로 전환하고 있으며 몇 가지 질문을 하고 싶습니다.
공작에게 물어보세요.
파블릭 만약 당신은 볼 것입니다 다음 뉴스를 보내
r.klassen.ruit@web.de
판사
새 빌드에서 컴파일되지 않는 칠면조, 올빼미 등의 대규모 데이터베이스가 있는 경우 자세히 살펴보고 "가슴을 흔드는" 것이 좋습니다. 유용한 정보는 남겨두고 시간을 내어 새 빌드를 다시 작성하고 디버그하세요.
어느 순간 질렸다.)
진짜 노련한 프로그래머 또는 그 프로그래머가 되고 싶은 사람들은 항상 혁신을 따르고 버그와 결함은 빵입니다. 좋은 프로그래밍으로 간주되는 오류 없는 코드를 작성하는 것입니다. Metaquotes의 모든 혁신을 탐구할 힘, 시간, 기회 또는 열망이 없다면 유창한 언어를 사용하십시오. DLL이 취소되지 않았습니다. 디버깅된 알고리즘을 연결하십시오.
실제 거래자나 거래자가 되고자 하는 사람들은 어떻게 됩니까? ) MT의 주요 기능인 저렴한 자동 거래는 망각에 빠졌고 수많은 빌드의 끊임없는 혁신 사이에서 사라졌습니다... 프로그래밍에 대한 보다 진지한 접근을 통해 사용할 수 있는 자동 거래 옵션이 있다고 가정해 보겠습니다. 바로 그 MT에는 실제로 잊혀진 작은 계정만 있었습니다. 오늘 저는 MT 도구의 재활에 2시간을 보냈습니다. 분명히 10배는 더 필요합니다. 내가 그것을 필요로 하는지 확신이 서지 않습니다. 아마도 조금 더 파헤칠 것입니다. 오히려 "예전을 위해서"입니다. 원칙적으로 나는 모든 것을 결정했습니다.
MT의 주요 기능인 저렴한 자동 거래는 무수히 많은 빌드의 끊임없는 혁신 속에서 잊혀져 갔고 길을 잃었습니다. 프로그래밍에 대한보다 진지한 접근을 통해 사용할 수있는 자동 거래 옵션이 있다고 가정 해 봅시다. 바로 그 MT에는 실제로 잊혀진 작은 계정만 있었습니다. 오늘 저는 MT 도구의 재활에 2시간을 보냈습니다. 분명히 10배는 더 필요합니다. 내가 그것을 필요로 하는지 확신이 서지 않습니다. 아마도 조금 더 파헤칠 것입니다. 오히려 "예전을 위해서"입니다. 원칙적으로 나는 모든 것을 결정했습니다.
어느 순간 질렸다.)
그리고 누군가 govnokoda를 낳은 사실에 대해 누구를 비난해야합니까 ???
figar0 :
원칙적으로 나는 모든 것을 결정했습니다.붙잡으려는 사람이 있습니까? 올가미 던지고 잡고???
그리고 누군가 govnokoda를 낳은 사실에 대해 누구를 비난해야합니까 ???
여기 더러운 코드는 무엇입니까? 몇 가지 기본적인 사항이 변경되었습니다.