再见，机器人--你好，沼泽地。 - 页 10

新评论
 
borilunad:

尊敬的女士们、先生们潘萨!为什么不使用SRC 按钮来输入密码？你有什么疑问吗？

祝您好运!

嗨，博里鲁纳德!
想问一下，你从哪里得到SRC的？
潘萨
 
 
pansa:
Hi borilunad！ ，想问问你从哪里得到SRC？ pansa


当你回复时，往上看一点，在视频的左边，你会看到一个SRC 按钮!点击它，它将打开一个周长，以粘贴代码!好运!

顺便说一下，非常准确和 "雄辩 "地指出了康斯坦丁的SRC 位置

 
7Konstantin7:

嗨，Konstantin，你在手工交易方面进展如何？我猜你已经成为一名刺客了，对吗？
 
Renat:

我明白，有些人在熟悉了静态分析器之后会歇斯底里。

但只有在这之后，才有人明白编译器必须（确切地说必须）做什么。现在是2014年，普通的编译器在质量控制方面至少落后10年，只专注于优化。

供参考：英特尔C++编译器仍然没有从它的缺陷中恢复过来--它在我们的项目上不断产生内部编译器错误。也就是说，它不会咀嚼大项目并产生自己的错误。而关于其非凡的优化特性的神话也已经过时了--所有其他的优化水平都大大收紧了。

在C++这样一种危险的自杀式语言中，有许多键和编译开关，因此自信的程序员可以编译大量古老的、不知道从哪里抄来的代码，而不会紧张得抽筋 :)

一个编译器，首先必须进行编译，而不是分析，而且它应该编译，最好是有良好的质量，这通常也要求它具有灵活性和可定制性。

将静态代码分析器 和其他类似的工具创建为独立的实用程序是合理的，与编译器对其功能的实现相比，它们的功能发挥得更好。

我们有理由理解，静态代码分析和其他类似的有用的东西只有助于发现少数错误，即那些与程序员的不注意和低技能有关的错误。设计错误、逻辑错误、"忘记实现 "类型的错误以及其他类似的错误都不能被静态分析器或类似工具检测出来。这正是我们在MT4中可以看到的情况。

在当时，微软的编译器也很容易因为内部错误而被 "破坏"。较新的版本也更稳定，包括英特尔的。至于优化，你通常不需要什么特别的东西--只需要好的、扎实的优化--而英特尔的优化是基于对其自身处理器的架构和机制的深刻理解。如果认为对英特尔来说会比对其他人更糟糕，那就太奇怪了。

编译开关主要是为了灵活地调整编译器，使之符合项目的（部分）要求，而使之更容易编译古代代码的选项只是一个额外的奖励。

如果C++语言是如此危险和具有自杀性，那么为什么早期基于C语言的MQL4被 "改进 "为MQL4++和MQL5，完全基于C++？

 

simpleton:

我们有理由理解，静态代码分析和其他类似的有用工具只有助于发现少数错误，即那些与程序员的不注意和低技能有关的错误。设计错误、逻辑错误、"忘记实现 "类型的错误以及其他类似的错误都不能被静态分析器或类似工具检测出来。这正是你在MT4中可以看到的情况。

测试环境在软件产品中被广泛使用，用于软件芯片设计的功能验证，对代码质量的要求非常高。此外，功能外壳是开发任何芯片设计 的代码的一个组成部分。另一方面，许多程序员在编写通常的软件项目时甚至不知道这些功能测试，这是因为从头开始编写这些测试可能比编写项目本身花费更多的时间，只有在要求编写高质量的代码或同一项目有许多版本时才有理由。另一方面，巧妙地编写测试环境可以大大减少调试和代码验证的时间。

静态分析也被使用，但只是作为一种非常肤浅和初级的语法检查。

 

憨厚的人，真是一派胡言。

当你达到全面质量控制的水平时，你才会理解它。同时，你仍然停留在个人自恋的程序员的认知水平上，并将继续认为 "不控制我是合理的，让控制由独立的永不运行的实用程序来进行"。

与C++不同，由于拒绝原始链接，MQL是绝对安全的（如果没有退出dll的话），而且一般来说--它是一种可管理的语言。

 
Renat:

与C++不同，MQL一点都不危险

C++编译器本身的故障是相当罕见的。

MQL的编译器故障现在是经常发生的（我看到MQL的内部编译器错误比VS的要多得多）。

如今，MQL代码执行故障也是一个反复出现的现象。

 

故障正在被处理，但我们同时也在增加和改进很多东西。

周五会有一个MT4版本，在执行速度 和测试方面有明显的改进。

 
雷纳特，我想要：命名空间、在宏中胶合、头文件的多重包含、undef、union。一切都像在C++中一样。
1...345678910111213141516
新评论