开源改变世界

关于编程语言和编码风格的一些一般性讨论 #18

推推 grbl 2年前 (2023-01-21) 209次浏览

关闭
jsb1 打开了这个问题 2016 年 10 月 21 日 · 2 条评论
关闭

关于编程语言和编码风格的一些一般性讨论#18

jsb1 打开了这个问题 2016 年 10 月 21 日 · 2 条评论

注释

关于编程语言和编码风格的一些一般性讨论 #18

这有点偏离主题,但在不久的将来启动 2.0 版时可能会有用。
我不是真正的纯 C 编程的粉丝。但是在控制器上没问题。特别是我们在 grbl 中发现的那种干净的编码风格。
我认为以 Arduino 风格使用 C++ 是绝对不行的。大多数库的性能和灵活性很简单?
但最近我发现了用于控制器编程的 C++ 模板。它们基本上是“类固醇宏”。
您可以将所有代码保存在标头中,并在单个 main.cpp 中对其进行实例化。
这使得文件更少,声明的麻烦更少,全局变量也更少。
GCC(还有 AVR-GCC)可以对这类代码进行惊人的优化。几乎所有的小函数和所有只从一个地方调用的函数都会被内联和全局优化。我经常对非常小的二进制输出感到惊讶。
C++最大的问题不是语言,而是程序员。C++ 程序员倾向于使代码过于抽象和复杂——只是因为语言允许这样做。

关于编程语言和编码风格的一些一般性讨论 #18
贡献者

@jsb1:我的职业是航空航天研究员,每当我需要创建 Python 或 Matlab 之类的东西无法做到的高性能代码时,我都会使用 C/Fortran。在大多数情况下,我从来不需要使用 C++,也不需要深入学习它,主要是因为您给出的过于抽象和复杂的原因。

我可以看到 C++ 如何对具有抽象和类的大型软件项目有用,但我从不做大型项目。我倾向于保持小型和模块化,微控制器程序通常是这样的。为此,C 很好。我也尽量遵守 NASA-JPL 的关键任务编码规则 ( http://lars-lab.jpl.nasa.gov )。他们明确地只使用 C。

我不是特别喜欢处理大型复杂的软件。它们可能很难维护,并且很容易变得不灵活或无法更改。我不打算使 v2.0 变大或臃肿,所以我打算坚持使用 C,直到有充分的理由改变它。

关于编程语言和编码风格的一些一般性讨论 #18
作者

@chamnit: 没问题这是你的项目。
在现实生活中,我处于一个不同的世界:500000 多行 java 网络应用程序……
计算微控制器上的 cpu 指令是一种爱好。

喜欢 (0)