编程语言的探究

不点

从今天开始，准备搜集编程语言方面的知识，试图找出一个最理想的编程语言。这里的判断标准，当然只代表我自己，是我自己的标准。我写的东西，不一定有用，也不一定成熟。我是随便写写，就像随笔或日志。着重点是探究、学习。也许写成博客比较好，因为博客不影响别人。然而我没有博客，而且也不知道哪个博客最好。所以呢，就想在这里写了。希望不至于干扰了他人的日常生活。

qzwhok

我还是比较喜欢纯中文编程，由26个字母排列组合表达函数意义不清晰，如果想表达清晰每句的涵义，就得搞一长串的字母组合，搞程序代码密密麻麻一大版，眼花缭乱，代码可读性极差，要花很长时间理清单词，出错率很高，而中文有几千汉字，排列组合出的代码要短很多，意义表达力强。最低级语言代码只有1和0两个符号排列组合编码组成，可读性最差。次之是，低级语言由0～9,a,b,c,d,e,f十六个符号排列组合编码组成，而由26个字母加上一些符号组成的代码的可读性仍然差，从这种意义上讲，中文编程是更高级，建义国人大力发展中文编程语言，少转弯路

20090101

我也跟你学习学习

vaf

能听懂人语言的语言最好, 连学都不用学.
不过, 需要等待......

不点

先学习 GNU Octave: https://www.gnu.org/software/octave/

先看流程控制语句。

一、if 语句

示例：

1. if (rem (x, 2) == 0)
   
2.     printf ("x is even\n");
   
3. elseif (rem (x, 3) == 0)
   
4.     printf ("x is odd and divisible by 3\n");
   
5. else
   
6.     printf ("x is odd\n");
   
7. endif

复制代码

很多语言都使用 if 和 else 关键字。而在 elseif 和 endif 上，不同的语言有不同的表现。C 语言没有 elseif 和 endif。有些语言使用 elif 和 fi。

这里容易引起错误的是，把 elseif 拆开成 else 和 if。因此，我觉得 C 语言的处理方式比较干净利索。C 语言的缺点是，用花括号来结束各种控制结构，可读性不那么好。但这个缺点不太严重。



二、switch 语句

1. switch (X)
   
2.   case 1
   
3.     do_something ();
   
4.   case 2
   
5.     do_something_else ();
   
6.   otherwise
   
7.     do_something_completely_different ();
   
8. endswitch

复制代码

看到模仿 C 语言的痕迹了，只是把 default 关键字换成了 otherwise。各个 case 之间是互不“贯通”的，这一点不同于 C 语言。因此，它不需要 break 语句来跳出 switch 语句块。

我倾向于认可 C 语言的处理方式，case 之间可以贯通，有时候是很有用的（经常见到有人这样使用）。无条件地“取缔”这种贯通，等于是损失了功能。然而 C 语言的 break 命令是有缺陷的，它既能跳出 switch 块，也能跳出循环结构，不合理。看这样的情况：

1. for (;;)
   
2. {
   
3.     switch(x)
   
4.     {
   
5.         case ...
   
6.         //假如想在这个地方跳出 for 循环，却没办法用 break 来实现，因为 break 只是跳出 switch 块了。
   
7.         case ...
   
8.     }
   
9. }

复制代码

因此，应该使用另外一个关键字来跳出 switch 块。

金

不点 发表于 2017-8-10 07:22
先学习 GNU Octave: https://www.gnu.org/software/octave/

先看流程控制语句。

厉害了，大佬能讲下Delphi 和 C 吗。这个语言还没有接触过

nttwqz

个人觉得吧，没有最理想的语言，只有相对理想的语言

话说，电脑版什么时候加了个验证回答，哈哈哈哈……

pcfan120

严重支持 不点 大大。。。 ^_^
我也希望学点编程的知识

pcfan120

哦，突然发现论坛改进了。。发贴需要 验证。。希望越来越好。。

邪恶海盗

