I’m sorry I’m bothering but I need this for a test:
what are these callback routines? What do you need them for? What are they doing?
TIA,
Matti
callback functions are outdated, since we have virtual functions in OOP, but are still commonly used, due many programmers ‘abuse’ their c+±compilers as plain c-compilers (e.g. directX cough witch IS OO, BUT sometimes uses callback, typical M$-crap)
but now to your question:
best way to explain is a exsample:
GLUT uses callback-fuctions, so u code a function that paints your scenery (with glbegin, glvertex, glcolor and all the nice stuff)
now u take the address (pointer) of this fuction and pass it to GLUT
GLUT manages all the stuff (e.g. creating the window for your openGL-app) and everytime your scenery has to get repainted it CALLs BACK your drawing function, to do so.
so callback functions are simply functions, which get … ehm, well … called back (normally by a library) to perform something
'hope i explained well (;
[This message has been edited by Tron (edited 06-29-2001).]
Thanks a lot, your explanation is very helpful!
Originally posted by Tron:
[b]callback functions are outdated, since we have virtual functions in OOP, but are still commonly used, due many programmers ‘abuse’ their c+±compilers as plain c-compilers (e.g. directX cough witch IS OO, BUT sometimes uses callback, typical M$-crap)
but now to your question:
best way to explain is a exsample:
GLUT uses callback-fuctions, so u code a function that paints your scenery (with glbegin, glvertex, glcolor and all the nice stuff)
now u take the address (pointer) of this fuction and pass it to GLUT
GLUT manages all the stuff (e.g. creating the window for your openGL-app) and everytime your scenery has to get repainted it CALLs BACK your drawing function, to do so.
so callback functions are simply functions, which get … ehm, well … called back (normally by a library) to perform something
'hope i explained well (;
[This message has been edited by Tron (edited 06-29-2001).][/b]
Originally posted by Tron:
callback functions are outdated, since we have virtual functions in OOP, but are still commonly used, due many programmers ‘abuse’ their c+±compilers as plain c-compilers (e.g. directX cough witch IS OO, BUT sometimes uses callback, typical M$-crap)
As old as the notion of callbacks are they are far from obselete and still have an important place in the programming even if you are developing in OOP.
Here is my side of the coin: callbacks and over-riding virtual functions solve different types of problems.
Callbacks allow customization to a system AFTER the system has been compiled together. You compile your routine into an EXE. When the EXE and system are run together, your EXE informs the system of your routine’s address and you’re done. In other words, you do not need the system’s source code for your routine to work.
Over-riding virtual functions, on the other hand, is to allow customization to a system DURING development. Over-riding is only possible during development because you need to compile your class along with the system’s source files for the over-ridden routine to be called. In other words, all source files must be in hand (or at least the system’s OBJ files).
So what’s the problem you say: why don’t we just do all customizations by compiling our over-ridden classes with system source files? … because 99.99% of systems are released to users as DLLs & EXEs and not as source code. Examples are Photoshop and WinNT. It would be impossible to pry the source code from Adobe just so you could do a customization. Instead Photoshop provides a documented way of submitting your routine without messing up Photoshop code. Just think of all the versioning problems this prevents.
Don’t ignore a tool just because it’s associated with a company that spews a lot propaganda. At the same time choose the right tool for the job.
I hope my response comes in time for your test.
[This message has been edited by Frumpy (edited 06-30-2001).]