对MQL语法的建议 - 页 10

新评论
 
读到这些很有趣。我记得当他们决定在MQL中引入类、"指针 "和结构时，老同志们的哭声。他们曾经写道："你已经杀死了MQL!现在只有专业人士才能在其中写作......"。- 和其他胡言乱语。现在他们在另一边大喊：让我拥有一个全功能的C++，而巨型系统却无法编码。但谁能阻止你们所有人这样做呢？拿着C++，继续走你的路。MQL是另一个故事，把温暖和寒冷混在一起是天真的。
 

如果你不喜欢C++，就选C#。 我在我的原帖中特别提到了这一点，并在讨论中进一步强调了这一点。 所建议的大部分内容涉及这两种语言。

因此，有两种情况：要么你在原则上反对进步，要么只是埋怨。 虽然这两种变体也是可能的

 
Alexey Navoykov:

...

MetaTrader是一个好的终端。但不幸的是，其绝大多数用户仍然是失败者和赌徒。MQ为进入智能交易领域做出了非常大的努力，但它并没有成功。赌徒们只需要在图表上用一些多色的 "TrendLaser "来 "戳 "MT4。他们不关心结构、阶级、有decltype的专业等等。但 "瘦羊的飞毛腿"--这就是我们的生活方式。因此，在这种情况下，开发MQL5的语言学特征在经济上是不可行的。但是，与人群调情是合理的，例如在MT5中引入锁，或者用Open[0]代替CopyRates。

 

实际上，这有点奇怪。最初，MQL是作为一种编写交易策略的应用语言而创建的。因此，它没有包含C++的一切。但随着时间的推移，算法交易中的任务变得更加复杂，人们寻找并等待对语言的补充。因此，他们往往把一切有意不加的东西都放在里面。这样一来，规则的数量和语言的复杂程度就会增加，成为自己的障碍。但是，如果他们愿意克服这些问题，就没有人能够阻止他们。

对我来说，发展首先是要找到正确和最简单的方式来实现一种思想。因此，旧语言的能力已经足够好了，但专业的程序员对那一堆规则和成堆的语法感到怀念。))好吧，如果这能给他们带来灵感--为什么不呢？

 
Реter Konow:

同时，规则的数量和语言的复杂程度将增加，成为他们的障碍。

为什么有障碍？ 增加新功能并不妨碍他们使用旧功能。通常情况下，没有人被迫使用这些 "复杂"。

虽然肯定有一些时期，为了C++的利益，既定的规则突然被无情地改变了，但那是它快速发展的时期。 现在，这种语言几乎拥有了一切，只剩下小的修改。

 

顺便说一下，我个人觉得在过去的一年半里，不仅缺乏改进，而且还减少了语言功能。 功能最强、最稳定的版本是1554，日期是2017年3月14日。在那之后，对内部进行了一些彻底的重新设计，出现了很多有问题的版本，其中一些至今没有被修复。 然而，一些旧的错误被修复了。 总的来说，当前版本的错误水平可能略胜一筹。 但关于功能...

例如，我已经写过关于削减将数组投向基本类型的可能性。 另一个削减是禁止将简单的结构 投向对方。 是的，它们被替换成了单位，但它们并没有涵盖投向所带来的可能性，而投向可以弥补常规功能的缺点。鉴于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)

有人提出让我全部使用它们。当我问 "为什么？"没有人解释清楚。


P.S. 我得到的最清楚的解释是："你的代码太丑了"。还有一件事："你不了解概念性的力量"。但我是一个开发者。我需要一个漂亮的解决方案，而不是漂亮的代码。

 
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
新评论