21

I'm a beginner-level C++ programmer, but I understand the concepts of the language fairly well. When I began to learn external C++ libraries, like SDL, OpenGL (maybe something else too), to my great surprise I found out that they don't use C++ concepts at all.

For example, neither SDL, nor OpenGL use classes or exceptions, preferring functions and error codes. In OpenGL I've seen functions like glVertex2f, which takes 2 float variables as an input and probably would be better as a template. Moreover, these libraries sometimes use marcos, while it seems to be a common agreement that using macroses is bad.

All in all, they seem to be written more in C style, than in C++ style. But they are completely different incompaitable languages, aren't they?

The question is: why modern libraries do not use the advantages of the language they are written in?

gnat
  • 21,442
  • 29
  • 112
  • 288
Saage
  • 321
  • 2
  • 5
  • 1
    I think Timo answered your question well. Other reasons (for other libraries) could be a library that was created in C and then ported. Or C developers wrote it. – Jeanne Boyarsky Dec 24 '12 at 22:00
  • 5
    Apart from that, neither OpenGL nor are "modern" in the sense that they're young, or at least able to adopt fancy new faetures. Both have a long history (OpenGL 1.1: 1997; SDL: 1998) and backwards-compatibility constraints. –  Dec 24 '12 at 22:08
  • 1
    Just so it's said: DirectX is much more objecty (if also quite a bit more low-level). – cHao Dec 25 '12 at 04:15
  • 1
    Native C++ libraries, like stl and Boost, do not use the crappy, outdated, useless OOP concepts as well. – SK-logic Dec 25 '12 at 08:05
  • 5
    I think your misconception here is that SDL and OpenGL are representative for a lot of "modern libraries". The very popular Qt library, for example, is fully object oriented. Your question title better should be "Why don't SDL and OpenGL use OOP"? – Doc Brown Dec 25 '12 at 10:42

5 Answers5

32

Both OpenGL and SDL are C libraries and expose a C interface to the rest of the world (as pretty much every language out there can interface with C but not necessarily with C++). Thus, they're restricted to the procedural interface that C gives you and the C way of declaring and using data structures.

Over and above the "interfacing with other languages" aspect that a C interface offers you, C in general tends to be a bit more portable than C++, which in turn makes it easier to get the non-platform dependent part of the code of libraries like these working on another OS or hardware architecture. Pretty much every platform out there has a decent C compiler, but there are still some that have restricted C++ compilers or ones that are just not very good.

While C and C++ are very different languages, they are not "incompatible", in fact, to a large extent C++ is a superset of C. There are some incompatibilities but not many, so using a C interface from C++ is a very easy thing to do.

Timo Geusch
  • 2,773
  • 21
  • 15
  • Oh, I see. Well, the next question then: is there, say, a graphics library for C++ as effective as OpenGL? Or maybe a wrapper over OpenGL that uses all the advantages of C++ and provides good management of resources? The APIs would look much cleaner, and I don't think memory/cpu overhead would be too high. – Saage Dec 24 '12 at 22:05
  • Effective or efficient? Either way, it should be fairly easy to find a C++ wrapper for either SDL or OpenGL. A quick Google brought up this wrapper for OpenGL: http://oglplus.org/ - no idea how good it is, I haven't used it. – Timo Geusch Dec 24 '12 at 22:08
  • 1
    Yeah, there are quite a few projects that attempt to wrap OpenGL with more C++ish interfaces (I even have one myself, though I refrain from many features and mostly add overloading and such). My impression is that most add a lot of baggage which makes it both harder to translate pure OpenGL snippets and harder to apply standard optimizations (look up Data-Oriented Design; some game devs swear by it). But by all means don't let that deter you. Alternatively, you may have more luck using a whole game engine (such as Irrlicht or Ogre) rather than just a bare-bones graphics API. –  Dec 24 '12 at 22:10
  • Alright, I think I have all the answers I was looking for. Thanks everyone! – Saage Dec 24 '12 at 22:16
  • It should also be noted that graphics hardware does not understand or perform computations on classes. You have `float3`s because all the hardware is concerned with is arrays of floats. The "class" structure (the notion that a vector is 2, 3, or 4 floats) is all implicit in how the card is told to access its heap of memory. It may be nice to try and think in classes when programming graphics, but in my opinion, that kind of work is close enough to the hardware that it's more of a hassle than help to abstract away the dirty details of the implementation. – David Cowden Dec 26 '12 at 08:19
10

I think you are confusing "writing a library" vs. "exposing API to outside". I don't know much specifically about the libraries you've mentioned (they might be internally written in C), but I know many others, myself included, have written C++ libraries/frameworks which fully utilized all kinds of fancy OOP practices/patterns, but still exposed C-style API to the outside world.

  1. C and C++ are not entirely different systems. C++ was built on top of C and a) can easily consume C code and b) is fully capable of providing C-style apis.
  2. Advantage of C interface is that it is very easily consumable by the rest of the world. There are interop layers that allow C API to be consumed from just about any language (python, java, c#, php...), where as C++ interface is consumable from..... well, maybe C++ and still not always (different compilers, different versions of the same compiler will cause issues)

In the past, as an experiment in one of the projects at work, i decided to expose "OO" interface from a C++ DLL. In order to hide internal details and avoid a bunch of other things, I almost ended up reinventing Windows COM (component object model). After that project, I realized COM is not as bad as people make it out to be because a) it exposes OOP interfaces, b) takes care of all the issues I ran into and c) is standard enough to be consumable from a number of other languages.

But COM is still not without its baggage. In many cases, regular, plan C-style API is still a much better alternative.

DXM
  • 19,932
  • 4
  • 55
  • 85
7

Both OpenGL and SDL are C libraries, not C++ libraries. You can use them from C++, but they're written in C and have a C API (which is also accessible from other languages; C++ is a pain to access via a FFI). Have a look at Boost for a large array of general-purpose (and some specialized) C++ libraries and SFML for a C++ multimedia library.

3

Speaking to OpenGL specifically, OpenGL was originally part of a stack of APIs -- OpenGL provided a low-level, performance-oriented API, accessible from C (or even Fortran), while OpenInventor provides a high-level object-oriented API, designed to be used from C++, and providing both a high-level scene-graph API, and abstractions for saving/reading scenes to/from files, and GUI integration.

OpenGL ended up going much farther than OpenInventor (it filled a more pressing need, giving video hardware makers something to optimize for, and providing a common low-level API people could target instead of dealing with 3D acceleration hardware directly). But OpenInventor is still out there, and there's a good open source implementation -- Coin3D -- with support for Unix/X11, Windows, and MacOS X/Cocoa.

jimwise
  • 7,433
  • 1
  • 30
  • 32
-2

Those libraries are not remotely modern at all. They are C APIs, and bad ones at that. Your premise is flawed.

DeadMG
  • 36,794
  • 8
  • 70
  • 139
  • How is OpenGL not modern? – James Dec 26 '12 at 03:04
  • 1
    I'd actually have to agree with this. OpenGL is not modern in that its model for accessing and manipulating the state it manages is based on hardware from the early 1990's. Having to do things like bind a texture to a particular target on a particular unit, and only having a limited number of those available regardless of how many textures you have in VRAM is not very modern. – user1118321 May 25 '14 at 07:18