linux 为什么不用c++
2010-04-12 20:52:00 Nightmare 阅读数 6988

当今世界上绝大多数游戏都是C++写的,为什么要说不呢?

要做什么?写游戏。


写游戏首先要考虑些什么?做什么样的游戏,图形、音效、游戏逻辑如何实现。


用C++要先考虑什么?定义跨平台数据类型抽象,实现常用集合类,设计宏实现RTTI,写一个支持Unicode并可以和其他多种字符串类型互相转换的字符串类,自定义内存分配器,写个shared_ptr,组织预编译头文件,设计实现Object基类以处理跨DLL内存管理等问题……


那么这些和做游戏有什么关系?不做好这些就很难开始写游戏。


做这些要话多少时间?很多时间。

就是这个原因了,得花很多时间用来关心解决语言本身的不足,而不是要做的游戏本身。尤其是人们多有完美主义倾向,这些基本问题每个都可以发掘出更深层次的问题,进行更进一步的优化,进一步耗费宝贵的时间。这也可以解释为什么有那么多的引擎、引擎基础存在,因为时间都花在底层上了。

新技术出现的快,游戏架构更新的也快,补丁摞补丁是游戏行业的常事,补不了了就得换新的,哪管你是不是用神圣的C++写的。游戏开发人员属于消耗品,所以想开一点,人生苦短,及时行乐。有句话叫“Good managers don't torture their programmers with bad tools”,同理,聪明的程序员不用C++折磨自己。非得用的话,也尽量找个现成的类库,除非是要专研底层技术。

2017-12-21 00:00:00 MIcF435p6D221sSdLd2 阅读数 6080

要回答这个问题首先要明确题主对于写网页的定义。

一个网页往往包含前端、后端两部分。前端负责页面的呈现,后端负责数据的处理,可以大概的理解成前端是人的衣服,而后端是人的五脏六腑。

1

前端

前端的话主要是采用html+css+javascript这样的组合。html有点像word里面的操作,告诉浏览器,哪里是题目,哪里是正文。然后用css去定义这些标题,正文,链接的样式。而JavaScript则让这些内容能够动起来,比如有些网站烦人的弹窗,其实就是js里的alert指令完成的。在前端部分里,html和css似乎是不可替代的,JavaScript的话,近年来有typescript等,但都没能成为主流,c++在前端在的应用似乎是没有的。

2

后端

再来说后端部分,后端的语言有很多,市场占有比例最大的是应该是java,这也是java前几年就业火热的一大原因。php作为“世界上最好的语言”,则是一门专门为网页开发而设计的一门语言,近年来,python的Flask,Django等框架,也渐渐进入人们的视野,airbnb就采用了Django。

那么为什么我们不在后端里使用C++呢?这个问题其实,本身是不对的。因为我们并不是不使用,而是使用的比较少。腾讯就是以C++作为开发的主要语言。因为腾讯的产品主要偏向于通讯,而做通讯的大部分都是采用C++来开发的,产品需求决定了团队,而团队则决定了传统。还有一个原因就是,C++虽然开发效率低,但是性能会比java等好。而腾讯这样大体量的公司,是不在乎开发效率的问题的。

这也就不难理解,为什么使用C++使用的人少了。

1

开发效率低,现成的类库少,编译还存在问题,有时会觉得用别人的库,还不如自己撸一个轮子。而Python、php等则容易上手很多,甚至一星期就能做一个还过得去的网站。

2

C++语言难,因为C++比较偏向底层的开发,内存,指针,这些东西对于一个入门的开发者来说很伤脑筋,debug的过程很艰难,而且C++很灵活,其它语言的一些语言特性,你基本在C++上面都可以实现,这就使得你做一件事,有了很多条路可以选,这很容易陷入一种怪圈,写完一种方法觉得不够优雅,然后再用另一种方法,再写一次。写完C++再去写Java,你会觉得爽快很多。

AI&ML 一个有用的公众号

长按,识别二维码,加关注


2005-01-26 00:37:00 wishfly 阅读数 4979
评论: << Linus为什么不用C++写Linux内核?
  贴出者为 macolex
编程开发 macolex写著 '在最近的一个关于LKML的讨论中,Linus给出了为什么不用C++来写Linux内核的理由:



在最近的一个关于LKML的讨论中,Linus给出了为什么不用C++来写Linux内核的理由:

"In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

“事实上,我们曾经尝试过用C++来写,是在1992年的时候。很糟糕。相信我--用C++来写内核代码是一个非常愚蠢的想法。”

"The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

“实际上,C++编译器是很不可靠的。在1992年的时候情况就很差了,而且一些基础的东西到现在还没有改变:(1)整个C++对Exception的处理根本就是不完整的,特别是在写内核的时候。(2)任何喜欢把跟内存分配有关的功能匿藏起来的编译器或者程序语言对于编写内核来说都是错误的选择。(3)在C里面你也可以写面向对象的代码(写文件系统的时候很有用),是不需要C++的。

Linuxbyte.net 新闻报道力求为您提供国内最快,最新,最务实的Linux业界新闻,欢迎转载.请转载时注明新闻出处, 作者名称并保留此声明. 谢谢您的合作.

发布人:wangxiaohu 来自:http://kerneltrap.org/node/view/2067 '
2011-04-12 14:57:00 deyili 阅读数 1768

C++为什么不用delete代替delete[]?

总结:一直想不通c++为什么多此一举,呵呵,前几天给Bjarne Stroustrup大师写了一份信,第二天就收到回复了,自己再仔细琢磨了一下,终于好像弄明白了:-)

