mjiuming

其实感觉编程范式的侧重点并不在于性能，在于“通过限制你可能出错的细节而给你更多的自由空间”，在Robert.C.Martin的《架构简洁之道》中第三章末尾有对编程范式进行总结 > 结构化编程对程序控制权的直接转移进行了限制和规范 > 面向对象编程对程序控制权的间接转移进行了限制和规范 > 函数式编程对程序中的赋值进行了限制和规范 > 每一种编程范式都从某一方面限制和规范了程序员的能力。没有一个范式是增加新能力的。 其实也可以这么理解。通过限制goto的使用，我们可以不必在意程序控制权的跳转细节，从而给我们带来了更多的灵活性。通过封装对象的状态，我们可以安全地控制对象所处状态的有效性，从而可以使用更多设计模式。通过限制属性的赋值，我们可以写出无状态的函数与服务，这样就不逼关心函数的可见性与数据一致性，从而更方便地扩展服务。

编程范式是与具体语言无关的，比如说下面这段代码是使用C语言实现的，这段代码是OOP的，因为它满足继承、封装、多态三个特性，但是它的所有语法使用的都是标准C99语法，执行性能与面向过程的C语言代码没有区别 ```C #include #include struct Object { int a; void (*setA)(struct Object *object, int a); int (*getA)(struct Object *object); }; struct ObjectExtended { struct Object *__super; void (*setA)(struct Object *object,...

硬件场合下决定是否使用某语言的关键因素并不是性能因素，而是这个语言是否是实时性的，而不是使用了何种编程范式。 对于C语言和C++语言来说，所有内存资源的申请与释放都是手动进行的，所有的指令都是以程序员期望的顺序以相同的指令周期顺序执行。 对于Java语言和Golang语言等带自动垃圾回收语言来说，程序会在不适当的时机暂停线程来执行垃圾回收。对于某些任务来说可能期望在几个指令周期内接受所有外部信号并处理完成，在这种情况下暂停线程并执行垃圾回收就会导致信号的丢失。 至于说面向对象与面向过程的性能差异，我上面给出了使用C语言实现面向对象的示例了，而在Linux内核中也大量使用OOP范式来实现对硬件资源的抽象，所以说性能差异是来自于这个语言的执行机制，而不是这个语言采用的编程范式。

函数是否编译于main函数是否调用是没有关系的，比如考虑如下的C语言代码 ```c void foo() {} void bar() {} int main(int argc, char **argv) { return 0; } ``` 在GCC10.2.0下使用O0优化编译出来汇编代码如下 ```as .file "main.c" .text .globl foo .type foo, @function foo: .LFB0:...

即使是-O3也是同样的 ```as .file "main.c" .text .p2align 4 .globl foo .type foo, @function foo: .LFB0: .cfi_startproc ret .cfi_endproc .LFE0: .size foo, .-foo .p2align 4 .globl bar .type bar, @function bar: .LFB4:...

请使用阳间的方式沟通，总这么发真的没意思， 你说的这种方式无异于 ```c int a; int b; int c; int d(int){ /* do something */ return 0; } inf e(int){ /* do something */ return 0; } inf f(int){ /*...

1. 执行性能面向对象与面向过程基本没有区别 [Link](https://github.com/Snailclimb/JavaGuide/issues/431#issuecomment-616058358) 2. 实现相同功能集的情况下，面向过程与面向过程内存调用基本一致，不会出现面向过程不编译，面向对象就多编译了的情况[Link](https://github.com/Snailclimb/JavaGuide/issues/431#issuecomment-769555142) 3. `现在在讨论的是用任何语言都能实现面向对象范式，在实现相同功能的情况下大家的执行效率没有明显差异`，大家指的就是面向对象和面向过程，因为最上面就有人用Java和C比较，所以要强调不止Java能实现面向对象，C也可以 4. 即使是面向过程也会有使用结构体来组合多个对象的情况，面向过程的情况下是一个函数就能实现完整的功能，所以你可以为每个函数定义一个结构，就好像你都恰到好处的定义了你所需要的数据，但是即使面向过程也会出现第三方库有很多你不需要的数据的问题，以单片机引脚为例 ```c struct { int _1: 1; int _2: 1; int _3: 1; int _4: 1; int _5: 1; int _6: 1;...

> > 硬件场合下决定是否使用某语言的关键因素并不是性能因素，而是这个语言是否是实时性的，而不是使用了何种编程范式。 > > 对于C语言和C++语言来说，所有内存资源的申请与释放都是手动进行的，所有的指令都是以程序员期望的顺序以相同的指令周期顺序执行。 > > 对于Java语言和Golang语言等带自动垃圾回收语言来说，程序会在不适当的时机暂停线程来执行垃圾回收。对于某些任务来说可能期望在几个指令周期内接受所有外部信号并处理完成，在这种情况下暂停线程并执行垃圾回收就会导致信号的丢失。 > > 至于说面向对象与面向过程的性能差异，我上面给出了使用C语言实现面向对象的示例了，而在Linux内核中也大量使用OOP范式来实现对硬件资源的抽象，所以说性能差异是来自于这个语言的执行机制，而不是这个语言采用的 > > > 硬件场合下决定是否使用某语言的关键因素并不是性能因素，而是这个语言是否是实时性的，而不是使用了何种编程范式。 > > 对于C语言和C++语言来说，所有内存资源的申请与释放都是手动进行的，所有的指令都是以程序员期望的顺序以相同的指令周期顺序执行。 > > 对于Java语言和Golang语言等带自动垃圾回收语言来说，程序会在不适当的时机暂停线程来执行垃圾回收。对于某些任务来说可能期望在几个指令周期内接受所有外部信号并处理完成，在这种情况下暂停线程并执行垃圾回收就会导致信号的丢失。 > > 至于说面向对象与面向过程的性能差异，我上面给出了使用C语言实现面向对象的示例了，而在Linux内核中也大量使用OOP范式来实现对硬件资源的抽象，所以说性能差异是来自于这个语言的执行机制，而不是这个语言采用的编程范式。 > > //========================================================= > 我之前两条确实刚写完就删了，因为发完之后觉得自己这半吊子把内存占用多些说得肯定不好。...

典型的思维误区，并且与问题无关。 这个回答还是两年前实习的时候写的。 有很多种中间代码无关的面向对象编译解决方案。比如golang和C++的封装通过object layout编译器生成对应的field offset，多态通过vlookup查虚表，所有的对象解构都是通过编译器传递receiver到方法的第一个参数，都可以在编译器去做这些事情，与是否有字节码没有任何关系。 Java的bytecode还有LLVM IR的本质要解决的是跨平台运行，不同的编译器前端表示和前端无关的目标代码优化。然而这些和面向对象编程范式是两个正交领域，是不该放在一起去讨论的。 OceanWild ***@***.***>于2021年12月16日 周四下午3:18写道： > 区别在于编译过程的复杂度，像Java这种面相对象的编程语言中间多了一步编译字节码。 > > — > You are receiving this because you commented. > Reply to this email directly, view...

我应该放在Java基础里面还是排序算法里面？