为什么利用C++
当前位置:以往代写 > C/C++ 教程 >为什么利用C++
2019-06-13

为什么利用C++

为什么利用C++

副标题#e#

问题

为什么利用C++?在你皱眉筹备关掉这个网页之前,试着答复这样一个简朴的问题。

谜底是效率,是吗?每小我私家都知道谜底。可是,我们应该以更专业的角度来接头一种编程语言或是与之相关的工作。那么,让我再问你一个问题:效率是否是人们选择利用C++的独一来由,为什么他们不消C呢?C的效率公认比C++高(虽然,我知道,现已证明在某种水平上说,C并不比C++高效,但请不要在此挑错,因为纵然他们是等效的,问题仍然存在)。

神话

我知道你大概会说,这是一种“择优选择”,因为究竟C++就是设计成了C的优化,是C的扩充,大概它没有想象中的那么高效,但同时它却有许多梦幻的高程度的特征。那么问题就归结为“开拓者真的需要这些梦幻特征吗?”我的意思是,究竟我们都传闻过KISS(Keep It Simple,Stupid!保持简朴)和stuff(质料),我们也都听过这种说法——与C++对比,C更KISS,所以我们应该选择C。这样无休止的争论使得C和C++之间的较量酿成了一个神话(可能是一片杂乱)。令人惊奇的是,好像许多人倾向于C,而来由是C++太难正确利用了。甚至是Linus也这么想。

这种现象发生的真正严重的影响是,差遣更多的人在C与C++之间衡量利弊的时候,他们选择了C;一旦他们开始利用C,他们很快就会感想满意和舒服,就是所说的“令人满足”的体验。这样,当争论发生的时候,他们就会站出来说与C++对比,C是更好的选择。而实际上,他们都没有真正试着利用过C++,可能他们基础不是足够好的C++措施员。而真实的谜底,往往开始与“它取决于”。

那么,我说过“它取决于”,取决于什么?显然,在一些规模选择C比C++更好。譬喻,设备驱动措施的开拓凡是就不需要OOP/GP(面向工具措施设计/观念编程)技能。它只需要简朴的数据操纵;最重要的是,措施员能正确的知道系统如何事情,以及他们该做什么事情。再思量OS(操纵系统)的开拓,我本身从来没有参加过任何OS的开拓,可是读过大量OS代码(大部门是Unix),我感受许多OS重要部门的开拓也都不需要OOP/GP技能。

可是,这就意味着,在所有强调效率的规模,C都比C++好吗?实际上不是。

谜底

让我们详细问题详细阐明

首先,当人们体贴效率的时候,实际上就体贴两类效率——时间效率(譬喻:OS,运行时间,及时软件,高要求系统)和空间效率(譬喻:所有嵌入式系统)。可是,这种分类并不能真正帮我们抉择应该选择C照旧C++,因为C和C++在时间和空间上都长短常高效的。真正影响我们选择哪种语言(虽然是在C和C++之间)的是贸易逻辑(这里的“贸易”并不是指“企业应用贸易”)。譬喻,是不是利用OOP/GP来表达逻辑更好,可能是不是除了思量数据和措施还应该思量保持软件雅观。