我的理解是这样的,无论new还是new[ ],C++的确知道返回的这个指针它指向多大的内存块,否则它就不可能正确地释放掉这块内存了。但是delete需要知道的不仅仅是指针指向多大的内存,而更重要的是要知道指针指向的数组中有多少个对象,知道了对象数量才能依次一一调用它们的析构函数。那么,下面的代码会产生什么样的结果??

int * pArray = new int[100];

……

delete   pArray;           //本来应该是   delete [ ] pArray;

根据上面的解释,我们不难想象,上述代码错误的原因并不是因为它只释放掉第一个元素的空间而没有能完全释放整个pArray所指的内存。 也就是说,在内存释放上不存在问题。问题出在在这里只对第一个元素调用了析构函数,而其他99个元素并没有被妥善地析构掉。呵呵,这才是真正的问题所在!! 当然对于整数类型来说并不会导致什么问题,但假如在每个对象中都分配了额外的资源,那么不调用对象的析构函数可就会导致严重的后果了……

那使用delete[ ]有什么用?这要从new[ ]说起,在new一个数组时,编译器会悄悄地在内存中保存一个整数用来表示数组中元素的个数。这样在使用delete[ ]时,编译器就会生成读取这个整数的代码,然后逐个调用析构函数。如果使用delete,则编译器只当作指针所指的是单个对象。再说了,new单个对象时,编译器也不会悄悄记录数组中元素的个数。呵呵,从这也可以感觉出C++的设计风格和宗旨,决不多费一点手脚,单个对象我就不记录长度,只有是数组时我才记录!:-)

下面是我给Bjarne Stroustrup的邮件及他的回信。在此对Bjarne Stroustrup大师平易近人的风范再次表示钦佩!!

> Hi, Dr. Stroustrup
>
> Firstly,Thank you for your great invention, the c++ programming language is
> really a great job, it gives me a lot of help in my study, it makes my work much
> more convenient!
>

Thanks

> Well, today ,I run into a confused problem about delete and delete[], so I
> wonder if you could give me some explanation or tips. I simply can't understand
> why c++ don't treat them in the same way. In other words, I think there is no
> need for delete[].
>
> For example, "delete [] ps", many textbooks just say that the operator
> delete[] is used to tell the compiler that the pointer "ps" refers to an array,
> but not a single object. Of course, I know that, but the thing is that I think
> the c++ compiler is totally clever enough to figure out whether "ps" points to a
> single object or an array. There is no need to bother the programmer to point it
> out explicitly.
>

No. The compiler cannot know.

void f(int* p)
{
     delete p; // or maybe delete [] p?
}

void g()
{
     int* q = new int[70];
     f(q);
     q = new int;;
     f(q);
}

separately compile those two functions an the compiler had no way of
knowing how many ints p points to.


> It's no doubt that the compiler knows the size of storage to which is pointed
> by "ps". Otherwise, it's impossible for c++ to deallocate the memory properly.
> OK, now that the compiler exactly knows how many bytes is allocated there and
> which type the object is, it can compute how many object are there, I mean,
> " number of object = number of bytes allocated / sizeof(object type) "
> Ok, after that, c++ may call destructor iteratively to destroy each object in
> the array and then deallocates the memory.
>

It is a bit trickier than that. Many allocators allocates space for at
least N ints when you ask for new int[N]. It is not uncommon for an
allocator to allocate more to minimize fragmentation.

> I don't know if I have made my question clear:-) In conclusion, I think a
> single object is just a special case of an array, so c++ is supposed to deal
> with them in the same way. There is no need for us to differentiate delete and
> delete[].
>

The snag is that many allocators (at least traditionally) just keep
track of the number of bytes allocated (rounding the allocation up to
something convenient). With destructors, the compiler has to know how
many objects are there (not just how much space is allocated). Some
implementers use (or used) two different layouts for individual objects
and arrays - the array layout (only) included an object count.

> In fact, I know certainly this is my misunderstanding. if not that, the c++
> committe should have changed the c++ syntax:-) I just hope to get some
> convincing explanation.
>
>
>
> Thank you, really appreciate for your help!
>
>
>
> Supermonkey,China,Nankai University
> 2007-09-03

2014-07-12 14:42:01 superzmy 阅读数 656


为什么我不用shared_ptr管理网络连接:

shared_ptr和weak_ptr等虽然方便,但是必须注意他们不是严格的线程安全的

服务端网络层在管理连接对象时就遇到过:在智能指针计数归零的但未析构的一瞬间,引用计数又被增加了(因为多线程增加),而shared_ptr是不支持引用计数从0恢复到1以后阻止析构恢复常态的。

另外还有一个缺陷是我使用的shared_ptr(来自boost)没有手动增加引用计数的功能,如果要增加就必须用一个shared_ptr来引用之,而连接对象在有数据要处理时需要自己防止析构,只能自己应用自己,造成了麻烦


后来我使用了复杂的C++模板技巧(VS2008)实现了一个多线程 对象池,使用句柄管理(随机循环句柄,仿HWND),持有句柄者能主动发现对象是否被销毁,

每个池内对象自带各种锁Flag状态(有构造和析构状态)和锁次数(类似引用计数),

逻辑层随意持有对象句柄,在使用的时候用对应状态(读状态/写状态等)的函数来获取指针,并在使用的瞬间增加引用计数,用完的瞬间释放引用计数,

这些状态还能帮助对象防止析构


事实证明采用了这个多线程对象池后,避免了很多需要脑经急转弯的代码(虽然这个对象池本身的实现需要强力的脑经急转弯),给网络连接对象编写提供了强有力的帮助,另外采用了原子量,性能比shared_ptr有所提升

以为不用C++

阅读数 131

为什么C++

阅读数 170

为什么C++

阅读数 544

为什么C++

阅读数 21

没有更多推荐了,返回首页