C-4: Вот тут подумалось что при объединении двух языков абсолютно необходимы условные директивы компиляции типа #ifdef - это бы существенно упростило бы унификацию кодов между двумя платформами, и плотформозависимый API определялся на этапе компиляции.
寻觅了又寻觅。找不到一个...
我并没有这样说。
调试器还没有被想到，也就是说，不知道会不会被想到，但既然没有被想到，就意味着 "还不会"。
http://forum.mql4.com/ru/56881/page4#820225
当你在琢磨升级的技术细节时，一个重要的细节被你忽略了--MetaTrader 4将有Marketplace。鉴于4的普遍性，你可以估计一个机器人/指标开发者在700万交易者的联合市场上能赚多少钱。MQL5市场的结果 可以作为进行假设的基础，并更好地了解什么类型的软件在交易者中更受欢迎。
还没有注册为开发者吗？
C-4:
Вот тут подумалось что при объединении двух языков абсолютно необходимы условные директивы компиляции типа #ifdef - это бы существенно упростило бы унификацию кодов между двумя платформами, и плотформозависимый API определялся на этапе компиляции.
是的，那就好了。
到目前为止，我使用了一种弯曲的替代方法，如
#define _DEBUG_OR_RELEASE_(DEBUG, RELEASE) DEBUG
但如果有了#ifdef，它就会灵活得多。
当我们正在弄清楚升级的技术细节时，我们已经失去了一个重要的细节 - MetaTrader 4将拥有市场。鉴于4的普遍性，你可以估计一个机器人/指标开发者在700万交易者的联合市场上可以赚多少钱。MQL5市场的结果 可以作为进行假设的基础，并更好地了解什么类型的软件在交易者中更受欢迎。
还没有注册为开发者吗？
那么我们就来找你了 :)
事实上，每个人都注意到了这一点，为了不把他们吓跑，大家都在默默地欢呼：)
我不同意hrenfx的 所有论点，然而，我个人选择MT5完全是为了OOP和标准库。
我真的希望在MT4++中引入OOP时，尽可能多地保留标准库类的接口（最好是除CTrade、CPositionInfo交易类外的所有接口，直接与净额结算相关）。
顺便说一下，他说的同样是关于自定义历史 的旧电子表格--在MT5中仍然可以模仿--只要利用这些功能就可以了。
我想知道如何在MT5测试器中进行模拟（即在你自己的历史上测试）？
它在哪里说的？
我想知道如何在MT5测试器中模拟这种情况（即在你的历史上测试）？
它在哪里说的？
它没有在任何地方这样说。这是我的想法。我在这个论坛上发起了一个话题，但没有人支持它，所以我意识到没有人对它感兴趣。
如果专家顾问只使用标准库类来工作，而不使用直接访问服务器的功能，那么仿真任务就是编写标准库类的派生类，这些派生类将不适用于服务器，并使用它们自己的、内部变量。
之后，专家顾问收到的不是原始的标准库类，而是派生类，它们不是访问服务器，而是向专家顾问传递它们自己的内部计算结果。专家顾问并没有注意到这种转换--它并不关心用什么来工作--无论是真实数据还是历史数据。
就我自己而言，我已经写了一个历史数据和类的存储，即时间序列的继承者（如SOPrep、CHigh等），它可以从服务器返回EA的真实数据和存储的历史数据。以后，我将把交易类写成标准库类的后代，可以作为真实服务器的交易的 "包装"，并根据历史数据进行虚拟交易。同样，专家顾问不会意识到这种替换。
所有这些都是可能的。当然，还有很多工作要做。
它没有在任何地方这样说。这是我的主意。我在论坛上开了一个主题，但没有人支持，我意识到没有人对它感兴趣。
如果专家顾问只使用标准库类来工作，而不使用直接访问服务器的功能，那么仿真任务就是编写标准库类的派生类，这些派生类将不适用于服务器，并使用它们自己的、内部变量。
之后，专家顾问收到的不是原始的标准库类，而是派生类，它们不是访问服务器，而是向专家顾问传递它们自己的内部计算结果。专家顾问并没有注意到这种转换--它并不关心用什么来工作--无论是真实数据还是历史数据。
就我自己而言，我已经写了一个历史数据和类的存储，即时间序列的继承者（如SOPrep、CHigh等），它可以从服务器返回EA的真实数据和存储的历史数据。以后，我将把交易类写成标准库类的后代，可以作为真实服务器的交易的 "包装"，并根据历史数据进行虚拟交易。同样，专家顾问不会意识到这种替换。
所有这些都是可能的。当然，有很多工作。
如果你写一个指标，从文件中读取数据（自定义历史），覆盖数据接收的标准功能（包括报价和市场环境），使用上下文的定义，你就会很高兴。
我不同意你对标准库的推崇，它是一个巨大的怪物，以普遍性为借口，只为实例和在向导中创建专家顾问而创造。
虽然它是为了什么而写的，但它很好地履行了自己的职责。
编写一个从文件中读取数据的指标（自定义历史），覆盖数据采集的标准功能（包括报价和市场环境），使用合约的定义，你就会很高兴。
这正是我所做的。我已经写好了类，可以把历史记录传给自定义EA（而不是来自服务器的真实记录）。 但EA不能直接使用终端的功能来完全实现我的想法。说，同样的OrderSend()。它应该只通过一个 "包装器 "来工作，这个包装器的作用可以由标准库 很好地完成。我们编写派生类，把它们输入EA，然后就可以了--它现在可以在历史数据上工作。 如果EA将直接使用终端的功能，它将无法使用历史数据。
我不同意你对标准库的推崇，这是一个巨大的怪物，它假装是通用的，只为例子和在向导中创建专家顾问而创建。
但它很好地实现了自己的目的。
好吧，也许这是我对MFC库长期工作的影响，我对MFC库非常满意，我发现它有很多相似之处。我相信标准库的开发者对MFC也相当熟悉。
标准库的主要优势是对OOP思想的良好支持，它允许向专家顾问传递一个自定义的历史，这样它就可以正常工作，而不需要进行任何修改。
我可以问问你为什么不喜欢标准库吗（好吧，除了明显的缺点--"懒得学"）？
当我们在调查升级的技术细节时，我们失去了一个重要的细节 - 市场将出现在MetaTrader 4。鉴于IV的普遍性，我们可以估计一个机器人/指标开发者在700万交易者的联合市场中可以赚取多少钱。MQL5市场的结果 可以作为进行假设的基础，并更好地了解什么类型的软件在交易者中更受欢迎。
你已经注册为开发者了吗？
既然我们已经触及了市场，我想听听大家对一个问题的看法......
根据MQL5的理念，指标应该计数，EA应该交易。
但市场出售的是现成的解决方案，正如他们所说的那样，都是一体的。
也许应该改进编译器，以便将指标作为资源储存在专家顾问系统中？
否则，我们必须将该指标的代码转移到专家顾问中，在那里它没有合适的环境。同样，"逐个指标 "的计划是将代码转移到专家顾问的整个史诗。