为什么现代图书馆不使用OOP

我是初学者级C ++程序员，但是我对语言的概念非常了解。当我开始学习外部C ++库（例如SDL，OpenGL）（也许还有其他东西）时，令我惊讶的是，我发现它们根本不使用C ++概念。

例如，SDL和OpenGL都不使用类或异常，而倾向于使用函数和错误代码。在OpenGL中，我看到过诸如glVertex2f之类的函数，该函数需要2个float变量作为输入，并且作为模板可能会更好。而且，这些库有时使用marcos，而使用宏函数似乎是一个坏习惯，这是一个普遍的共识。

总而言之，它们似乎更多地是用C风格而不是C ++风格编写的。但是它们是完全不同的语言，不是吗？

问题是：为什么现代图书馆没有利用它们所写语言的优势？

OpenGL和SDL都是C库，它们向世界其他地方公开了C接口（因为几乎每种语言都可以与C接口，但不一定与C ++接口）。因此，它们仅限于C为您提供的过程接口以及C声明和使用数据结构的方式。

除了C接口为您提供的“与其他语言接口”方面之外，C通常比C ++具有更高的可移植性，这反过来又使获取代码库中与平台无关的部分更加容易就像这些在其他OS或硬件体系结构上工作一样。几乎每个平台都有一个不错的C编译器，但是仍然有些平台的C ++编译器受到限制，或者有些不是很好。

尽管C和C ++是非常不同的语言，但是它们不是“不兼容的”，实际上，在很大程度上C ++是C的超集。存在一些不兼容性，但不很多，因此使用C ++中的C接口是一件很容易的事情去做。

我认为您将“编写库”与“将​​API暴露给外部”混淆了。我不太了解您提到的库（它们可能是用C内部编写的），但是我知道还有很多其他人（包括我本人）编写了C ++库/框架，它们充分利用了各种花哨的OOP做法/模式。 ，但仍然向外界公开了C风格的API。

1. C和C ++并不是完全不同的系统。C ++建立在C之上，并且a）可以轻松使用C代码，并且b）完全能够提供C风格的api。
2. C接口的优点是它很容易被世界其他地方使用。有互操作层，允许几乎所有语言（Python，java，c＃，php ...）使用C API，因为C ++接口可以从中使用.....嗯，也许C ++仍然不总是（不同的编译器，同一编译器的不同版本会导致问题）

过去，作为对一个工作项目的实验，我决定从C ++ DLL中公开“ OO”接口。为了隐藏内部细节并避免许多其他事情，我几乎最终重新发明了Windows COM（组件对象模型）。在完成该项目之后，我意识到COM并没有人们认为的那么糟糕，原因是a）公开了OOP接口，b）照顾了我遇到的所有问题，并且c）足够标准，可以从许多方面使用其他语言。

但是COM仍然不是没有它的包bag。在许多情况下，常规的计划C风格API仍然是更好的选择。

OpenGL和SDL都是C库，而不是C ++库。您可以从C ++使用它们，但是它们是用C编写的并且具有C API（也可以从其他语言访问； C ++很难通过FFI访问）。看看Boost可以获取大量的通用（和一些专门的）C ++库，以及SFML可以获取C ++多媒体库。

专门针对OpenGL，Op​​enGL最初是API堆栈的一部分-OpenGL提供了一个低级的，面向性能的API，可以从C（甚至Fortran）访问，而OpenInventor提供了一个高级的面向对象的API可以从C ++使用，并提供高级场景图API，以及用于将场景保存到文件或从文件读取场景的抽象以及GUI集成。

OpenGL的发展远远超过了OpenInventor（它满足了更紧迫的需求，为视频硬件制造商提供了一些可以优化的东西，并提供了人们可以针对的通用低级API，而不是直接处理3D加速硬件）。但是OpenInventor仍然存在，并且有一个很好的开源实现-Coin3D-支持Unix / X11，Windows和MacOS X / Cocoa。

这些库根本不是现代的。它们是C API，而那是不好的。您的前提有缺陷。