win32应用程序不是那么面向对象,为什么有这么多指针?

num*_*l25 8 c c++ winapi

对于你们中的一些人来说这可能是一个愚蠢的问题,也许我对这个问题提出了错误,因为我是c ++的新手.但是我注意到在使用很多win32应用程序时,你会使用大量的指针资源.为什么必须总是获取对象指针?为什么不发起一个新的类实例.说到这一点,我注意到在大多数情况下你永远不会发起新对象,但总是调用返回该指针的方法.如果该指针正在其他地方使用该怎么办?如果改变那个指针并且它正在其他地方使用,你不能弄乱一些东西.

Mat*_*lia 25

Windows API是为C语言设计的,它曾经是并且仍然是系统编程最常用的语言; C API是系统API的事实上的标准,为此,几乎所有其他语言都有一些方法可以调用外部C函数,因此编写C API有助于与其他语言兼容.

C API只需要一个简单的ABI,它几乎只包含用于函数的调用约定的定义(以及有关结构布局的内容).相反,C++和其他面向对象的语言需要复杂的ABI,它必须定义对象在内存中的布局,如何处理继承,如何布局vtable,如何传播异常,在哪里放置RTTI数据, ...此外,并非所有语言都是面向对象的,并且使用C++与其他非面向对象语言一起考虑的API可能是一个真正的痛苦(如果你曾经使用过C语言的COM,你就知道我的意思了).

顺便说一句,当Windows最初设计C++是不是在PC上那么普遍,而且也没有用c 这么多:实际上,3.11的Windows和许多应用程序的很大一部分仍用汇编写的,因为内存和CPU这个时代的制约因素非常紧张; 编译器也比现在更不聪明,尤其是C++.在手工锻造组装通常是唯一解决方案的机器上,C++开销实际上是不可接受的.

对于指针来说:Windows API几乎总是使用句柄,即不透明指针,能够在不影响现有应用程序的情况下改变每个资源的基本特性,并阻止应用程序乱搞内部结构.如果窗口管理器用于在内部表示窗口的结构发生变化,则无关紧要:所有应用程序仅使用HWND,它总是具有指针的大小.您可能会认为这是某种PIMPL习语.

但是,Windows在某种程度上是面向对象的(参见例如整个"窗口类"概念,或者在更深层次上,NT内核的内部工作,这很大程度上基于"对象"概念),但是它最基本的API,简单的C函数,不知何故隐藏了这个OO本质.另一方面,shell在很多年后被设计,主要用C++编写,它提供了一个真正面向对象的COM接口.

有趣的是,您可以在COM中看到在构建跨语言时必须面对的所有权衡,但仍然是C++偏向于面向对象的接口:结果非常复杂,在某些方面很难看,并且从任何语言使用都不是很简单.相反,Windows API是简单的函数,通常更容易调用.

如果您对基于C++ API的系统感兴趣,可以查看Haiku ; 就个人而言,这是其中一个方面因为我对该项目非常感兴趣.

顺便说一句,如果你打算使用API​​进行Win32编程,你最好得到一本好书,以适应这些"特殊性"和其他Win32习语.两个着名的是Rector-NewcomerPetzhold.


wer*_*dle 7

因为Win32 Api是用纯C编写的,而不是C++.因此几乎任何语言的任何程序都可以调用这些API.

此外,没有简单的机制可以在不同的模块和不同的语言中使用对象.即你不能将C++类导出到python.当然,有像OLE/COM这样的技术,但它们仍然写在简单的C上.它们有点复杂使用.

另一方面 - 对普通C函数的调用是标准化的.因此,您可以使用任何语言从DLL或静态库中调用例程.


Bri*_*ndy 5

Win32旨在使用C语言而不是C++.
这就是为什么你会看到定义的返回类型BOOL而不是bool例如.
bool是C++特有的,在C中不存在.

对于Microsoft的面向对象的Win32包装,请参阅MFC.

从那时起,Microsoft的一个新框架是.Net Framework.
.Net框架虽然基于托管代码,但不是本机运行的.在Windows上进行GUI编程的最现代的方法是WPF甚至Silverlight.

进行非托管GUI编程的最现代方法仍然是使用MFC,尽管有些人仍然喜欢使用直接Win32.

注意使用指针并不是特定于C,它在C++中仍然很常见.

  • MFC仍然是用C++做Windows的_official_ OO方式,不是吗? (3认同)
  • MFC太老了,设计不好,我不建议使用它...... (2认同)
  • 今天是真的,但对于1995年来说,这是你能做的最好的事情 - 在RTTI之前,在STL之前的信号之前. (2认同)