![R和Rstudio终端显示语言的更改[Windows]](/aiimages/R%E5%92%8CRstudio%E7%BB%88%E7%AB%AF%E6%98%BE%E7%A4%BA%E8%AF%AD%E8%A8%80%E7%9A%84%E6%9B%B4%E6%94%B9%5BWindows%5D.png)
![python中a[1][2]是什么意思](/aiimages/python%E4%B8%ADa%5B1%5D%5B2%5D%E6%98%AF%E4%BB%80%E4%B9%88%E6%84%8F%E6%80%9D.png)
银河系中的恒星有14000000万个
银河系中的恒星有1400亿个
2.为排列组合问题C22=2，无论怎么装，只有两种可能性，所以装队的可能性为50%
面向对象是一种编程的方式..就如同你思考问题的方式一样,是一种规则,方法..
好比 C语言的面向过程一样,它的着中点在于问题解决的过程,先干什么,接着干什么,最后干什么..比较明显的过程式,汇编更是面向对象编程的鼻祖..所以,它们很适合编写,像操作系统,嵌入式等这些与硬件亲近,且基本上不需要对程序进行较大修改的程序,用过程式就比较高效了.
而面向对象呢,它就不同于面向对象了,它的着重点在于,怎样表示程序中的对象,这样的程序很适合编写一些像游戏,ERP,等等这样的应用性软件.
举个例子..要写一段程序模拟大自然创造世界的程序:
如果,是过程式的编写方式,首先,创造宇宙,然后从宇宙的某个点开始,创造星系,将全部星系创造完毕,星系创造完毕,又从某个星系,开始创造该星系所有的子星系,完成后创造该星系中的其他子星系,将所有星系中的所有子星系全部创建完成之后,就开始在从整个宇宙中的某个星系中的子星系的某个星球开始,建立完整的生态体系,用地球做比喻,首先,建立细菌系,然后将细菌系分裂成动物,植物系列,动物系列,进行几何式分裂,形成几亿种生命形态..依次为宇宙中的每个星球建立生态体系,完毕之后,宇宙的过程式创造就完毕了..这种方式有个明显的不足的地方就是,当你在整个宇宙,创造完毕之后要加入一个新的星系,那对与程序员来说那将是灾难性的,而且,可扩展性极差..
再看看面向对象:
首先为宇宙中的基本对象建模,宇宙这个结构中半包含的成员
class 宇宙
{
class* 大星系
class 宇宙真空空间
public:
//宇宙能进行的动作
宇宙()
宇宙(宇宙&a)//复制宇宙..
void operator=(宇宙&a)//复制宇宙.
~宇宙()//自动销毁宇宙..
void 增加星系(unsigned int 新增星系编号)
void 销毁星系(unsigned int 已有星系编号)
...
...
... //等等操作
}
class 银河系:public 大星系
{
}
class 太阳系:public 银河系
{
class 地球
class 火星
...
}
class 地球
{
class 动物
class 植物
class 地球的状态
}
class 地球的状态
{
class 陆地
class 海洋
...
}
class 陆地
{
class 亚洲
class 欧洲
...
}
class 亚洲
{
class 中国
class 印度
class 蒙古
...
}
class 中国
{
class 省区[31]
}
class 省区
{
class 市区
...
}
class 市区
{
string 省名
int 人口
double 面积
...
}
将宇宙中所有这些对象建模之后,只需生成一个宇宙对象,咋们的宇宙不就生成了..而且你要加入新的星系,或者毁灭某个星系不就轻而易举,或者要在宇宙某个地方复制个地球,那还会有什么难呢?
但并不是说面向对象的编程方式就能完全没有过程式编程,那是不可能,好比,你把车子的所有部分造好了,你不组装起来,它又怎么可能开得起来呢,其实C语言中同样有面向对象,struct 就是C语言的对象组织方式,只不过再C++中它得到了飞升..
这两种编程的方式也没有 谁强谁弱的说法,如果,用Java去编写操作系统,无异于 用诸葛亮去单条吕布..反之,用汇编去编写网络游戏,无异与让张飞去考取状元,术业有专攻..
◥
” 作为LabVIEW产品经理，我被很多次问到这个问题。 老实说，这么提问实际上是错误的。必须要有具体的应用环境，这么提问才有意义（例如，“在这些限制条件下，哪一种语言更适合这个任务？”） 若没有这些细节，这个问题就像为什么面包比面粉好一般无意义。 如果您想创建一个测控系统，不同于C语言等低级语言，使用NI LabVIEW系统设计软件能够帮助您降低风险、节省开支并免除不必要的麻烦。在这里我并非暗示LabVIEW是比C语言“更好”的编程语言——特别是考虑到LabVIEW大部分内容不仅仅由G语言编写，还由C和C++语言组成。 恰恰相反，这两种语言各自具有不同的优势，程序员应合理择取才能达到自己的目的。 为什么要把LabVIEW比作面包？ 请继续阅读 LabVIEW和C语言相比起来就好比面包和面粉的关系。 如果您想做一个三明治，就必须先选用面包。 如果您想做一个蛋糕，先用的自然是面粉。 如果用面粉从头烘烤面包，即昂贵又费时（尤其是当你只想吃些小点心时），但若做的是蛋糕，面粉就必不可少了。 同样的，你会发现，要选择最适合的编程语言并非易事，它归结为使用正确的工具来完成适合的工作。 C语言提供了低级别的控制 当应用资源有限，必须严格管理时，C语言的使用效果更好。 由于C语言是相对低级别的语言，因此，即便是最细微的细节，如内存分配和线程，都必须考虑周全。优秀的程序员能够使用低级别的控制，省去大部分高级别应用带来的间接开销。此外，还能充分利用目标体系构架或主机操作系统属性，实现更高的性能。 正是由于上述原因，NI程序员使用C或C++编写了LabVIEW库中的大部分内容。LabVIEW与C语言在文件I/O和分析等操作的运行速度上旗鼓相当，因为这些操作都是基于低级语言编写的，并对LabVIEW支持的不同平台和操作系统进行了优化。 效率Vs控制 有时，若开发人员的效率足够高的话，就无需手动优化代码了。 减少一点控制，借鉴类似问题的解决方案，可极大地促进项目的高质量开发。 编程语言不断朝更高级抽象方向发展，让您更专注于手头的问题，而不是被计算细节所困扰。 LabVIEW： 并行执行和真实I/O 无论使用何种语言，高级系统设计与低级执行都是独立的。 在测控应用中，编程只是系统设计者的任务之一。 工程师很少有时间为了计算和测量硬件，或是操作系统上的改进，去更新或重写旧版本软件。 他们通过获取、处理和呈现真实数据进行改进——而不是去挖掘新方法处理内存分配和线程池。 使用LabVIEW，您可以使用经测试、支持、维护的NI底层代码库来创建应用。 而选择C语言意味着您需要实现、支持和维护自己的底层库，或从供应商处购买（NI提供NI LabWindows 64/CVI 软件与NI Measurement Studio） 从语法角度来说， C语言指令连续执行的能力非常强，CPU能以最快的速度处理它们。 对于纯粹的数据计算，在执行单一任务且指令相对基本的情况下，C语言非常适用。 而LabVIEW采用的是图形化语法，更适用于有真实时间约束的并行执行任务。 使用LabVIEW，您可以跳过基础构建的步骤，直接进行自定制。 LabVIEW不仅仅是一种编程语言及相关的代码库。 结合使用LabVIEW集成开发环境（IDE）与NI硬件，由此所带来的开发体验是各个部分的总和无法企及的。LabVIEW可以准确识别可用的硬件资源，并以下拉菜单和项目名称显示可用的I/O通道与执行目标。 在编辑过程中，您可以防止或察觉错误的配置，以避免代价高昂、又难以调试的运行时错误。 新一代测量硬件（如NI PXIe-5644R矢量信号收发器）甚至可以允许LabVIEW对其固件进行重新定义，达到传统、不同的编程语言和仪器无法实现的性能水平。 有很多项目都会延期或超预算完成，主要是因为工程师低估了聚集所有资源所需的开销。 若您使用LabVIEW，硬件驱动程序会以与数据分析库相同的格式返回数据，UI小部件则以相同的格式显示技术数据，无需再拼凑不同组件。 到底哪个更好： LabVIEW还是C语言？ 这个问题的最佳答案是：“一切皆有可能。” 正如《银河系漫游指南》中所说的， 除非您明确自己的问题或了解正试图解决的问题，否则得到的答案也是无意义的。 对于熟练的用户来说，LabVIEW和C都是非常有用的工具，几乎可以解决任何问题： LabVIEW适用于高级测试、测量和控制应用，而C更容易实现低级计算密集型任务。 若再有人问起LabVIEW好还是C语言好，您就回答一切皆有可能。 这也许是将问题朝着正确的方向引导的唯一途径了。
