Pourquoi les bibliothèques modernes n'utilisent-elles pas la POO

20

Je suis un programmeur C ++ de niveau débutant, mais je comprends assez bien les concepts du langage. Quand j'ai commencé à apprendre les bibliothèques C ++ externes, comme SDL, OpenGL (peut-être autre chose aussi), à ma grande surprise, j'ai découvert qu'elles n'utilisaient pas du tout les concepts C ++.

Par exemple, ni SDL, ni OpenGL n'utilisent de classes ou d'exceptions, préférant les fonctions et les codes d'erreur. Dans OpenGL, j'ai vu des fonctions comme glVertex2f, qui prend 2 variables flottantes en entrée et serait probablement mieux comme modèle. De plus, ces bibliothèques utilisent parfois marcos, alors qu'il semble être courant que l'utilisation de macroses est mauvaise.

Dans l'ensemble, ils semblent être écrits plus en style C qu'en style C ++. Mais ce sont des langues incompressibles complètement différentes, n'est-ce pas?

La question est: pourquoi les bibliothèques modernes n'utilisent pas les avantages de la langue dans laquelle elles sont écrites?

c++ object-oriented libraries opengl Saage
la source
1
Je pense que Timo a bien répondu à votre question. D'autres raisons (pour d'autres bibliothèques) pourraient être une bibliothèque qui a été créée en C puis portée. Ou les développeurs C l'ont écrit.
Jeanne Boyarsky,
5
En dehors de cela, ni OpenGL ni "moderne" dans le sens où ils sont jeunes, ou au moins capables d'adopter de nouvelles faetures fantaisistes. Les deux ont une longue histoire (OpenGL 1.1: 1997; SDL: 1998) et des contraintes de compatibilité descendante.
1
Juste comme il est dit: DirectX est beaucoup plus objectif (même s'il est également un peu plus bas).
cHao
1
Les bibliothèques C ++ natives, comme stl et Boost, n'utilisent pas également les concepts de POO merdiques, obsolètes et inutiles.
SK-logic
5
Je pense que votre idée fausse ici est que SDL et OpenGL sont représentatifs de beaucoup de "bibliothèques modernes". La bibliothèque Qt très populaire, par exemple, est entièrement orientée objet. Le titre de votre question devrait être "Pourquoi SDL et OpenGL n'utilisent-ils pas la POO"?
Doc Brown

Réponses:

31

OpenGL et SDL sont des bibliothèques C et exposent une interface C au reste du monde (comme presque tous les langages peuvent interagir avec C mais pas nécessairement avec C ++). Ainsi, ils sont limités à l'interface procédurale que C vous offre et à la manière C de déclarer et d'utiliser les structures de données.

Au-delà de l'aspect "interface avec d'autres langages" qu'une interface C vous offre, le C en général a tendance à être un peu plus portable que le C ++, ce qui à son tour facilite l'obtention de la partie non dépendante de la plate-forme du code des bibliothèques comme ceux-ci travaillant sur un autre système d'exploitation ou une architecture matérielle. Presque toutes les plates-formes ont un compilateur C décent, mais il y en a encore qui ont des compilateurs C ++ restreints ou qui ne sont tout simplement pas très bons.

Alors que C et C ++ sont des langages très différents, ils ne sont pas "incompatibles", en fait, dans une large mesure, C ++ est un sur-ensemble de C. Il y a quelques incompatibilités mais pas beaucoup, donc utiliser une interface C à partir de C ++ est une chose très facile faire.

Timo Geusch
la source
Oh je vois. Eh bien, la question suivante alors: existe-t-il, disons, une bibliothèque graphique pour C ++ aussi efficace qu'OpenGL? Ou peut-être un wrapper sur OpenGL qui utilise tous les avantages de C ++ et fournit une bonne gestion des ressources? Les API sembleraient beaucoup plus propres, et je ne pense pas que la surcharge mémoire / processeur serait trop élevée.
Saage
Efficace ou efficace? Dans tous les cas, il devrait être assez facile de trouver un wrapper C ++ pour SDL ou OpenGL. Un rapide Google a présenté ce wrapper pour OpenGL: oglplus.org - aucune idée de sa qualité, je ne l'ai pas utilisé.
Timo Geusch
1
Oui, il y a pas mal de projets qui tentent d'envelopper OpenGL avec plus d'interfaces ish C ++ (j'en ai même une moi-même, bien que je m'abstienne de nombreuses fonctionnalités et j'ajoute principalement la surcharge et autres). Mon impression est que la plupart ajoutent beaucoup de bagages, ce qui rend à la fois plus difficile la traduction d'extraits OpenGL purs et plus difficile à appliquer des optimisations standard (recherchez Data-Oriented Design; certains développeurs de jeux ne jurent que par cela). Mais ne vous laissez pas décourager. Alternativement, vous pouvez avoir plus de chance en utilisant un moteur de jeu complet (comme Irrlicht ou Ogre) plutôt qu'une simple API graphique simple.
D'accord, je pense avoir toutes les réponses que je cherchais. Merci tout le monde!
Saage
Il convient également de noter que le matériel graphique ne comprend pas ou n'effectue pas de calculs sur les classes. Vous avez des float3s car tout le matériel est concerné par des tableaux de flottants. La structure de "classe" (la notion qu'un vecteur est 2, 3 ou 4 flottants) est tout implicite dans la façon dont la carte est invitée à accéder à son tas de mémoire. Il peut être agréable d'essayer de penser en classe lors de la programmation de graphiques, mais à mon avis, ce genre de travail est suffisamment proche du matériel pour qu'il soit plus compliqué que d'aider à résumer les détails sales de l'implémentation.
David Cowden
10

Je pense que vous confondez "écrire une bibliothèque" et "exposer l'API à l'extérieur". Je ne sais pas grand-chose en particulier sur les bibliothèques que vous avez mentionnées (elles peuvent être écrites en interne en C), mais je sais que beaucoup d'autres, moi-même inclus, ont écrit des bibliothèques / frameworks C ++ qui utilisent pleinement toutes sortes de pratiques / modèles sophistiqués de POO , mais toujours exposé API de style C au monde extérieur.

  1. C et C ++ ne sont pas des systèmes entièrement différents. C ++ a été construit au-dessus de C et a) peut facilement consommer du code C et b) est entièrement capable de fournir des API de style C.
  2. L'avantage de l'interface C est qu'elle est très facilement consommable par le reste du monde. Il existe des couches d'interopérabilité qui permettent à l'API C d'être consommée à partir de n'importe quel langage (python, java, c #, php ...), où l'interface C ++ est consommable depuis ..... bien, peut-être C ++ et toujours pas toujours ( différents compilateurs, différentes versions du même compilateur causeront des problèmes)