从这点上来说,我们可以恍惚地把应用分为两类(虽然前提是我们只体贴C/C++,不体贴java/C#/ruby/erlang等):低程度应用和高程度应用。低程度应用的意思就是,在这里并不需要那些梦幻抽象如OB(基于工具)/OOP和GP;高程度的意思虽然就是需要了。显然,在所有需要C/C++的规模(由于它们的高效性)里,有大量“高程度”应用(参看在Bjarne Stroustrup主页上列出的),在这些规模,C++就会更有用。

不外,换个角度想想,纵然在这些规模,措施员在他们的代码中不利用那些高程度的抽象,照旧有他们应该利用C++的来由。为什么呢?因为你的代码不利用类和模板并不料味着不利用类库。思量所有便捷的C++类库东西(即将有校准扩展tr1/tr2)的实用性,我认为在这些环境下,有很是充实的来由选择C++——编码的时候你可以仍然利用C的形式(以任何你想要的方法来保持KISS)。同时,你还可以利用强大的C++类库(譬喻,STL尺度模板库,tr1/tr2组件等)。最终,就会发明这件大概会被许多人忽略的工作——有时KISS依靠抽象。我想,Matthew Wilson在他的新书“Extended STL,Vol1”的序言中,极其透彻地阐发了这个概念。书中提到了两段代码,别离用C和C++编写:


#p#副标题#e#

//C代码
DIR* dir = opendir(".");
if(NULL != dir)
{
struct dirent* de;
for(; NULL != (de = readdir(dir)); )
{
struct stat st;
if( 0 == stat(de->d_name, &st) &&
S_IFREG == (st.st_mode & S_IFMT))
{
remove(de->d_name);
}
}
closedir(dir);
}
//C++代码
readdir_sequence entries(".", readdir_sequence::files);
std::for_each(entries.begin(), entries.end(), ::remove);
And it’s even simpler in C++09:
// C++09代码
std::for_each(readdir_sequence(".", readdir_sequence::files), ::remove);

#p#分页标题#e#

我想,这能很清楚地说明,为什么纵然人们不需要利用类和模板的时候照旧应该利用C++——你会发明便捷的C++类库是何等有用。雷同地,假如一个高效的容器(可能一个巧妙的指针)可以使你挣脱所有手工操纵内存的贫苦事情,那么,尚有什么来由要利用那些原始的malloc/free?假如一个好的string类(我不是在说std::string;人人都知道这不是C++做的最好的)可能regex类可以使你挣脱所有你看都不想看的杂乱的字符串处理惩罚代码,那么尚有什么来由要选择手动做这件工作呢?假如一个“transform”(或‘for_each’)语句可以如此简朴明白地一行就完成你的事情(虽然,我知道C++做这件事需要lambda函数的支持),那么,尚有什么来由要手动写for-loops轮回?假如高定制的函数真的能实现你想要的成果,那么,尚有什么来由利用鸠拙的事情区来完成同样的事务呢?

KISS并不料味着“粗拙”;KISS的意思是为你的事情选择最适合的东西,“最适合”意味着你所利用的东西能尽大概直接(和简捷)的辅佐你表达你的想法。只要它不影响代码的可读性和易懂性。

现实问题

人们大概会说C++很容易会用错,而相反,C凡是更容易打点和操控。一其中等程度的C++措施员大概会写出一大串接洽细密的类,而很快这些类就会酿成一堆垃圾。但这实际上只是个体环境。一方面,在任何面向工具语言中城市常常产生这样的工作。老是有一些措施员,他们敢于在类之上再界说类,而他们甚至还不知道什么是HAS-A和IS-A;他们进修了所有界说一个类和从其他类担任一个类的语法,他们就以为把握了OOP的本质。另一方面,为什么问题会呈此刻C++中,是因为C++有许多阻止设计的巨大之处,是因为C++如此机动,以至于每个用C++办理的问题都有许多可选的办理方案(思量所有的GUI类库),以至于衡量选择哪种办理方案就成了难题的事情。C++的隶属巨大性是一个汗青遗留问题,C++0X做了多番尽力试图挣脱这个问题;关于设计的机动性并不是一件坏事——假如你思量到它可以辅佐好的设计师做出好的设计;假如有人谴责它,因为这样挥霍了本身许多脑细胞,那这只是小我私家问题,而不是语言问题,或者这样的人就不该该认真做设计。假如你担忧你的C++编程同伴因为受这些高程度特征的诱惑而使得你的工程代码一团遭,那么,或者你应该成立一个编码尺度并强制执行它(可能你可以遵循the collective wisdom,可能僵持C类型,可能带有C++类的C类型),而不是因为存在风险而退缩放弃(政策可以制止风险),因为假如不这样做,你将再也不能打仗所有C++类库。

另一方面,存在着最重要的心理上问题——假如一个语言中存在一个稀奇离奇的性质,那么最终就会有人发明它,然后人们就会被它吸引,这就会吸引那些原来在尽力做一些有用的事的人的精神(有点像墨菲法例),不要去打搅那些正在做完美办理方案的人。人们天生就会被一些罕有资源吸引。结论就是:诀窍和稀奇离奇的性质就是罕有资源,所以会引起人们的留意,更不必说把握一种诀窍可以使人感受本身与众差异。糟糕的是,纵然是没有代价的诀窍也会引起人们的强烈留意。

    关键字:

在线提交作业