其实个人认为,如果不是开发什么大的项目地话,不必纠结编程语言的问题,只要会用一种就行了...

话说我是什么都不会的...

邪恶海盗

至于博客,可以考虑typecho,很轻巧的一个PHP博客程序,交流也很方便的

还可以考虑使用论坛程序来做博客,比如xiuno,反正我觉得可以...

不点

前面在学习流程控制语句时，其实碰到了一个古老的话题：结构化程序设计(Structured programming)。现在就复习一下有关知识。

主要内容摘录：

1、结构化程序设计方法的起源来自对 GOTO 语句的认识和争论。

2、GOTO 语句确实有害，应当尽量避免；

3、完全避免使用 GOTO 语句也并非是个明智的方法，有些地方使用 GOTO 语句，会使程序流程更清楚、效率更高；

4、争论的焦点不应该放在是否取消 GOTO 语句上，而应该放在用什么样的程序结构上。其中最关键的是，应在以提高程序清晰性为目标的结构化方法中限制使用 GOTO 语句。

5、结构化程序设计主要强调的是程序的易读性。

6、任何程序都可由顺序、选择、循环三种基本控制结构构造。三种结构的任意组合和嵌套就构成了结构化的程序。

7、每一个结构只有一个入口和一个出口。

8、任何一个有 GOTO 的程序，可以改为完全不使用 GOTO 的程序。


注意上述第 3 条，其实是说 goto 不可以彻底消灭。换句话说，仅仅使用三种基本控制结构，并不能达到所有的程序设计目标。goto 确实可以被取代，但有时会因此而损失性能。在效率和性能不太重要的场合，可以取缔 goto 语句。

Octave 这个语言，就已经取缔了 goto。因此，Octave 是一个高级语言。那些低级、中级语言（Assembly，C ），是离不开 goto 的。毋庸置疑，低级、中级语言肯定是效率高、性能好的语言。

总结一下：在大多数情况下，可以不使用 goto。但在一些少数情况下，必须使用 goto。如果一个编程语言想“打通”、“通吃”高级语言和低级语言，那它应该包含 goto，否则它只能用作高级语言，无法兼具低级语言的功能。

记得 BASIC 语言不允许从循环体之外 goto 到循环体之内。然而 C 语言却允许这么做。C 语言的 goto 几乎允许任意的跳转。然而编程者们都会尽量避免使用 goto，因此 goto 总体使用率是很低的。但不管使用率怎么低，它也是有可能使用到的，彻底取缔不合适（如果这个语言一定要照顾中、低级的程序设计的话）。

有一个叫做 HLA（High-Level-Assembly）的语言，它就是“高级语言化”了的“低级语言”。可惜的是，它只支持 Intel 平台，不支持 ARM 平台。然而这个编程语言是开源的，因此将来有可能支持 ARM 平台。

在 HLA 中，你想用高级就用高级，想用低级就用低级，编程者的自由度空前扩大了！

不点

在搜索 HLA 时，顺便发现了 IR 和 LLVM。参考：

IR is better than assembly
https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/

不点

关于 goto 的话题还有很多（在搜索引擎里面搜“java goto”）。Java 就是明确禁止 goto 的一个语言。goto 是 Java 的一个关键字，但却是个不能使用的关键字（这好像有点绕口）。我猜 Java 的设计者担心 C 程序员习惯地把 goto 带过来，于是就让那些含有 goto 的程序无法编译。就是说，让 goto 成为一个“能够引起编译错误”的关键字（这就不绕口了）。

Java 的这个做法，我并不认同（前面我已经提到，goto 不可以彻底取缔）。但此处不谈这个问题，而是谈谈 Java 撤销 goto 以后的一个补救思路。这里顺便说说，goto 虽然撤销了，但还得有补救的措施！这反过来印证了，goto 并非完全无用（从哲学上讲），就算是 Java 的开发者，也能隐约认识到这一点（我是否曲解了 Java 开发者的本意？但我觉得在哲学上可以这么理解或“曲解”吧）。

