제 생각에는 이 모든 것이 극소수의 사람들에게 필요합니다.
Codebase의 코드로 판단하면 OOP 사용자의 95%가 매우 잘못 사용합니다. 그리고 나머지 5%에서 대부분은 이 모든 가능성이 거의 사용되지 않습니다. 물론 그것들은 즐겁고 유용할 수도 있지만 제 생각에는 이러한 모든 개선 사항이 크게 필요하지 않습니다.
제 생각에는 이 모든 것이 극소수의 사람들에게 필요합니다.
Codebase의 코드로 판단하면 OOP 사용자의 95%가 매우 잘못 사용합니다. 그리고 나머지 5%에서 대부분은 이 모든 가능성이 거의 사용되지 않습니다. 물론 그것들은 즐겁고 유용할 수도 있지만 제 생각에는 이러한 모든 개선 사항이 크게 필요하지 않습니다.
예, 이해합니다. 하지만 코드 기반 외에도 Freelance 및 Market도 있으며 MQ가 제품 품질에 관심을 가져야 하는 곳입니다. 그리고 언어의 품질은 개발 및 디버깅의 품질과 속도에 어떻게든 영향을 미칩니다.
그리고 백분율에 대해 그렇게 이야기한다면 MQL5는 왜 만들어졌습니까? 그들은 여전히 OOP나 다른 것이 필요하지 않은 오래된 하드코어 MQL4에 앉아 있을 것입니다. 99%의 사용자가 모든 것에 만족했습니다)
아마도 일반 프로그래머는 MQL이 여전히 열등한 언어이기 때문에 정확하게 MQL로 가지 않을 것입니다.
나는 그런 주제를 만들기로 결정했습니다. 왜냐하면. 내 관찰에 따르면 MQL 구문의 개발은 오랫동안 정체되어 있으며 최근 몇 년 동안 언어의 개선이 눈에 띄지 않습니다. 개발자가 MQL에 대해 더 작업할 것인지는 모르겠지만 누락된 기능이 많이 있으며 그 중 일부는 매우 필요합니다.
이 스레드에서 주요 소원을 정리하기로 결정했습니다. 먼저 내 목록을 제공하고 누군가가 다른 것을 추가할 것입니다. 그리고 그 과정에서 개발자들이 연결되어 자신의 비전을 표현할 수도 있습니다. 정말 좋을 것입니다.
나는 이 목록을 중요도 순으로 배열했지만(내가 보는 대로) 개인적인 우선 순위가 아닌 순서로 배열했습니다. 저것들. 언어에 가장 기본적이고 없어서는 안 될 것들을 먼저 둡니다. 지침으로 C++ 및 C#의 기능을 사용합니다.
1. 유형 작업: typedef , decltype , auto
이것은 일반적으로 기본 기능이며 최소한 처음 두 지정자입니다. 이름을 지정하고 형식을 취하는 작업은 편의성뿐만 아니라 코드의 안정성과 유연성을 위해 생성됩니다. 모든 곳에서 다른 장소에서 사용되는 특정 유형의 변수에 대해 엄격하게 규정되어 있으면 유형을 변경해야 할 때 문제가 시작됩니다.
많은 사람들이 이미 typedef 에 익숙하지만 불행히도 이것은 여전히 함수 포인터에서만 작동하는 그루터기에 불과합니다. decltype 의 경우 잘 모르는 사람들을 위해 설명하겠습니다. 전달된 표현식의 유형을 인수로 반환하므로 일부 변수 또는 함수의 유형을 다른 유형에 따라 유연하게 설정할 수 있습니다. :
또는 typedef 사용:
C#에서는 typedef 대신 using 이 사용됩니다.
2. 네임스페이스: 네임스페이스
이 주제는 최근에 논의되었습니다. 저에게는 일반적으로 왜 아직 구현되지 않았는지 매우 이상합니다. 그것은 언어에서 필수입니다. 특히 커뮤니티 개발, 코드 기반 사용, 그룹 개발 추세를 고려할 때. 이 경우 이름을 일치시키는 문제가 매우 관련이 있습니다.
그리고 일반적으로 모든 것이 단일 공간의 하나의 힙에 버려지면 잘못된 것입니다.
3. 유형 캐스팅 연산자 , 또는 오히려 클래스의 과부하 가능성. 그것이 없으면 사용자 정의 형식은 본질적으로 열등하고 유연성이 크게 감소합니다.
일반적으로 이것은 간단하게 수행됩니다. 적절한 유형으로 생성자와 캐스팅 연산자를 오버로드하고 이 유형과 구조의 완전한 호환성을 얻습니다.
그러나 MQL에서는 대신 별도의 to_datetime() 메서드를 만들고 모든 곳에서 호출해야 합니다. 또는 편안함과 유연성을 추가하지 않는 DATETIME 및 유형에 대한 대상 함수를 오버로드합니다.
4. 다중 인터페이스 . 글쎄, 이것에 대해 이미 많은 소문과 대화가 있었지만 (3 년 전에 그들이 작업이 진행 중이라고 서비스 데스크에 썼던 것을 기억합니다), 그러나 그 과정은 어떻게 든 끌렸습니다 ... 그것이 진행되고 있다면.
5. 구조용 인터페이스 지원 . 이는 OOP와의 통합 작업에 필요합니다. 이제 종종 목발을 울타리로 묶을 필요가 있습니다.
이 기능은 두 가지 방법으로 구현할 수 있습니다. C#에서와 같이 - 패킹/언패킹(boxing) 을 통해 또는 보다 유연한 옵션 - 구조가 있는 동적 개체의 디스크립터에 연결된 구조에 대한 동적 디스크립터를 생성하여 위치 - 더 효율적일 뿐만 아니라 실제로 구조 및 기타 데이터 유형에 대한 포인터를 생성할 수 있어 유연성이 크게 향상됩니다.
6. 구조 생성자가 그러한 유형을 지원하는 경우 한 유형에서 다른 유형으로 즉석에서 유연한 변환을 허용하는 작은 구조(위의 예와 동일한 DATETIME)를 전달할 때 관련이 있는 값으로 구조를 전달하는 기능. 참조로 전달할 때는 그러한 유연성이 없습니다. 구조에 대한 인터페이스가 구현되더라도 관련성이 떨어집니다.
7. 템플릿의 숫자 매개변수를 설정하는 기능:
두 번째 예의 경우 MQL4에서 없이도 할 수 있습니다. 함수는 모든 차원의 배열을 허용합니다. 그러나 MQL5에서는 다차원 배열로 모든 것이 훨씬 더 복잡합니다.
글쎄, 그래서 작은 것들에 대해 :
9. 포인터 배열을 기본 포인터 배열로 캐스팅(명시적 또는 암시적으로)하는 기능 . 이전 빌드에서는 이것이 효과가 있었고 매우 편리했습니다.
이제 어레이를 새 어레이로 다시 복사한 다음 다시 비용을 낭비해야 합니다.
12. 포인터를 숫자 값으로 명시적으로 캐스팅하는 기능.
이렇게 하면 이진 검색이나 해시 테이블 생성을 통해 원하는 포인터를 빠르게 찾기 위해 값을 기준으로 포인터 배열을 정렬할 수 있습니다. 이제 전체 아이디어를 죽이는 텍스트 형식으로 변환해야만 숫자 값을 얻을 수 있습니다.
13. 템플릿 기본값 설정
나는 지원한다.
제 생각에는 이 모든 것이 극소수의 사람들에게 필요합니다.
Codebase의 코드로 판단하면 OOP 사용자의 95%가 매우 잘못 사용합니다. 그리고 나머지 5%에서 대부분은 이 모든 가능성이 거의 사용되지 않습니다. 물론 그것들은 즐겁고 유용할 수도 있지만 제 생각에는 이러한 모든 개선 사항이 크게 필요하지 않습니다.
이 적은 수의 사람들이 모두가 사용할 라이브러리를 작성할 수 있습니다.
14. 함수 인수가 상수 참조인 경우 임시 개체 전달을 허용합니다.
template < typename Type > struct complex { Type Re; Type Im; complex() : Re(), Im(){} complex( Type re, Type im ) : Re(re), Im(im){} }; template < typename Type > void Func( const Type& val ) { } void OnStart () { Func( 5.0 ); complex< double > C( 1.0 , 5.0 ); Func( C ); Func( complex< double >( 2.0 , 4.0 ) ); }
15. 키워드 친구.
일부 클래스의 경우 개인 멤버에게 특정 클래스에 대한 액세스 권한을 부여하고 싶지만 전부는 아닙니다.
template < typename Type > class Matrix; template < typename Type > class MatrixData { friend class Matrix< Type >; int mRefCount; int mRows; int mColumns; Type mArray[]; public : MatrixData(); MatrixData( int rows, int cols ); }; template < typename Type > class matrix { MatrixData< Type >* mData; public : Matrix(); Matrix( int rows, int cols ); };
16. 기본 제공 유형에 대한 생성자를 명시적으로 호출할 때 변수를 0으로 만듭니다.
이것은 템플릿에서 유용할 것입니다.
double x; // Не инициализирована double y(); // Инициализирована нулём double z = 5.0 ; // Инициализирована 5.0
나는 그런 주제를 만들기로 결정했습니다. 왜냐하면. 내 관찰에 따르면 MQL 구문의 개발은 오랫동안 정체되어 있으며 최근 몇 년 동안 언어의 개선이 눈에 띄지 않습니다. 개발자가 MQL에 대해 더 작업할 것인지는 모르겠지만 누락된 기능이 많이 있으며 그 중 일부는 매우 필요합니다.
이 스레드에서 주요 소원을 정리하기로 결정했습니다. 먼저 내 목록을 제공하고 누군가가 다른 것을 추가할 것입니다. 그리고 그 과정에서 개발자들이 연결되어 자신의 비전을 표현할 수도 있습니다. 정말 좋을 것입니다.
************
금지를 기다리세요, 경전비판은 용납되지 않습니다 :)
추신: 전 세계적인 수준은 아니지만 개선 사항이 있었습니다.
그들은 포인터조차 가지고 있지 않습니다) 더 근본적인 것이 무엇입니까)
GC 없이도 언어는 관리되지 않습니다.
Sharp에서도 안전하지 않은 모드에만 있습니다.
예, 이해합니다. 하지만 코드 기반 외에도 Freelance 및 Market도 있으며 MQ가 제품 품질에 관심을 가져야 하는 곳입니다. 그리고 언어의 품질은 개발 및 디버깅의 품질과 속도에 어떻게든 영향을 미칩니다.
그리고 백분율에 대해 그렇게 이야기한다면 MQL5는 왜 만들어졌습니까? 그들은 여전히 OOP나 다른 것이 필요하지 않은 오래된 하드코어 MQL4에 앉아 있을 것입니다. 99%의 사용자가 모든 것에 만족했습니다)
아마도 일반 프로그래머는 MQL이 여전히 열등한 언어이기 때문에 정확하게 MQL로 가지 않을 것입니다.
코드베이스는 95% 쓰레기입니다. 오랜만에 MT5의 새 버전이 나오지 않았습니다. Renat는 새 릴리스에서 전 세계적인 것을 약속한 것으로 기억합니다.
추신: 전 세계적인 수준은 아니지만 개선 사항이 있었습니다.
글쎄, 그것은 정확히 무엇이었습니까? 내가 마지막으로 기억하는 것은 동적 개체를 복사할 수 있도록 하는 암시적 복사 연산자이지만, 특히 그 이후로 많은 시간이 흘렀기 때문에 이것은 하찮은 일입니다.
나는 그런 주제를 만들기로 결정했습니다. 왜냐하면. 내 관찰에 따르면 MQL 구문의 개발은 오랫동안 정체되어 있으며 최근 몇 년 동안 언어의 개선이 눈에 띄지 않습니다. 개발자가 MQL에 대해 더 작업할 것인지는 모르겠지만 누락된 기능이 많이 있으며 그 중 일부는 매우 필요합니다.
이 스레드에서 주요 소원을 정리하기로 결정했습니다. 먼저 내 목록을 제공하고 누군가가 다른 것을 추가할 것입니다. 그리고 그 과정에서 개발자들이 연결되어 자신의 비전을 표현할 수도 있습니다. 정말 좋을 것입니다.
나는 이 목록을 중요도 순으로 배열했지만(내가 보는 대로) 개인적인 우선 순위가 아닌 순서로 배열했습니다. 저것들. 언어에 가장 기본적이고 없어서는 안 될 것들을 먼저 둡니다. 지침으로 C++ 및 C#의 기능을 사용합니다.
1. 유형 작업: typedef , decltype , auto
이것은 일반적으로 기본 기능이며 최소한 처음 두 지정자입니다. 이름을 지정하고 형식을 취하는 작업은 편의성뿐만 아니라 코드의 안정성과 유연성을 위해 생성됩니다. 모든 곳에서 다른 장소에서 사용되는 특정 유형의 변수에 대해 엄격하게 규정되어 있으면 유형을 변경해야 할 때 문제가 시작됩니다.
많은 사람들이 이미 typedef 에 익숙하지만 불행히도 이것은 여전히 함수 포인터에서만 작동하는 그루터기에 불과합니다. decltype 의 경우 잘 모르는 사람들을 위해 설명하겠습니다. 전달된 표현식의 유형을 인수로 반환하므로 일부 변수 또는 함수의 유형을 다른 유형에 따라 유연하게 설정할 수 있습니다. :
또는 typedef 사용:
C#에서는 typedef 대신 using 이 사용됩니다.
2. 네임스페이스: 네임스페이스
이 주제는 최근에 논의되었습니다. 저에게는 일반적으로 왜 아직 구현되지 않았는지 매우 이상합니다. 그것은 언어에서 필수입니다. 특히 커뮤니티 개발, 코드 기반 사용, 그룹 개발 추세를 고려할 때. 이 경우 이름을 일치시키는 문제가 매우 관련이 있습니다.
그리고 일반적으로 모든 것이 단일 공간의 하나의 힙에 버려지면 잘못된 것입니다.
3. 유형 캐스팅 연산자 , 또는 오히려 클래스의 과부하 가능성. 그것이 없으면 사용자 정의 형식은 본질적으로 열등하고 유연성이 크게 감소합니다.
일반적으로 이것은 간단하게 수행됩니다. 적절한 유형으로 생성자와 캐스팅 연산자를 오버로드하고 이 유형과 구조의 완전한 호환성을 얻습니다.
그러나 MQL에서는 대신 별도의 to_datetime() 메서드를 만들고 모든 곳에서 호출해야 합니다. 또는 편안함과 유연성을 추가하지 않는 DATETIME 및 유형에 대한 대상 함수를 오버로드합니다.
4. 다중 인터페이스 . 글쎄, 이것에 대해 이미 많은 소문과 대화가 있었지만 (3 년 전에 그들이 작업이 진행 중이라고 서비스 데스크에 썼던 것을 기억합니다), 그러나 그 과정은 어떻게 든 끌렸습니다 ... 그것이 진행되고 있다면.
5. 구조용 인터페이스 지원 . 이는 OOP와의 통합 작업에 필요합니다. 이제 종종 목발을 울타리로 묶을 필요가 있습니다.
이 기능은 두 가지 방법으로 구현할 수 있습니다. C#에서와 같이 - 패킹/언패킹(boxing) 을 통해 또는 보다 유연한 옵션 - 구조가 있는 동적 개체의 디스크립터에 연결된 구조에 대한 동적 디스크립터를 생성하여 위치 - 더 효율적일 뿐만 아니라 실제로 구조 및 기타 데이터 유형에 대한 포인터를 생성할 수 있어 유연성이 크게 향상됩니다.
6. 구조 생성자가 그러한 유형을 지원하는 경우 한 유형에서 다른 유형으로 즉석에서 유연한 변환을 허용하는 작은 구조(위의 예와 동일한 DATETIME)를 전달할 때 관련이 있는 값으로 구조를 전달하는 기능. 참조로 전달할 때는 그러한 유연성이 없습니다. 구조에 대한 인터페이스가 구현되더라도 관련성이 떨어집니다.
7. 템플릿의 숫자 매개변수를 설정하는 기능:
두 번째 예의 경우 MQL4에서 없이도 할 수 있습니다. 함수는 모든 차원의 배열을 허용합니다. 그러나 MQL5에서는 다차원 배열로 모든 것이 훨씬 더 복잡합니다.
글쎄, 그래서 작은 것들에 대해 :
9. 포인터 배열을 기본 포인터 배열로 캐스팅(명시적 또는 암시적으로)하는 기능 . 이전 빌드에서는 이것이 효과가 있었고 매우 편리했습니다.
이제 어레이를 새 어레이로 다시 복사한 다음 다시 비용을 낭비해야 합니다.
12. 포인터를 숫자 값으로 명시적으로 캐스팅하는 기능.
이렇게 하면 이진 검색이나 해시 테이블 생성을 통해 원하는 포인터를 빠르게 찾기 위해 값을 기준으로 포인터 배열을 정렬할 수 있습니다. 이제 전체 아이디어를 죽이는 텍스트 형식으로 변환해야만 숫자 값을 얻을 수 있습니다.
13. 템플릿 기본값 설정