Korval, you can’t find anything substantially wrong with what I suggested as a most basic level of C++ functionality, so you say it’s useless. If I’d argued for more, you’d say that was too much of a change or too slow, or some other reason for doing nothing.
I don’t think you really want to explore the issue rationally, so I’m not going to argue with you.
Avi
[This message has been edited by Cyranose (edited 01-06-2004).]
Can’t C++ wrap C code in a Class? So, why not just do that? Of course another problem comes since C can’t do function overloading. The very essence of putting 2D on a function that has only 2 parameters for a point doesn’t make sense. The function should already know that it is 2D by the amount of parameters.
Another problem comes about using the f for float and so on. Using templates can solve this problem, gone should be the days of having do so much work. C isn’t dead but more coders are going to C++ as the benefits are there in working with classes. I also don’t understand, why don’t they just do it like the STL library which is cross platform? Through, one can all ways just create a wrapper if they so desire.
Why can’t they create both a C and C++ library? Granted there is a lot of work in doing so.
[This message has been edited by Gold_Dragon (edited 01-09-2004).]
Why can’t they create both a C and C++ library?
Because there is little to gain from it. You get some syntactical sugar and that’s all. No real productivity is gained. No real clarity. The only thing you gain is using C++ language features. And you lose all of the benifits of straight C (binary compatibility, for example).
Cyranose, what’s about people like me who doesn’t use C++(and are not going to use it)? Every C++ compiler has a different liker structure. You don’t want to standartise all existing C++ compilers, aren’t you? If so - good luck!
Ok here is my opinion about OOP…
I think OpenGL should be like is now… NOT OOP ( in the C++ way, so must be C-styled ).Why? Simple… you can always write a “wrapper” from C-style to C++ style… The inverse operation is, obviously, impossible.
Other reason to take the “non-oop” C-style is that some machines ( like PS2 a year ago ) haven’t a C++ compiler to work with it. If my memory is not failing me, VectorC was only a “C” compiler some time ago(notC++)…So if, for example, I want to use OGL2.0 in the PS2, OGL2.0 CANT BE C++ based…Or other example, JNI… not sure if JNI supports C++… So, that is true is that any C++ compiler is ALSO a C compiler ( again, the inverse is NOT true )…
Another reason to choose the C-style is that C++ is typically slower when using polyformic methods ( because it has to use the vtbl, so adds calling overhead ).
Problems of the C-styled OGL… well… I can call glEnable(1) … cuz it won’t be strong-typed… well… simply change the function definition to void glEnable(enum eENABLE_STATES). In general, polish a little the gl.h
Other problem of the C-style is that is NOT CLEAR… ok, that can be an issue.
So, putting all the advantages and issues on the balance, I prefer the “plain” c-style to the oop C++ style ( and omg, i am a frekkie of the OOP cuz I program in Java,c#,vs.net and C++ ), but sincerely, I think, in this case, is better the C-style for the OGL 2.0. But, when I use OGL2.0 in my 3d engine, do a wrapper or custom OOP driver, that’s sure… I cant imagine a full-hard coded-C-style ONLY game omg, no no no… that will be confusing… So, resuming:
OGL2.0 —> C-style NON oop
Your App–> C++ oop style, OGL2.0 driver/wrapper with, if possible, display API independence
Originally posted by santyhammer:
[b]Ok here is my opinion about OOP…
The inverse operation is, obviously, impossible.
[/b]
I believe Performer is/was C++ internally but had a C API. This is easy to do by either having static objects that are implicit inside the C wrappers or by passing the object pointer (or handle) as the first parameter in the C call…
Also note polymorphism does not have any inherent runtime cost. Those are virtual functions (a result of inheritance) that cause v-tables to be used and even then, the cost has been greatly reduced with modern compilers. In other words operator+(int,int) and operator+(float,float) is resolved at compile time, not via virtual functions.
Anyway, I don’t think GL2 needs to be C+±based for the reasons we talked about before. The DLL issue is easier resolved with a C-only interface.
However, I do think GL2 should have an optional but official compile-time C++ layer to a) save us the work of writing this repeatedly b) provide type safety and c) to finally have a standard C++ base on which we can start building some interoperable OGL-ready libraries without having to deal with twelve different ways to write and use a vector class.
Avi
[This message has been edited by Cyranose (edited 01-26-2004).]
Allow my to rectify… Is possible to use C++ internally as you describe, BUT DOING a UGLY SHODDY WORK. Imagine:
Scene_Octree_Lightmapped_And_With_Collisions_Draw(camera)
Scene_BSP_VertexLighted_Without_Specular_Draw()
bah… Come on… I wanna scene->Draw() and thats all…
Scene_Octree_Lightmapped_And_With_Collisions_Draw(camera)
Scene_BSP_VertexLighted_Without_Specular_Draw()
scene->Draw()
None of these functions, nor anything that looks even remotely like them, belong in OpenGL.
Is only a C++ to C coding example korval…pfff
If someone seriously would like a C++ wrapper for the OGL2 bindings, they should write a program that reads in the <GL/gl2.h> file and transcribes each function call automatically to a new header file.
This is how I created an “openGL extension” (read OpenGL function bindings) for Ruby. It is possible to create language bindings to a C implementation for virtually every other language. (C++, Perl, Python, Ruby, Tcl could all have language binding created from the C header file).
Since every implementation of OpenGL from the SGI workstation, to the gaming console, to the home PC, to the cell phone and personal organizer, would need whatever run-time support OpenGL required. It should be in C, as it inheritantly requires little run-time support, usually for varargs, locales and sometimes floating-point operations. The last being the only thing it used. There are maybe 5 versions of C, (K&R, ANSI, ISO90, C99), but compiled code is interchangeable.
If C++ were used, every platform would need all the C run-time support and more, including RTTI(added a few years ago as a requirement), vtable stuff(multiple inheritance name/binding resolution, virtual function dispatch), name-mangling(C-names for functions, every compiler did this different, every change made to this would render all the previous compiled versions unusable), class and template export(which only recently started to work (more) correctly), namespaces(addional name-mangling). There are maybe 30 version of C++, and none(few) of the compiled code is interchangeable.