在循环嵌套的情形，Java 让（外层的）for 循环（能够）带上标号，在（内层）循环体内的 break（ 或 continue）语句（后跟标号）就可以跳出（或继续）外层的 for 循环。可以看出，Java 的开发者认为，goto 的用处就在这一种情形。因此，他认为没必要使用 goto（而用 break 和 continue 来简单地取代了）。我认为，goto 的应用场合，绝不只有这么狭窄的一种情形。在有些特殊的程序设计任务中，甚至需要从循环体外 goto 到循环体内！这里不展开讨论。


无论如何，“给 for 循环加上标号”这个思路有闪光点，可以借鉴。

“for 循环”可以看成一个“语句块”，因此，假如我们推广一下，让所有的语句块都可以有标号，那可能就更有用了。目前的 C 语言不能为“语句块”定义标号。C 语言的标号只代表一个“地点”，不过这个“地点”的位置（几乎）可以设置在程序中的任何地方。假如我们重新解释 C 语言的标号，让这个标号能够代表其后（紧接着的）语句块（单一语句也可以看成一个特殊的语句块）的标号，那就可以像 Java 那样来处理了。Java 的那种处理方法的实质，我认为，属于“结构化 goto”的范畴。就是说，虽然 goto 本身破坏了“结构化”，但通过对 goto 进行“规范化”，让 goto 能够纳入（用户定义的某个新的）“结构化”框架内，那就完全没问题了。

在 https://stackoverflow.com/questions/2545103/is-there-a-goto-statement-in-java
有这样一个 Java 的示例（我不确定是否符合 Java 语法，但我认为这个设计的构思很棒！）：

1. public static void main(String [] args) {
   
2. 
   
3.      boolean t = true;
   
4. 
   
5.      first: {
   
6.         second: {
   
7.            third: {
   
8.                System.out.println("Before the break");
   
9. 
   
10.                if (t) {
    
11.                   break second;
    
12.                }
    
13. 
    
14.                System.out.println("Not executed");
    
15.            }
    
16. 
    
17.            System.out.println("Not executed - end of second block");
    
18.         }
    
19. 
    
20.         System.out.println("End of third block");
    
21.      }
    
22. }

复制代码

上述代码说明了如何能够在 Java 中使用 goto（用 break 曲径通幽）。在上述代码中，既然 break 可以用在循环体之外，那么，continue 是否也能用在循环体之外呢？（——这是不是有点“难为情”？）因此，在这样一个例子中，如果能够使用 goto 关键字，岂不是更好？我们来分析一下上述代码中 “break second;”语句的缺陷。（程序是给人看的）人首先要查到 second 这个标号；然后，还要找到 second 块的尾部（是个花括号）。这累不累呀？还有点“变态”吧？如果允许使用 goto 的话，那么直接在尾部花括号处写上一个标号，岂不更清晰？

不过，上述示例能够为语句块设置标号，确实是一个不错的构思。我觉得，可以利用这一点，来为 C 语言的 goto“脱困”，即，对 goto 进行“结构化封装改造”。大致思路如下：

1. my_label: //这就是下面语句块的标号。在一个具有标号的语句块里面，是可以随便使用 goto 的。
   
2. {
   
3.                 //这里面可以是一个很复杂的程序，但所有的 goto 都不跳出语句块之外。
   
4.                 for (;;) {
   
5.                                 //.........
   
6.                                 if (......) goto  my_label_02;
   
7.                 }
   
8. my_label_01:
   
9.                 for (;;) {
   
10.                                 //.........
    
11.                                 if (......) goto  my_label_03;
    
12.                 }
    
13. my_label_02:
    
14.                 for (;;) {
    
15.                                 //.........
    
16.                                 if (......) goto  my_label_01;
    
17.                 }
    
18. my_label_03:
    
19.                 for (;;) {
    
20.                                 //.........
    
21.                                 if (......) goto  my_label_02;
    
22.                 }
    
23.                 //上面只展示了跳出循环体的情况。其实 goto 不只是可以跳出循环体，甚至也可以从循环体外跳入循环体，就像 C 语言目前的设计那样。
    
24. }

