Por que as bibliotecas modernas não usam OOP

Sou um programador de C ++ para iniciantes, mas entendo bastante bem os conceitos da linguagem. Quando comecei a aprender bibliotecas externas de C ++, como SDL, OpenGL (talvez também outra coisa), para minha grande surpresa, descobri que elas não usam conceitos de C ++.

Por exemplo, nem o SDL nem o OpenGL usam classes ou exceções, preferindo funções e códigos de erro. No OpenGL, vi funções como glVertex2f, que usa 2 variáveis ​​flutuantes como entrada e provavelmente seria melhor como modelo. Além disso, essas bibliotecas às vezes usam marcos, embora pareça ser um acordo comum que o uso de macroses é ruim.

Em suma, eles parecem ser escritos mais no estilo C, do que no estilo C ++. Mas eles são idiomas incomparáveis ​​completamente diferentes, não são?

A questão é: por que as bibliotecas modernas não usam as vantagens da linguagem em que estão escritas?

Tanto o OpenGL quanto o SDL são bibliotecas C e expõem uma interface C para o resto do mundo (já que praticamente todas as línguas podem interagir com C, mas não necessariamente com C ++). Portanto, eles estão restritos à interface processual que C fornece a você e à maneira C de declarar e usar estruturas de dados.

Além do aspecto "interface com outras linguagens" que uma interface C oferece, em geral, o C tende a ser um pouco mais portátil que o C ++, o que, por sua vez, facilita a obtenção da parte não dependente da plataforma do código das bibliotecas como estes trabalhando em outro sistema operacional ou arquitetura de hardware. Praticamente todas as plataformas existentes possuem um compilador C decente, mas ainda existem algumas que restringiram os compiladores C ++ ou que não são muito bons.

Embora C e C ++ sejam linguagens muito diferentes, eles não são "incompatíveis", de fato, em grande parte, C ++ é um superconjunto de C. Existem algumas incompatibilidades, mas não muitas, portanto, usar uma interface C de C ++ é uma coisa muito fácil façam.

Eu acho que você está confuso "escrevendo uma biblioteca" vs. "expondo a API para fora". Não sei muito especificamente sobre as bibliotecas que você mencionou (elas podem ser escritas internamente em C), mas sei que muitas outras, inclusive eu, escreveram bibliotecas / estruturas C ++ que utilizavam totalmente todos os tipos de práticas / padrões extravagantes de OOP , mas ainda expôs a API de estilo C ao mundo exterior.

1. C e C ++ não são sistemas totalmente diferentes. O C ++ foi construído sobre C e a) pode consumir facilmente o código C eb) é totalmente capaz de fornecer APIs no estilo C.
2. A vantagem da interface C é que ela é consumida com muita facilidade pelo resto do mundo. Existem camadas de interoperabilidade que permitem que a API C seja consumida em praticamente qualquer idioma (python, java, c #, php ...), onde a interface C ++ é consumível de ..... bem, talvez C ++ e ainda nem sempre ( compiladores diferentes, versões diferentes do mesmo compilador causarão problemas)

No passado, como um experimento em um dos projetos em andamento, decidi expor a interface "OO" de uma DLL C ++. Para ocultar detalhes internos e evitar várias outras coisas, quase acabei reinventando o Windows COM (modelo de objeto componente). Após esse projeto, percebi que o COM não é tão ruim quanto as pessoas imaginam, porque a) expõe interfaces OOP, b) cuida de todos os problemas com os quais encontrei ec) é padrão o suficiente para ser consumível em vários outras línguas.

Mas o COM ainda não está sem sua bagagem. Em muitos casos, a API regular de estilo C do plano ainda é uma alternativa muito melhor.

O OpenGL e o SDL são bibliotecas C, não bibliotecas C ++. Você pode usá-los no C ++, mas eles são escritos em C e possuem uma API C (que também é acessível em outras linguagens; o C ++ é difícil de acessar via FFI). Dê uma olhada no Boost para uma grande variedade de bibliotecas C ++ de uso geral (e algumas especializadas) e SFML para uma biblioteca multimídia C ++.

Falando especificamente ao OpenGL, o OpenGL fazia parte de uma pilha de APIs - o OpenGL forneceu uma API orientada para o desempenho e de baixo nível, acessível a partir de C (ou mesmo Fortran), enquanto o OpenInventor fornece uma API orientada a objetos de alto nível, projetada para ser usado no C ++ e fornecer uma API de gráfico de cena de alto nível e abstrações para salvar / ler cenas de / para arquivos e integração da GUI.

O OpenGL acabou indo muito além do OpenInventor (ele preencheu uma necessidade mais premente, fornecendo aos fabricantes de hardware de vídeo algo para otimizar e fornecendo uma API comum de baixo nível que as pessoas poderiam atingir em vez de lidar diretamente com o hardware de aceleração 3D). Mas o OpenInventor ainda está por aí, e há uma boa implementação de código aberto - Coin3D - com suporte para Unix / X11, Windows e MacOS X / Cocoa.

Essas bibliotecas não são remotamente modernas. Eles são APIs C e são ruins. Sua premissa é falho.