Dans le passé, en tant qu'expérience dans l'un des projets à l'œuvre, j'ai décidé d'exposer l'interface "OO" à partir d'une DLL C ++. Afin de masquer les détails internes et d'éviter un tas d'autres choses, j'ai presque fini par réinventer Windows COM (modèle d'objet composant). Après ce projet, j'ai réalisé que COM n'est pas aussi mauvais que les gens le prétendent car a) il expose les interfaces POO, b) s'occupe de tous les problèmes que j'ai rencontrés et c) est suffisamment standard pour être consommable à partir d'un certain nombre de autres langues.

Mais COM n'est toujours pas sans bagages. Dans de nombreux cas, une API régulière de type C est toujours une bien meilleure alternative.

DXM
la source
7

OpenGL et SDL sont des bibliothèques C et non des bibliothèques C ++. Vous pouvez les utiliser à partir de C ++, mais ils sont écrits en C et ont une API C (qui est également accessible à partir d'autres langages; C ++ est difficile à accéder via un FFI). Jetez un œil à Boost pour un large éventail de bibliothèques C ++ à usage général (et certaines spécialisées) et SFML pour une bibliothèque multimédia C ++.


la source
3

S'adressant spécifiquement à OpenGL, OpenGL faisait à l'origine partie d'une pile d'API - OpenGL a fourni une API de bas niveau, orientée vers les performances, accessible depuis C (ou même Fortran), tandis qu'OpenInventor fournit une API orientée objet de haut niveau, conçue à utiliser à partir de C ++, et fournissant à la fois une API de graphique de scène de haut niveau, et des abstractions pour enregistrer / lire des scènes vers / depuis des fichiers, et une intégration GUI.

OpenGL a fini par aller beaucoup plus loin qu'OpenInventor (il répondait à un besoin plus urgent, donnant aux fabricants de matériel vidéo quelque chose à optimiser et fournissant une API commune de bas niveau que les gens pouvaient cibler au lieu de traiter directement avec du matériel d'accélération 3D). Mais OpenInventor est toujours là, et il y a une bonne implémentation open source - Coin3D - avec un support pour Unix / X11, Windows et MacOS X / Cocoa.

Jimwise
la source
-2

Ces bibliothèques ne sont pas du tout modernes à distance. Ce sont des API C, et de mauvaises à cela. Votre prémisse est défectueuse.

DeadMG
la source
Comment OpenGL n'est-il pas moderne?
James
1
Je dois en fait être d'accord avec cela. OpenGL n'est pas moderne dans la mesure où son modèle d'accès et de manipulation de l'état qu'il gère est basé sur le matériel du début des années 1990. Devoir faire des choses comme lier une texture à une cible particulière sur une unité particulière, et avoir seulement un nombre limité de celles disponibles quel que soit le nombre de textures que vous avez dans VRAM n'est pas très moderne.
user1118321