复制代码

像这样被封装了的 goto，就认为是安全的，完全不影响语句块之外的情况。上述 my_label 语句块，就相当于“用户自定义的一个新结构”了。

整体思路就是：对 goto 的使用方式，不加任何实质性的限制；所限制的，仅仅是 goto 的使用“格式”，即，必须在“允许使用 goto 的程序块”里面，才可以使用 goto。

以上仅仅是举例如何封装 goto 罢了（仅仅是个思路）。具体的封装办法可能是多种多样的。

slore

然而 C 语言的 break 命令是有缺陷的，它既能跳出 switch 块，也能跳出循环结构，不合理。

语法要设计简单，C语言来说，break是跳出block，不管你是while,for还是switch，统一的概念，且不跨层这是一个好的清晰的设计。

1. for..
   
2.    for..
   
3.    ...
   
4.    next
   
5. next

复制代码

这种时候难道需要提供一个跳出内层for的语法，再提供一个跳出外层for的语法么？

for,switch嵌套N层的话，怎么办？break以外再有跳出语句的话，程序的逻辑需要慢慢仔细梳理了，
只break一层的话，谁都可以看得很容易。如果想跳出外层for，建议代码函数化。

1. int switchblock(){
   
2.    switch()
   
3.   {
   
4.     case x:
   
5.       return 1;
   
6.   }
   
7.   return 0;
   
8. }
   
9. 
   
10. forblock(){
    
11. 
    
12.   for (...){
    
13.     if (switchblock()==1) {
    
14.        break;
    
15.     }
    
16.   }
    
17. }

复制代码

slore

3、完全避免使用 GOTO 语句也并非是个明智的方法，有些地方使用 GOTO 语句，会使程序流程更清楚、效率更高；
注意上述第 3 条，其实是说 goto 不可以彻底消灭。换句话说，仅仅使用三种基本控制结构，并不能达到所有的程序设计目标。goto 确实可以被取代，但有时会因此而损失性能。在效率和性能不太重要的场合，可以取缔 goto 语句。

Java 的这个做法，我并不认同（前面我已经提到，goto 不可以彻底取缔）。

有很多语言都是没有goto的了包括主流语言，所以说不可以彻底取缔不过是你个人的看法。

goto是某些场合，代码更清晰，比如 异常处理，这个也是目前我们唯一允许使用goto的使用场合。
更多的时候是造成代码逻辑混乱，全局变量等共享数据看起来有始无终。
“效率更高”现在是微乎及微的，函数化总是可以让代码不用goto，不过代码会多些，
效率上来说，不过多几次调用并没有什么效率影响。函数化后，反而让其他人更容易理解编写人的意图，
基本上是弊大于利的，某些场合有奇效，但是更多时候不易懂，容易埋下潜在BUG，所以不推荐。

不点

谢谢以上各位关注这个话题并参与讨论。很抱歉，没能及时给您回复。

回 slore 兄，谢谢捧场，谢谢深入讨论技术话题。

我在一楼已经申明，这是博客、随笔性质的，是代表我个人的评判标准的。因为从我的哲学认识来看，世上没什么真理，所谓真理，都是自己认定的，没什么标准。

您对我的观点提出异议，这本身是瞧得起我，也是对我的尊重。那么，假如我要辩解，提出我的反驳意见，那也是对您的尊重。

我要辩解的是，goto 使用量本来就不会很多，尤其是，当已经存在三种基本控制结构以后。

在 goto 造成巨大麻烦的年代里，那时候缺少控制结构，人们大量使用 goto，这才造成问题。

在 goto 的使用频率非常低的“现代化”年代里，goto 根本就没机会造成问题。——这就是我主要反驳的理由。

