MQL 언어의 구문에 대한 희망 - 페이지 10

새 코멘트
 
이것저것 다 읽어보니 재미있네요. 클래스, "포인터" 및 구조를 MQL에 도입하기로 결정했을 때 옛 동지들의 외침을 기억합니다. 그래서 그들은 "당신은 MQL을 죽였습니다! 이제 프로만이 그것에 쓸 수 있습니다 ..."라고 썼습니다. 이제 다른 쪽에서 비명을 지르십시오. 본격적인 C ++를 제공하십시오. 그렇지 않으면 메가 시스템을 코딩하는 것이 불가능합니다. 하지만 누가 너희들을 막고 있니? C++를 가지고 가십시오. MQL은 약간 다른 이야기이며, warm과 long을 혼동하는 것은 다소 순진합니다.
 

C ++에 대해 말하는 것이 무엇입니까 ... 글쎄, 당신은 C ++를 좋아하지 않으므로 C #을 사용하십시오. 나는 원래 게시물에서 그것을 구체적으로 언급했고 토론에서 더 강조했습니다. 제안된 내용의 대부분은 두 언어 모두에 적용됩니다.

따라서 두 가지 중 하나가 있습니다. 원칙적으로 진보에 반대하거나 원망합니다. 두 가지 옵션 모두 가능하지만

 
Alexey Navoykov :

...

MetaTrader는 좋은 터미널입니다. 그러나 불행하게도 사용자의 대다수는 광적인 광기와 도박꾼으로 남아 있습니다. MQ는 지적 거래 틈새 시장으로 이동하기 위해 많은 노력을 기울였지만 제대로 되지 않았습니다. 도박꾼의 경우 차트에 여러 색상의 "TrendLaser"를 넣어 MT4를 "찔러" 충분합니다. 그들은 구조, 클래스, decltype이 있는 프릴 등에는 관심이 없습니다. 하지만 "가느다란 양털이라도 양털 다발"이 있는 경우 - 그것이 우리가 사는 방식입니다. 따라서 현재 상황에서는 MQL5 언어 도구를 개발하는 것이 경제적으로 불가능합니다. 예를 들어 MT5에 잠금을 도입하거나 CopyRates 대신 Open[0]을 표시하는 것과 같이 군중을 노리는 것이 좋습니다.

 

사실 좀 이상해요. 처음에 MQL은 거래 전략을 작성하기 위한 응용 언어로 만들어졌습니다. 따라서 C ++에 있는 모든 것이 추가되지 않았습니다. 그리고 아마 좋을 것입니다. 그러나 시간이 지남에 따라 알고리즘 거래의 작업은 더욱 복잡해졌으며 사람들은 언어 추가를 찾고 기다리고 있습니다. 따라서 의도적으로 추가되지 않은 모든 것을 넣는 경향이 있습니다. 동시에 규칙의 수와 언어의 복잡성 수준이 증가하여 장벽이 됩니다. 그러나 그들이 그것을 극복할 준비가 되어 있다면 막을 수 없습니다.

저에게 개발이란 무엇보다도 아이디어를 구현하는 가장 정확하고 간단한 방법을 찾는 것입니다. 이를 바탕으로 기존 언어의 기능은 충분하지만 전문 프로그래머는 많은 규칙과 많은 구문에 대해 향수를 느낍니다. )) 글쎄, 그것이 그들에게 영감을 준다면 왜 안 될까요?

 
Реter Konow :

동시에 규칙의 수와 언어의 복잡성 수준이 증가하여 장벽이 됩니다.

그렇다면 왜 장벽인가? 새로운 기능을 추가한다고 해서 기존 기능을 사용할 수 있는 것은 아닙니다. 대개. 따라서 아무도 이러한 "복잡성"을 사용하도록 강요하지 않습니다.

물론 정착된 규칙이 갑자기 C++를 만족시키기 위해 무자비하게 다시 그려지는 시기도 있었지만, 당시는 언어의 급속한 발전이었습니다. 이제 거의 모든 것이 이미 존재하며 약간의 개선이 있습니다.

 

