I have always asked this but I have never received a really good answer; I think that almost any programmer before even writing the first "Hello World" had encountered a phrase like "macro should never be used", "macro are evil" and so on, my question is: why? With the new C++11 is there a real alternative after so many years? The easy...
当然可以!但这会有多难看?
在没有宏的 TypeToBytes 库中,这不仅可怕,而且不方便。也就是说,这个库可以直接扔掉。
我认为这与语言能力有关。当我不知道/不理解 OOP 时,我不会使用它。一切都变了。
这和熟练程度有什么关系,我们说的是用法,而这是代码调试,使用宏比较困难...
宏用于不需要调试的地方--干净的代码中。
编译器收到的总是没有宏的简洁代码。如果你能得到这些干净的代码(保存到文件中),你就能看到它。
开发人员可以做到,但他们不太可能做到(C++ 中的 -E 开关)。
宏用于不需要调试的地方--干净的代码。
编译器总能接收到不含宏的干净代码。如果你能得到这些干净的代码(保存到文件中),你就能看到它。
开发人员可以做到,但他们不太可能做到(C++ 中的 -E 键)。
你是真的不理解我的意思,还是像通常与开发人员交流时那样固执地捍卫自己的真实观点?我在上面写道,我坚持在这一领域远远领先于我们的程序员的意见,我还特别写了两个问题--一个是与阅读代码不便有关的小问题,第二个是调试代码时的严重问题,如果您真的不明白,那么请用调试器查看使用宏的代码....。
这就是这个不必要的 jalivar 的结尾。
你是真的不理解我的意思,还是像通常与开发人员交流时那样固执地捍卫自己的真实观点?我在上面写道,我坚持在这一领域远远领先于我们的程序员的观点,我还具体写了两个问题--一个是与阅读代码不便有关的小问题,第二个是调试代码时的严重问题,如果您真的不理解,那么请用调试器查看使用宏的代码....。
我完全尊重你的观点,论据也很清楚。遗憾的是,metaeditor.exe 没有 -E 开关。而它可以创建干净的代码,方便阅读和调试。
当我在写一些非同小可的东西时,我写出了极其糟糕的代码。我意识到首先要做的是让代码正常工作(开发人员自己的错误也是在这个阶段被发现的)。如何从架构上更好地解决这个问题并不总是显而易见的。由于在工作开始时很少意识到某些要点,因此会出现严重的重新设计。调试之后,还要将错误的代码构建成更合理的代码。可能会创建新的函数和宏。这样做的目的是使一切都合乎逻辑,并删除任何重复的逻辑/代码。这样,代码就会变得美观、简洁和合乎逻辑。
调试真正困难的地方在于模板。模板是一种棘手的预处理器。而且调试起来非常困难。例如,在编写 TypeToBytes 超级模板时,调试几乎是不可能的。也不可能写出错误的代码,然后再把它梳理出来。你必须把所有东西都记在脑子里,并清楚地意识到发生了什么、在哪里。这是一种自我检查,以求理解。
这就是为什么在有些情况下,你根本离不开模板和预处理器。而纯粹代码的支持者们可能不会想到这些情况。
价格比较
作者:fxsaber
有趣。
为什么您的 EPSILON 被定义为这个值?
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий Альтернативные реализации стандинных
Альтернативные реализации стандартных функций/подходов
fxsaber, 2016.09.02 10:58
关于交易、自动交易系统和测试交易策略的论坛
标准功能/方法的替代实施
fxsaber, 2016.09.02 10:58 AM.
现在工作始终正常,但速度只比原来快 10为什么预处理器宏是邪恶的?
为什么预处理器宏是邪恶的?
邪恶的不是宏,而是对宏的盲目使用。
罪恶不在于宏,而在于对宏的盲目使用。
这就是问题所在,宏并不能避免滥用。
宏是在没有类、模板或常量时出现的。
现在,宏的使用毫无意义。