请不要认为我“有意鼓励”使用 goto ——我绝对没有这个意思。我并不认为使用 goto 了就“特别好”。我也同大多数人一样，认为应该尽量避免使用 goto。

我是在为那些必须使用 goto 的场合（有这样的场合，不管它多么的稀少）找到一个“用户自定义结构”的解决办法。我这种办法，完全不排斥目前行之有效的结构化成果；我的办法是与目前的结构化方案兼容的。也许对某个人来说，他整个一生的工作都碰不上需要使用 goto 的场合。那么，这种“用户自定义结构”对他来说就“完全无用”，他完全可以当成“垃圾”扔了（不用关注、不用投入任何学习成本；只要简单地“忽视”、或“扔掉”即可）。就是说，这种“用户自定义结构”的方法或理念，并不影响一个“正常”人在“正常”情况下的任何行为，不会对任何人带来任何麻烦。但它会对某些“不正常”人所遇到的“不正常”情况，给出解决方案。

我同意您对 goto 使用率“低”的评价。我觉得 goto 可能也就主要用在与机器指令打交道的场合了。使用率很低，是相对于那些不与机器指令打交道的场合。那些需要与机器指令打交道的场合，可能就有比较高的几率使用 goto 了。在特殊的情况下，当代码需要优化时，说不定需要节约几个字节，或禁止使用函数，禁止子程序调用（少压入一个堆栈，少执行一条指令，少浪费一点时间），等等。此时，也许最优化的方法就是使用 goto 了。像前面提到的 HLA 这个语言，就是可以采用高级结构来编写汇编语言的一种语言。我们作为一个人，来评价某个东西有用或无用、重要或不重要，都是站在自己的立场上，是自己经验的一种体现而已，因此，不能取代别人的感受和意见。

在讨论技术时，由于认识不同，侧重点不同，在有时候、有些人，可能会觉得某个话题的讨论是“吹毛求疵”的、或“高射炮打蚊子”（没必要的），等等。认识不同、立场不同，结论就可能相去甚远。因此之故，每个人都掌握着自己的真理。那真理，其实就是他自己经验的总结。这是正常现象，也是普遍现象。

我接受您的意见。从您的意见中，我看到有关 goto 的问题不那么紧要。我们所遇到的绝大多数情况，都不是“性能攸关”的。人越来越浪费了，一个人浪费的资源是很可观的（比如人消耗的水量就大得很）。所以，人越来越不注重性能的优化了，而是越来越注重一个程序对人的可读性、友好性的问题了。于是 goto 这个问题好像越来越没什么人去关注了。既然如此，那么接下来我们就换个话题，不再讨论 goto 及其相关问题了。其实，通过以上的讨论，我觉得问题也都已经摆明了，因而也就没什么可讨论的了。

谢谢 slore兄。也再次一并谢谢各位，抱歉没能及时逐一回复。

不点

这几天通过搜索，发现了一个名叫 ROOT 的强大团队：

https://root.cern.ch/

这个团队开发了（曾经）强大的 CINT 语言，现在转向了 Cling 语言——这俩都是 C/C++ 语言的解释器，可用于交互式执行，也可用作脚本。

另外，LLVM 和 IR 的庞大架构也都是这个团队开发出来的。他们开发的 Clang 编译器，可以作为 gcc 的一个替代品。

值得一提的是，ROOT 所开发的产品都是开源的：

https://root.cern.ch/license

我所关注的 Cling（当然也是开源的），在这里：

https://root.cern.ch/cling

在下载页，我幸运地看到了为 ARM64 的 Linux 所编译的版本，下载并解压后就能直接在 ARM64 的 Ubuntu 下使用了（无需安装）。

目前的 Cling 比起另一个闭源的 Ch 解释器来说，还有一些差距；但我感觉，Cling 赶超 Ch，只是时间问题。

顺便说，Ch 的官网在这里： https://www.softintegration.com/

