OOP与程序化编程 - 页 24

新评论
 
Dmitry Fedoseev:

1.有一个标准。主要的标准是操作速度。

代码可见性是错误的标准。


每个人都要紧急切换到ambler.....，但快速....。诚然，快速是指整个项目 的适当组织或个别功能的速度。

 
Alexandr Andreev:

每个人都要紧急行动起来，到ambler.....，但快速....。事实上，快是指整个项目的速度或单个功能的速度。

汇编程序+DLL
 
Alexandr Andreev:

每个人都要紧急行动起来，到ambler.....，但快速....。真正快速的是整个项目的适当组织或个别功能的速度。


不，继续通过***进行编码。

 
George Merts:

嗯，我不同意。

代码清晰是一件非常重要的事情，因为清晰的代码更容易维护和修改。

这是正确的--我写了一个赤裸裸的函数，然后我实际上 "混淆 "了它，使它变得不可见和不可理解。这是个被迫的决定。在这种情况下，对我来说，使整个班级透明化更为重要。我牺牲了一个相当微不足道的功能的清晰性。当然，我可以把这个函数的主体放在.mq5文件中，但我认为接口不应该被分成两个文件，应该在头文件.mqh中完全描述。

速度也是需要记住的，但我认为我们不应该追求 "不惜一切代价的速度"。必须有一个合理的充分性。


对你来说，可能也是第3点

 

我已经做了很长时间的编程。自MT3发布以来。

从那时起，我觉得在mql4上用程序化风格写作更舒服。我没有1001行的EA。此外，我只有一些函数存储在库中。

而在MQL5中，我使用标准库。这是件很方便的事。

但应进行性能优化，以避免调用越来越多的重型函数。最近，我一直在将一个EA从Mql4修改为MQL5。我使用了这里介绍的库，花了半天时间才搞清楚所有的功能，而且还能用，但优化的速度很慢。我已将指标削减到2条，一切都开始飞起来了。

结论很简单。每个人都可以用任何风格来写作。MQL并不是一种真正需要代码优化的语言，以便通过程序化编程获得几毫秒的时间。逻辑性的任务更重要。它们的实施方式对速度几乎没有影响。

 
Dmitiry Ananiev:

...

结论很简单。每个人都可以用任何风格来写作。MQL并不是一种真正的语言，它需要对代码进行优化，这样就可以通过使用程序化编程获得几毫秒 的时间。逻辑性的任务更重要。它们的实施方式对速度几乎没有影响。


因此，柔和地不露声色地让人知道，是程序性编程提供了高性能。三天来，我一直在向你展示一个只有通过OOP才能解决的问题，没有多余的刹车。

OOP允许我们从代码的其他部分屏蔽变量集，这使得我们在类内部进行计算时可以避免向方法传递参数，这对速度来说是一个重要因素。即使你用程序化的方式来做，你也不得不创建大量的全局变量，结果是代码的可读性不可能很低。

 
Dmitry Fedoseev:

就这样被轻轻地放下了，是程序化编程提供了高性能。三天来，我一直在这里展示一个只有OOP才能解决的问题，没有不必要的刹车。

OOP允许我们从代码的其他部分屏蔽变量集，这使得我们在类内部进行计算时可以避免向方法传递参数，这对速度来说是一个重要因素。即使你以程序化的方式来做，你也不得不创建大量的全局变量，结果是代码的可读性不可能很低。

程序化风格的收益可以忽略不计，因为在Expert Advisors中，代码是随着每一个tick开始的。而且，在两个脉冲之间可能有几百甚至几十毫秒的间隔。我从来没有理会过指标。我没有发现任何真正的指标利润。
然而，对于大型项目来说，使用OOP可能更方便。我自己更喜欢使用结构，如果我必须要保存一些东西的话。
这样，对数据的访问就安排得更加清楚，下拉菜单的使用也非常方便。如果你用数组代替结构，往往会产生混乱，数组的数量也会增加。

在上一篇文章中，我正是把重点放在了调用重型函数上。例如，某种不需要在每个tick上调用的循环回路。而且你也不必在每个新酒吧都这样做。
这就是可以提高真正性能增益的地方。

 

是的，这是一个有趣的辩论：挖掘机与铲子。

我想如果你想种树，用铲子会更好。但如果你想挖一个洞，反铲可能更好。

[删除]  
Nikolai Semko:

是的，这是一个有趣的辩论：挖掘机与铲子。

我想如果你想种树，用铲子会更好。但如果你想挖一个洞，反铲可能更好。

只掌握了铁锹的人也会使用铁锹
 
Nikolai Semko:

是的，这是一个有趣的辩论：挖掘机与铲子。

我想如果你想种树，用铲子会更好。但如果你想挖一个洞，反铲可能更好。

目前还不清楚为什么这么多当地的园丁都成了深信不疑的挖掘机，为一棵树开了一条沟））。
1...171819202122232425262728293031...48
新评论