Hi there ,
Why isn't openGL object-orientied? Everybody teaches Object Orientated Programming + Design Patterns, but OpenGL has many global functions. Isn't this bad style?
+4
A:
OpenGL was created for and in C, and none of that stuff existed then. Even now, they still want to keep a C interface, because C is still a widely used language.
Should they maintain both C interfaces and C++ wrappers, ditch C and just use C++, or keep a C interface? I'd argue the latter is the best solution: easy on them, not too hard for us.
That said, the OpenGL interface is admittedly gross. Lot's of stuff was "suppose" to be deprecated, but alas that got moved to a later date.
GMan
2010-01-30 02:43:54
What do you consider gross? Also, I don't see a single really good reason in your post. Even if OpenGL would be designed today, it'd still be C.
Kornel Kisielewicz
2010-01-30 04:00:30
@Kornel: Hence the keep the C interface. It's easy for everyone to use. Maybe I should have been more explicit: What I mean by that is almost every language can interface with a C library. As for the grossness, if you compare what OpenGL 3.0 was suppose to do to what it is, there's tons of useless and deprecated functions just hanging around. To me that makes it gross. If I wish to perform a task, a clean interface gives me one good flexible way to do that; not a bunch of different ways, where only one is considered the right way.
GMan
2010-01-30 04:32:58
@GMan, that unfortunately can't be avoided -- there's tons of software written using deprecated functions. Personally I've cleaned my local OpenGL headers from all the deprecated functions -- it helps :)
Kornel Kisielewicz
2010-01-30 04:39:11
@Kornel: I've never actually though of doing that, I tend to steer clear from modifying 3rd party headers. That said, I wrap up OpenGL so I no longer really have to touch it. :) Making wrappers is fun.
GMan
2010-01-30 04:51:44
@GMan, I'm also currently working on a templated boost-like wrapper for GL... it's fun and furious at the same time D:
Kornel Kisielewicz
2010-01-30 05:22:21
@Kornel: Ha, nice. I somewhat did that last year, but time constraints (school assignment, after all) forced me to cut back on the generality of it. How are the templates being used?
GMan
2010-01-30 05:37:58
@GMan - for example the vertex is templated so that there's single code for any type of vertex encoding (3v3n3c, 2v2t, etc), the type of mesh is templated via the vertex definitions, and the code to handle them is determinated at runtime. And some more tricks :>
Kornel Kisielewicz
2010-01-30 15:38:23
@Kornel: That sounds kind of like what I did. :3 fun times.
GMan
2010-01-30 17:09:23
Another gross thing is the lack of compile-time type safety. When every data type is basically just represented by a typedef for an int, you have to keep track of which handles represent which types of objects yourself. That's a bit sloppy, and could easily have been avoided, even in a handle-based C API. Win32 manages it.
jalf
2010-01-31 04:10:08
+4
A:
Well, there are a few reasons.
- You should think of an OpenGL context as a state machine. There is only one of them active at any time. There is no difference between putting a little Opengl.whatever in front of everything.
- Speed, OpenGL was designed to be a minimal API
- If it was object oriented, what language would you write it in? C++? Then everybody would ahve to write complex bindings. C is WAY easier to wrap.
Chris H
2010-01-30 02:47:15
amen. c is easy to understand, easy to write. OO definitely shouldn't be the default.
Matt Joiner
2010-01-30 03:21:16
Doesn't the fact that there can only be one context active at any time make it difficult/impossible to have two threads doing OpenGL calls simultaneously, since they would step on each other's context? That seems like it could be a problem given the prevalence of multicore CPUs these days...
Jeremy Friesner
2010-01-31 03:35:54
Well, yes. Only one thread can access a context at the same time and only one context can be active any any given time in a program. What's the point you're trying to make, and how does it relate to the asked question?
Chris H
2010-01-31 05:35:05
@Kornel Kisielewicz: Of course they could write bindings. Those would most likely involve wrapping the c++ api into extern c procedures (aka the kind of api we have now), but it would be possible
Grizzly
2010-09-24 13:05:00
+13
A:
The whole point of a low-level API is to make it as minimal and portable as possible. Giving it an object-oriented architecture would not allow this:
- Polymorphism adds unnecessary function call overhead.
- It forces you to use some relatively difficult calling convention, which reduces portability.
- You cannot wrap an object-oriented architecture to make it procedural, but you can do the reverse; so, it makes sense to make things as flexible as possible. It's trivial to write an object-oriented wrapper around OpenGL if you want.
Finally, you should really question what you've been taught about OOP. Despite what your college or university may tell you, OOP is not a panacea of program design. There are very good reasons why there is absolutely no object-orientation in the C++ STL (and most of Boost for that matter).
Object-orientation is useful in some cases, but you should learn when it is useful, and when it is not, and under no circumstances should you believe that anything that is not OOP is "bad style".
Peter Alexander
2010-01-30 03:10:00
+6
A:
In general, OpenGL is object oriented. It is just implemented in a language that doesn't directly support OOP. But the API is object-oriented: It consists of a number of different object types, and a set of operations defined on each. And the internals of each object type are hidden from the user. It fulfills all the requirements for OOP. It just so happens to be implemented in C, which doesn't have a convenient class or member method syntax.
Apart from this, there is absolutely nothing wrong with global functions. In C++, a common recommendation is to prefer them over member methods whenever possible. In functional programmming, global functions are the default.
jalf
2010-01-30 03:21:22
Cool, anonymous downvotes. Nothing quite like knowing what people disagree with in your post.
jalf
2010-01-30 03:42:09
OpenGL is not object-oriented at all. There are no classes in OpenGL, only raw data types. Since there are no classes, there are no objects and obviously no methods that can be called on objects. Again, everything is just raw data that changes the state of the OpenGL FSM.There's no message passing (because there are no objects).There's no inheritance (no classes).There's no polymorphism (no classes).The only thing that the OpenGL API shares with OOP is that it is an abstraction, but it abstracts the internals using procedures, not objects and class hierarchies.
Peter Alexander
2010-01-30 03:46:15
+1: for object orientation. Poita_ have you ever written FBO's or VBO's?
Kornel Kisielewicz
2010-01-30 04:02:56
@Poita: I think if you understood what it means to have "classes" or "objects", it would be clear you can program OOP in C. Consider Herb Sutter's "Interface Principle" if you don't get what I mean: Data + methods to operate on that data == Object. And guess what the interface provides.
GMan
2010-01-30 04:34:35
@GMan, the day I saw a cleanly written OOP C program, I **almost** started to like C :P.
Kornel Kisielewicz
2010-01-30 04:42:01
@GMan, I understand this, but I further think that you don't understand what OOP is. OOP is not simply programming with objects, that's just object programming. Object-oriented programming is specifically referring to the things I mentioned above (e.g. polymorphism, inheritance, class hierarchies, message passing etc.)If an object is just data and manipulation of data then does that mean all C programming is OOP? I don't think so.Finally, at no point did I say that you can't program in the OOP style in C.
Peter Alexander
2010-01-30 06:47:01
@Poita: Last point is fair, you didn't. But looks like we have different definitions of OOP. My version merely requires what's called objects (a collection of data) and the ability to manipulate that data. Boost doesn't use inheritance or message passing too often, does that means most of Boost isn't OO? I think your definition is too strict.
GMan
2010-01-30 06:55:25
Most of Boost isn't OO. Perhaps we'll just have to agree to disagree on what OOP is, but I would like to hear your opinion on the question I asked in my last comment, namely: If an object is just data that can be manipulated through procedures then does that mean that all C programming is OOP in your definition? If so, then I think your definition of OOP is too broad, and if not, then what else does a program need beyond data and data manipulation to be OOP?
Peter Alexander
2010-01-30 07:19:54
I'd just like to add something else as well: In your definition of OOP, is the STL OO? I know for a fact that Alexander Stepanov (the designer and main implementer of the STL) specifically created it NOT to be OOP because he thinks OOP is a farce.
Peter Alexander
2010-01-30 07:22:11
@Poita_: The point is that you manipulate the data through a related set of procedures - not that any arbitrary procedure manipulates the data directly as it is often common in plain C. But then again there are some different interpretations of OOP out there.
Georg Fritzsche
2010-01-30 10:48:08
@Poita_ So prototype-based languages such as Javascript or for that matter, Smalltalk, aren't object-oriented either? Someone needs to read up on the *original* meaning of OOP, I think. A `class` keyword is hardly essential. The thing about OpenGL is that it is *not* just manipulation of data. Every object is thoroughly encapsulated, their internals invisible as all the user sees is a handle, most functions are polymorphic in that they work on a range of different OGL objects.
jalf
2010-01-31 04:06:12
And each object has a clearly defined set of functions that can access its internal representation, just like OOP member methods. How is this not OOP?The STL too has OOP aspects. What Stepanov objected to wasn't the common-sense parts of OOP of abstraction and data hiding, but precisely the things that OGL *doesn't* have - the formalia of a "class" keyword, the loss of type safety or the inability to express generic code.
jalf
2010-01-31 04:07:14
I like your answer, it's a more fleshed out version of what I was trying to say. :) Also, I agree with GL versus DX. I used to swear by DX, but I finally tried OpenGL, and even though I think it could be cleaned up immensely, the amount of flexibility and control it offers is fantastic, not to mention the entire extensions system. I can actually take advantage of very specific features and fall back more and more until one works, and even use one vendor specific helper if I want, or my own generic implementation. You could never try to design such a system in DX.
GMan
2010-01-30 04:38:16
@GMan, and besides of that, lets be honest -- there is no API besides OpenGL if one wants to look at something else than Windows and XBox...
Kornel Kisielewicz
2010-01-30 04:43:46
@Kornel: Totally true. It's a shame more people don't tap into the power of OpenGL. Admittedly you have to know a little more to start using it, but that's ok.
GMan
2010-01-30 04:53:48
I agree to this, just begun with OpenGL in C# with the OpenTK framework, and boy do I love it. I found XNA a pain, this is actually fun!
Skurmedel
2010-02-01 20:39:20