不点

今天在 ARM ubuntu 下成功编译了 Cling，自己祝贺一下。编译过程不太顺利，记录下来，是怕以后再遇到问题时，忘了是如何解决的。

按照 Cling 官方 https://root.cern.ch/cling-build-instructions 给出的脚本 https://raw.github.com/karies/cling-all-in-one/master/clone.sh 进行自动下载和编译。编译过程中出了很多 gcc internal error，并提示向 gcc 开发者报告 bug。我一开始以为是 cling 的代码有错，就丧失了信心。后来仔细看出错的红字提示内容，是说 gcc 的“内部错误”。这就明白，不是 Cling 代码有错，而是 gcc 执行过程出错。通过研究 clone.sh 了解到，在执行 cd obj 命令进入 obj 目录之后，make -j6 命令出错。我试试反复执行 make -j6 （这里的 6 是 CPU 核心 core 的个数，我的 RK3399 是六核的），每次出错信息都不一样，而且前面编译未通过的步骤，再次编译就可能顺利通过了。经过几个小时反复执行 make -j6 命令，终于全部编译通过。现在想想，gcc 时常出错的原因，很可能是 CPU 发热造成的。我的 CPU 没有风扇。

在顺利执行 make -j6 之后，只剩下安装的步骤了：make -j6 install。这不需要 root 用户的权限，它会把 Cling 安装在我自己的 inst 目录下。

以下是 gcc 出错信息片段：