그건 그렇고, 지난 1년 반 동안 개인적으로 개선의 부족뿐만 아니라 언어 능력의 축소도 느끼고 있습니다. 가장 기능적이고 안정적인 빌드는 2017년 3월 14일자 1554입니다. 그 후 내부에 일종의 기본적인 변경이 있었고 많은 버그가 있는 문제가 있는 빌드가 시작되었으며 그 중 일부는 현재까지 수정되지 않았습니다. 사실, 일부 오래된 버그가 수정되었습니다. 일반적으로 버그 수준의 측면에서 현재 빌드가 약간 승리합니다. 하지만 기능면에서는...

예를 들어, 배열을 기본 유형으로 캐스팅하는 기능을 줄이는 것에 대해 이미 썼습니다. 또 다른 축소는 단순한 구조 를 서로 가져 오는 것을 금지하는 것입니다. 예, 그 대가로 유니온을 제공했지만 캐스팅이 제공한 가능성은 다루지 않아 표준 기능의 단점을 보완할 수 있었습니다. 즉, 구조의 다형성을 생성할 수 있습니다. MQL의 구조에 대한 인터페이스가 없기 때문에(이미 쓴) 이 솔루션은 좋은 대안이었습니다. 이와 같이:

 template < typename T>
struct IValueable
{ 
   double Value() const { return ((T) this ).GetValue(); }
 protected :
  IValueable() { }
 private :
   static void Check_IValueable() { T::Check_IValueable(); }   // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
   double _value;

  A( double value) { _value=value; }
  
   double GetValue() const { return _value; }
};


void Func(IValueable<A> &a) { Print (a.Value()); }


void OnStart ()
{
  A a( 10 );
  Func(a);
}
 
Alexey Navoykov :

그렇다면 왜 장벽인가? 새로운 기능을 추가한다고 해서 이전 기능의 사용이 금지되는 것은 아닙니다. 대개. 따라서 아무도 이러한 "복잡성"을 사용하도록 강요하지 않습니다.

물론 정착된 규칙이 갑자기 C++를 만족시키기 위해 무자비하게 다시 그려지는 시기도 있었지만, 당시는 언어의 급속한 발전이었습니다. 이제 거의 모든 것이 이미 존재하며 약간의 개선 사항이 있습니다.

내 말은, 스스로 새로운 규칙과 구문을 사용하려는 사람들을 위한 장벽입니다. 그들은 프로그램을 더 오래 작성하고 더 오래 이해해야 합니다. 이것이 그들의 프로그램을 더 효과적으로 만들 것인가? - 사실이 아닙니다. 그들은 더 많은 문제를 해결할 수 있습니까? - 사실이 아닙니다.

포럼에서 나는 모든 사람이 "산"의 코드로 해결한 문제에 대한 매우 간단한 솔루션을 제안했습니다. 작고 빨랐습니다. 그러나 모두가 그것을 좋아하지 않았습니다. 그들은 사랑하는 것이 없었습니다. 모든 템플릿 < typename T> 및 void Func(IValueable<A> &a)

이 모든 것을 사용하도록 요청받았습니다. "왜?"라고 물었을 때 아무도 명확하게 설명하지 않았습니다.


추신 : 내가 얻은 가장 명확한 설명은 "당신의 코드는 추악합니다"입니다. 그리고 다시: "당신은 개념적 힘을 이해하지 못합니다." 하지만 저는 개발자입니다. 예쁜 코드가 아니라 예쁜 솔루션이 필요합니다.

 
Alexey Navoykov :

간단한 구조 를 서로 가져 오는 것을 금지합니다. 예, 그 대가로 유니온을 제공했지만 캐스팅이 제공한 가능성은 다루지 않아 표준 기능의 단점을 보완할 수 있었습니다. 즉, 구조의 다형성을 생성할 수 있습니다. MQL의 구조에 대한 인터페이스가 없기 때문에(이미 쓴) 이 솔루션은 좋은 대안이었습니다. 이와 같이:

그것은 컴파일

 #include <TypeToBytes.mqh>

template < typename T>
struct IValueable
{ 
   uchar Tmp;
   double Value() const { return (_C(T, this )).GetValue(); }
 protected :
//  IValueable() { }
 private :
   static void Check_IValueable() { T::Check_IValueable(); }   // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
   double _value;

//  A(double value) { _value=value; }
   void Set( double value ) { _value=value; }
  
   double GetValue() const { return _value; }
};

그러나 결과는 당연히 다릅니다.

1...345678910
새 코멘트