App*_*ker 25 c c++ gtk gobject
好吧,因此在GTK +版本0.60之后,设计人员意识到,为了将来的开发和进步,整个工具包需要被重写为面向对象.
现在,由于C不支持OOP,为了提供面向对象和继承heiriearchies,他们创建了GObject系统.现在创建GObject系统必须具有所需的开发时间,更多依赖性,更多问题,但他们必须创建它以向C编程语言提供面向对象的功能.但在那个时候,有是提供另一种解决方案恰好的是,C++!
为什么GTK +的开发人员只使用C++？
我的意思是,为什么浪费时间创建整个库而不是使用许多项目采用的经过时间考验的解决方案？不要误会我的意思,我不是想把这篇文章变成C vs C++的东西(我在论坛上已经有足够的了,谢谢你).我只是想知道让GTK +的设计师做出决定的原因和问题.
Ken*_*nde 25
我不能直接回答这个问题,至少就GTK而言.答案取决于GTK +开发人员,所以你必须追捕他们并问他们.但至于为什么人们想要向C添加面向对象的系统,而不是使用C++,有很多原因.我立即想到的三个是
语言复杂性:虽然C是一种非常简单的语言,但C++令人难以置信的复杂,支持大多数(不是所有)C的东西,以及诸如引用之类的便利,以及面向对象的特性和复杂的模板语言.你有没有看到新的价值体系:左值,右值,glvalues,prvalues和xvalues - 是吧？还有更多我可以谈论的内容.在给定时间的情况下,C++变得易于管理,但是仅仅想要在C中使用一些面向对象的功能仍然是过度的.
控制:如果设计人员使用C++,他们就会被C++哲学所困扰.例如,多重继承是一个有争议的想法,并且有充分的理由.按照设计,GObject系统构建为仅支持单继承,这可以大大简化继承层次结构.如果设计人员使用C++,则无法将用户限制为单个继承系统.多重继承只是一个例子 - 我确信GObject系统还有许多与C++意识形态不同的地方.
互操作性:这可能是一个很大的问题.尽管有几种语言可以与C++完全互操作,但事实上C++在互操作方面并不是那么出色.但是,与C的互操作性几乎被认为是理所当然的.C通常被描述为编程语言的通用语言,因为它构成了互操作的事实标准.通过设计C API,GObject设计者以任意数量的语言打开了GTK +开发的大门.
Mat*_*ias 14
GObjects旨在与语言无关.它具有动态类型,您应该与COM,.NET或CORBA等运行时系统进行比较,而不是与特定语言进行比较.如果你使用语言,那么Objective-C的功能比C++更多.
gcb*_*son 13
GObject类型系统执行在C++中无法执行的操作.首先,它允许在运行时创建新类,并以与语言无关的方式执行此操作 - 您可以在运行时在Python中定义新类,然后在用C编写的函数中操作该类的实例,甚至不需要意识到Python曾经涉及过.
从链接到问题的维基:
GTK +最初是在GNU图像处理程序(GIMP)中设计和使用的,作为Motif工具包的替代品; 在某些时候,Peter Mattis对Motif不再抱有幻想,并开始编写自己的GUI工具包,称为GIMP工具包,并成功地用0.60版本的GIMP替换了Motif.[3]最后,GTK被重新编写为面向对象,并重命名为GTK +.这首先在0.99版本的GIMP中使用.
这应该告诉你,这object-oriented paradigm不是GTK语言选择的最重要标准(与GTK +不同),并且该功能后来添加了很多.