［62%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/MicrosoftCXXABI.cpp.o
［62%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/ObjectFilePCHContainerOperations.cpp.o
［62%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/SanitizerMetadata.cpp.o
［66%］ Built target clangStaticAnalyzerCheckers
［66%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/SwiftCallingConv.cpp.o
［66%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/TargetInfo.cpp.o
［66%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/VarBypassDetector.cpp.o
c++: internal compiler error: 已杀死 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
c++: internal compiler error: 已杀死 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/build.make:1190: recipe for target 'tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/MicrosoftCXXABI.cpp.o' failed
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/build.make:566: recipe for target 'tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaDeclAttr.cpp.o' failed
make［2］: *** ［tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/MicrosoftCXXABI.cpp.o］ Error 4
make［2］: *** ［tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaDeclAttr.cpp.o］ Error 4
make［2］: *** 正在等待未完成的任务....
CMakeFiles/Makefile2:17360: recipe for target 'tools/clang/lib/Sema/CMakeFiles/clangSema.dir/all' failed
make［1］: *** ［tools/clang/lib/Sema/CMakeFiles/clangSema.dir/all］ Error 2
make［1］: *** 正在等待未完成的任务....
[ 66%］ Built target sanstats
CMakeFiles/Makefile2:17453: recipe for target 'tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/all' failed
make［1］: *** ［tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/all］ Error 2
Makefile:149: recipe for target 'all' failed
make: *** ［all］ Error 2
firefly@firefly:~/obj$


以下是 gcc 最后编译成功时的信息：


［100%］ Built target libclang
Scanning dependencies of target c-index-test
Scanning dependencies of target c-arcmt-test
［100%］ Building C object tools/clang/tools/c-arcmt-test/CMakeFiles/c-arcmt-test.dir/c-arcmt-test.c.o
［100%］ Building C object tools/clang/tools/c-index-test/CMakeFiles/c-index-test.dir/c-index-test.c.o
［100%］ Building CXX object tools/clang/tools/c-index-test/CMakeFiles/c-index-test.dir/core_main.cpp.o
［100%］ Linking CXX executable ../../../../bin/c-arcmt-test
［100%］ Built target c-arcmt-test
［100%］ Linking CXX executable ../../../../bin/c-index-test
［100%］ Built target c-index-test
firefly@firefly:~/obj$

hs6688

感谢经验之谈

音乐与电脑

新人表示支持。可能cpu发热严重导致程序编译不过，居然还有这种操作？楼主为什么在用arm的cpu呢？那么，楼主你认为c#，java与php怎么样？我认为c#最好，无论是代码书写难度，代码可读性，抒写效率，优化，跨平台能力，执行效率还是debug效率。有支持intel的，有没有支持amd，via与ibm的呢？支持mips与alpha的又是什么呢？

音乐与电脑

新人表示支持。可能cpu发热严重导致程序编译不过，居然还有这种操作？楼主为什么在用arm的cpu呢？那么，楼主你认为c#，java与php怎么样？我认为c#最好，无论是代码书写难度，代码可读性，抒写效率，优化，跨平台能力，执行效率还是debug效率。有支持intel的，有没有支持amd，via与ibm的呢？支持mips与alpha的又是什么呢？

音乐与电脑

新人表示支持。可能cpu发热严重导致程序编译不过，居然还有这种操作？楼主为什么在用arm的cpu呢？那么，楼主你认为c#，java与php怎么样？我认为c#最好，无论是代码书写难度，代码可读性，抒写效率，优化，跨平台能力，执行效率还是debug效率。有支持intel的，有没有支持amd，via与ibm的呢？支持mips与alpha的又是什么呢？

不点

感谢楼上高人给以指点。本人腐朽没落，没接触过太多的编程语言。像 C#，java，php，python，ruby 等，我都仅限于知道其名称而已，基本都不曾接触过。IBM、VIA、MIPS、ALPHA 也都没机会接触。期待以后能有时间多接触、多学习。

gnuxwy

很喜看不点大师的贴子，总氏能分享长智者的体验，获得各种收获。
屮就只懂得一点点c和cjj，还在初步学习当中，希望以后水平高了，也能象大师一样做出优秀的产品。

音乐与电脑

楼主谦虚了 我可不是高人

linpinger

大大，可以再 github上写一个静态博客，会一点简单的html语言就行，不会也可以用工具来做网页，使用git来推送，还可以同步推送到 git.oschina.net 上，我就是这么做的，http://linpinger.github.io/?s=wuyou                 http://linpinger.oschina.io  后面这个链接不能直接点开，要复制粘贴，应该是对来源做了限制

不点

linpinger 发表于 2017-8-18 16:57
大大，可以再 github上写一个静态博客，会一点简单的html语言就行，不会也可以用工具来做网页，使用git来推 ...

年轻的时候，经常为争取自由而斗争。现在已经没有那种活力了。不仅不去争取，而且白送给我自由，我都可能不要（我驾驭不了那种自由，宁可不要；正如许多人驾驭不了 Linux，宁可不要 Linux）。折腾自己的博客？我还真折腾不了，不是年轻人的那种心态了，没有年轻人的那种“冲劲”了（向前冲的冲，一声，不是当“怼人”讲的那个 chong4），没有年轻人的那种“朝气蓬勃”了。

不点

Cling 旨在提供一款高性能的 C++ REPL

作者 Sergio De Simone，译者 谢丽  发布于 2015年5月25日 http://www.infoq.com/cn/news/2015/05/cling-cpp-interpreter

Cling 是一款交互式 C++ 解释器，以 LLVM 和 Clang 为基础构建，其目标是通过超越编码-编译-运行-调试这个惯常的 C++ 工作流程提供生产力的飞跃。

Cling 提供了一个读取-求值-输出循环（REPL），类似常见的 Unix shell，并支持 Emacs 绑定。使用 Cling 可以测试 C++ 代码片段，而不需要创建文件、包含头文件等等。使用 REPL 的主要好处是可以在极短的时间内测试一个想法，而不需要等待构建系统编译代码。REPL 在学习一门语言时也非常有用，因为它让试用语言特性变得更简单。

ROOT 是 Cern 的数据分析框架，Cling 即是由该框架背后的团队开发完成，作为现有的命令行 C/C++ 解释器 CINT 的一个替代方案。目前，在粒子物理学领域中，许多 实验 中都用到了 ROOT，包括大型“强子对撞器（Large Hadron Collider）”。

Cling 可以解析 Clang 所能解析的一切内容，并且还支持一些 CINT 特有的 C++ 扩展。ROOT 开发团队 列举 了 Cling 提供的主要好处，其中包括使用生产级解析器、JIT 允许不使用封装器直接进行库调用、使用独立的解析器和执行引擎。

Cling 在 GitHub 上开源。用户既可以使用 每日构建的二进制包 进行安装，也可以 从源代码构建。官方的 一体化构建脚本 支持基于 Unix 的系统，而 Windows 上的手动构建过程可以借助 CMake 实现。此外，Gallagher Pryor 介绍 了针对 ARM 平台构建 Cling 的步骤，这比针对 x86 平台进行构建要复杂得多，因为开发团队没有在他们的构建脚本中直接提供这种支持选项。

查看英文原文：Cling Aims to Provide a High-performance C++ REPL

正如前面帖子所说，现在在 ARM 平台编译 Cling 已经很简单了，全自动完成，不需要人工介入（cpu 发热导致 gcc 被 kill 掉，这不是 Cling 的错）。

不点

Cling 编译成功后，发现 root 比 cling 更强大一些（两者都是 root 团队开发的）。于是就尝试编译 root。编译 root 稍稍费了一些周折。在 configure 和 编译过程中，有出错提示，说缺少某某软件和某某 lib 库，于是就安装相应的软件和库。有一个比较棘手的问题，需要记录下来，免得以后想不起来是怎么解决的了。

在编译 TreePlayer 时，总是提示缺少 MultiProc 库。就是说，连接参数 -lMultiProc 失败。等价地说，就是找不到 libMultiProc.so 文件。我怀疑根本就不需要这个文件，于是，我随便把 lib 目录下的另外一个文件（只要是合法的 .so 格式即可） cp 成 libMultiProc.so，果然编译通过了！等全部编译完成后，发现 lib 里面的 libMultiProc.so 也更新了（文件大小变了，不是我随便拷贝的那个 .so 的大小了）！这说明，在编译 TreePlayer 时，根本就不需要  libMultiProc.so ，而这个 libMultiProc.so 是在后续编译过程中生成的。

无论如何，费了一天的时间，能够在 ARM Linux 下把 ROOT 编译成功，也是一大收获，自己觉得很不容易，因而很高兴，自娱自乐，庆祝一下。

不点

root 果然比 cling 更好一点。看这个

1. firefly@firefly:~/root-6.10.04$ root
   
2.    ------------------------------------------------------------
   
3.   | Welcome to ROOT 6.10/04                http://root.cern.ch |
   
4.   |                               (c) 1995-2017, The ROOT Team |
   
5.   | Built for linuxarm64                                       |
   
6.   | From tag v6-10-04, 28 July 2017                            |
   
7.   | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
   
8.    ------------------------------------------------------------
   
9. 
   
10. root [0] cout << "jhjkhjk" << endl
    
11. jhjkhjk
    
12. (std::basic_ostream<char, std::char_traits<char> >::__ostream_type &) @0x7f8a126ac8
    
13. root [1]

复制代码

就是说，cout 在 ROOT 下执行成功。然而 cout 在 cling 下却不行，即使加上 -std=c++11 参数也不行：

1. firefly@firefly:~$ cling -std=c++11
   
2. 
   
3. ****************** CLING ******************
   
4. * Type C++ code and press enter to run it *
   
5. *             Type .q to exit             *
   
6. *******************************************
   
7. [cling]$ cout << "uyhhuiyui" << endl
   
8. input_line_3:2:2: error: use of undeclared identifier 'cout'
   
9. cout << "uyhhuiyui" << endl
   
10. ^
    
11. input_line_3:2:25: error: use of undeclared identifier 'endl'
    
12. cout << "uyhhuiyui" << endl
    
13.                         ^
    
14. [cling]$

复制代码