巴解组织的间接费用 - 页 2 1234567 新评论 Alexey Volchanskiy 2017.07.06 09:58 #11 Andrei:当然,漂亮的OOP必须用资源和大量的调试时间来支付。OOP只有作为一个方便的文本包装器或在运行时初始化中的最小用途才有意义......实际上,OOP 只是微软的一个营销手段,目的是增加程序员的工作时间成本,刺激他们购买更先进的设备。而且他们自己也不是傻瓜,用C语言和汇编编写所有的软件。真是一派胡言。大家都知道MS的程序员是直接用机器码写的每个程序员的桌子上都有一本写有处理器机器代码的书,他们只是把代码刻录在打孔卡上。比尔-盖茨可以在他的头脑中编译一个操作系统)。 Andrei01 2017.07.06 10:00 #12 Alexey Volchanskiy: 真是一派胡言。 你对你所说的实质内容有任何有意义的争论吗? Andrei01 2017.07.06 10:25 #13 Alexey Volchanskiy: 大家都知道,MS程序员直接用机器代码编写你的丑话说得不太清楚,众所周知,汇编语言的插入是用来提高代码性能的...我可以推测,OOP在终端中的应用是最少的,或者根本没有,因为没有像dotnet那样的大型外部库,很难得到这样紧凑的文件...... Georgiy Merts 2017.07.06 10:29 #14 Andrei: 你对所讲的实质内容有什么有意义的争论吗?检查。阿列克谢确实只是情绪化的反应。而在本质上,反对意见如下。当你需要支持一些复杂的代码时,OOP是非常有用的。 当然,将所有的OOP技巧应用于一个指标MA是没有意义的。尽管在编写基本的类时--即使是为MA--OOP-方法至少也和通常的程序性方法一样好。OOP的主要优势在发达的对象结构的支持下显现出来。当封装确保没有必要每次都了解重载函数的所有细微差别时。当它基于多态性时,代码的重用性 会变得更高。 OOP的本质更接近于现实世界,任何对象都与它的属性有关,并有一定的与环境互动的规则。 关于 "增加的工作时间成本"--这不是真的。 当然,当以OOP风格设计一个系统时,需要比面向过程的方法多一点工作。然而,这些额外的费用被维护和修改书面代码的便利性所补偿。 就个人而言,我写的是非常小的 "膝写 "指标,没有任何对象。然而,当需要更多的东西(至少是跨平台的)时--我总是使用OOP风格和对象库的现有做法。 Alexey Volchanskiy 2017.07.06 10:35 #15 Andrei:你的小丑行为不太清楚,我们知道,汇编语言的插入是用来提高代码性能的...我可以假设终端使用最少或没有OOP,因为没有像dotnet那样巨大的外部库,很难得到这样紧凑的文件...... 现代编译器的优化效果比一般甚至优秀的程序员好很多倍。就像你从上个世纪出现一样。你说的普通代码中的插入物是什么意思?驱动程序是的,他们使用assebler,但不是因为性能,它只是更容易与硬件工作.., Andrei01 2017.07.06 10:39 #16 George Merts:1.OOP - 当你需要支持某种复杂的代码时,它有很大的帮助。 2.当然,将所有的OOP技巧应用于指标-MA是没有意义的。虽然,当基本的类被写出来时--即使是为MA--它仍然是OOP-方法,至少,不比通常的程序性方法差。3.OOP的主要优势在发达的对象结构的支持下显现出来。 1.例如:?朗朗上口的口号是好的,但不清楚它们的具体含义......2.已经有人说过,作为一个文本封装器,OOP是好的,但那是因为它在程序化编程中还没有得到完善。3.为什么我们需要倍增这些 "先进的结构"?这对代码的性能是有破坏性的,而且不确定是否能更容易和更快地抓住其中的错误。 Andrei01 2017.07.06 10:43 #17 Alexey Volchanskiy: 现代编译器的优化效果比一般甚至优秀的程序员好很多倍。 也许一些简单琐碎的事情可以,但只是因为人们坐下来手动写了算法,但如果是一些非标准的东西,那就远远不能确定了,特别是如果在那里发现了OOPesheh功能。 Andrei01 2017.07.06 10:46 #18 Alexey Volchanskiy: 在驱动程序中,是的,他们使用assebler,但不是因为速度,它只是更容易与硬件合作..,好吧,人们并不愚蠢--为什么他们会想要一些复杂的、令人困惑的、也是缓慢的东西呢? Sergey Dzyublik 2017.07.06 11:16 #19 巨魔,走开,不喜欢它,就不要用它。 Georgiy Merts 2017.07.06 11:26 #20 Andrei:比如说呢?朗朗上口的口号很好,但很难理解我们到底在说什么......3。2.已经有人说过,作为一个文本封装器,OOP是好的,但那是因为它还没有在过程性编程中被提上日程。3)我们为什么要增加这些 "发达结构"?这对代码的性能来说是很糟糕的,而且这并不是说它会更容易和更快地抓住其中的错误。1.例如,你需要一个对象的数组。当你需要改变对象的行为时,问题就开始了,比如说,添加或删除对象或对它们进行排序。在OOP中,对指针数组本身的支持以及与之相关的工作都包含在基础对象中。修改实际包含在数组中的后裔对象不会影响任何东西。在程序化风格中--修改实际包含在数组中的真实对象--通常会影响到更多的地方,至少因为我们要考虑对象的大小变化。这将更容易导致错误。 跨平台--以OOP方式组织也更方便。当请求时,例如,一个交易头寸 - 我们得到一个界面,不管我们在什么平台上工作 - 界面提供虚拟功能,我们可以得到所有订单(MT4)或头寸(MT5)的所有数据,而且,从专家的角度来看 - 没有区别。专家顾问不需要知道它在什么平台上工作。2.好吧,"在程序化编程中完成 "意味着 "编写对象-程序",即在数据和程序之间建立一些联系,这在OOP中代表对象。3.然后我们有,比如说,一些种类的订单,它们有很多共同点。做一个对象COrderInfo是合理的,它将是基础对象,而它的后代将代表不同种类的订单。在这种情况下,交易处理器(我有CTADERProcessor类)将自动支持该订单,该订单已被传递给它,由那些需要处理该订单的程序来处理。 在交叉链接较少的地方,更容易捕捉到bug。这正是由封装和多态性提供的。我们要求交易头寸接口(CTALPositionI),所有与代表该头寸的真实类(CMT4PositionInfo,CMT5PositionInfo)的连接都只通过该接口进行,这恰恰有助于比直接与返回交易头寸数据的真实函数工作更容易纠正错误。 1234567 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
当然,漂亮的OOP必须用资源和大量的调试时间来支付。OOP只有作为一个方便的文本包装器或在运行时初始化中的最小用途才有意义......实际上,OOP 只是微软的一个营销手段,目的是增加程序员的工作时间成本,刺激他们购买更先进的设备。而且他们自己也不是傻瓜,用C语言和汇编编写所有的软件。
真是一派胡言。
大家都知道MS的程序员是直接用机器码写的
每个程序员的桌子上都有一本写有处理器机器代码的书,他们只是把代码刻录在打孔卡上。
比尔-盖茨可以在他的头脑中编译一个操作系统)。
真是一派胡言。
大家都知道,MS程序员直接用机器代码编写
你的丑话说得不太清楚,众所周知,汇编语言的插入是用来提高代码性能的...
我可以推测,OOP在终端中的应用是最少的,或者根本没有,因为没有像dotnet那样的大型外部库,很难得到这样紧凑的文件......
你对所讲的实质内容有什么有意义的争论吗?
检查。阿列克谢确实只是情绪化的反应。而在本质上,反对意见如下。
当你需要支持一些复杂的代码时,OOP是非常有用的。
当然,将所有的OOP技巧应用于一个指标MA是没有意义的。尽管在编写基本的类时--即使是为MA--OOP-方法至少也和通常的程序性方法一样好。
OOP的主要优势在发达的对象结构的支持下显现出来。当封装确保没有必要每次都了解重载函数的所有细微差别时。当它基于多态性时,代码的重用性 会变得更高。
OOP的本质更接近于现实世界,任何对象都与它的属性有关,并有一定的与环境互动的规则。
关于 "增加的工作时间成本"--这不是真的。 当然,当以OOP风格设计一个系统时,需要比面向过程的方法多一点工作。然而,这些额外的费用被维护和修改书面代码的便利性所补偿。
就个人而言,我写的是非常小的 "膝写 "指标,没有任何对象。然而,当需要更多的东西(至少是跨平台的)时--我总是使用OOP风格和对象库的现有做法。
你的小丑行为不太清楚,我们知道,汇编语言的插入是用来提高代码性能的...
我可以假设终端使用最少或没有OOP,因为没有像dotnet那样巨大的外部库,很难得到这样紧凑的文件......
1.OOP - 当你需要支持某种复杂的代码时,它有很大的帮助。
2.当然,将所有的OOP技巧应用于指标-MA是没有意义的。虽然,当基本的类被写出来时--即使是为MA--它仍然是OOP-方法,至少,不比通常的程序性方法差。
3.OOP的主要优势在发达的对象结构的支持下显现出来。
1.例如:?朗朗上口的口号是好的,但不清楚它们的具体含义......
2.已经有人说过,作为一个文本封装器,OOP是好的,但那是因为它在程序化编程中还没有得到完善。
3.为什么我们需要倍增这些 "先进的结构"?这对代码的性能是有破坏性的,而且不确定是否能更容易和更快地抓住其中的错误。
现代编译器的优化效果比一般甚至优秀的程序员好很多倍。
也许一些简单琐碎的事情可以,但只是因为人们坐下来手动写了算法,但如果是一些非标准的东西,那就远远不能确定了,特别是如果在那里发现了OOPesheh功能。
在驱动程序中,是的,他们使用assebler,但不是因为速度,它只是更容易与硬件合作..,
好吧,人们并不愚蠢--为什么他们会想要一些复杂的、令人困惑的、也是缓慢的东西呢?
比如说呢?朗朗上口的口号很好,但很难理解我们到底在说什么......3。
2.已经有人说过,作为一个文本封装器,OOP是好的,但那是因为它还没有在过程性编程中被提上日程。
3)我们为什么要增加这些 "发达结构"?这对代码的性能来说是很糟糕的,而且这并不是说它会更容易和更快地抓住其中的错误。
1.例如,你需要一个对象的数组。当你需要改变对象的行为时,问题就开始了,比如说,添加或删除对象或对它们进行排序。在OOP中,对指针数组本身的支持以及与之相关的工作都包含在基础对象中。修改实际包含在数组中的后裔对象不会影响任何东西。在程序化风格中--修改实际包含在数组中的真实对象--通常会影响到更多的地方,至少因为我们要考虑对象的大小变化。这将更容易导致错误。
跨平台--以OOP方式组织也更方便。当请求时,例如,一个交易头寸 - 我们得到一个界面,不管我们在什么平台上工作 - 界面提供虚拟功能,我们可以得到所有订单(MT4)或头寸(MT5)的所有数据,而且,从专家的角度来看 - 没有区别。专家顾问不需要知道它在什么平台上工作。
2.好吧,"在程序化编程中完成 "意味着 "编写对象-程序",即在数据和程序之间建立一些联系,这在OOP中代表对象。
3.然后我们有,比如说,一些种类的订单,它们有很多共同点。做一个对象COrderInfo是合理的,它将是基础对象,而它的后代将代表不同种类的订单。在这种情况下,交易处理器(我有CTADERProcessor类)将自动支持该订单,该订单已被传递给它,由那些需要处理该订单的程序来处理。
在交叉链接较少的地方,更容易捕捉到bug。这正是由封装和多态性提供的。我们要求交易头寸接口(CTALPositionI),所有与代表该头寸的真实类(CMT4PositionInfo,CMT5PositionInfo)的连接都只通过该接口进行,这恰恰有助于比直接与返回交易头寸数据的真实函数工作更容易纠正错误。