Ah yes? All callbacks I worked with involved function whichs specs were defined roughly but not implemented yet. The proceedings involved writing this function and supplying a pointer to it to the already existing code. No?
Rene
"Steve at fivetrees" schreef in bericht news: snipped-for-privacy@nildram.net...
90% of the responses were pretty much okay. That is not 'Full of misinformation'.Of course you don't bother to give any meaningful response yourself. Like the majority of CAE, bunch of arrogant, boring wannabees as they are.
-- Thanks, Frank. (remove 'q' and 'invalid' when replying by email)
I'd say yes, now that you described it a bit better.
-- Thanks, Frank. (remove 'q' and 'invalid' when replying by email)
Granted. However the 10% were fairly forceful ;).
CAE? not sure I know this >> A callback is a function call to a fuction that at design time does not
yet exist.
Yup. I'm still talking of static storage but thinking of linking.
-- Best Regards, Mike
It's actually a lot more true than you believe. Rene may have condensed its essence down to a little too few words for you to recognize it, but he did get it right.
Correct, but that's not the issue at hand. We're talking about the not-yet-existing implementation of a _called_ function, not its caller.
To rephrase Rene's statement: a callback is what you use if a function 'foo' needs to be written now, which has to call another function 'bar' that may not exist yet. More importantly, different calls to 'foo' may want to use different functions 'bar', at least some of which aren't written yet.
So you declare the interface signature of 'bar', and make a pointer to a function of that signature (or, in OO, an object implementing that interface) part of the set of arguments passed to 'foo'.
The central aspect that makes this a good idea (compared to other methods of selecting a function to call from a collection, e.g. an index into a table of function pointers, or a switch() between a lot of function calls), is indeed, as Rene pointed out, that it lets you split up "compile time" into at least two separate phases, to be carried out by different people, at different places and times: one is the compilation time of 'foo', the other the (potentially lots of) compilations of 'bar', and also of the function that calls 'foo' and passes 'bar' to it.
But an empty function is not part of this design --- there's just the prototype, and a *pointer* to such a function. But no actual implementation of any such function is involved in this design pattern named "callback". That's how you can implement the pattern, without having any implementation of the actual callback function at hand.
-- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
"Steve at fivetrees" schreef in bericht news: snipped-for-privacy@nildram.net...
It's right under your nose. You are posting in it ;)
I have to admit I misread his post first too, thought for a moment he was talking about stubs or something. But imo he was as close as it gets.
OTH, what's in a name. All too often we see old wine in new bags.
simplest
afrom
Perhaps I am misreading here, but this sounds not at all as callbacks. More like down to earth routing of objects to their specific handlers.
astatic
I don't know ;) It's getting hairier.
-- Thanks, Frank. (remove 'q' and 'invalid' when replying by email)
call
Not as I understand things. Static linking is when you satisfy all external references at compile/link time, incorporating all the library routines right into your bound executable. This generally makes for quite large (megabytes) executable files, but also means that the executable contains everything necessary to run. This means people wont have to install a bunch of libraries to be able to execute it.
This is as opposed to dynamic linking where external references are satisfied at run-time. This is done in windows with DLL libs or in Linux with .so libs. The executable file only contains references to the desired routines and acceptable versions (aka stubs); a dynamic linker pieces it all together just in the nick of time. The dynamic linker is part of the OS. This tends to make the executables much smaller as all that's in them is the core code of the application and a bunch of external references (not to be confused with object files).
There is no mandate of recursion or re-entrancy other than that dynamic library scenarios are typically done in a manner to support a single resident copy of the code segment even with multiple threads simultaneously executing.
Statically linked programs would usually lead to multiple copies of the same code being in memory when multiple occurrences of the program are in execution. It's also possible that the OS might handle two occurrences of the same executable by using one mostly shared copy by implementing copy-on-write to clone pages as necessary.
I guess that's my 2cents anyhoo. ;-)
Ho hum. I gave the terminology twice already. That is not a definition, it is a deeclaration.
I also gave the definition of a callback function and it has absolutely nothing to do with whether the function is implemented (defined) or vaporware.
Way off. The WinMain function (like main() in a DOS app) is the application entry point which actually calls a WinMain function from the CRT lib which has more parameters that you don't see.
^^^^^^^^^ wtf?
No. CreateWindow() and CreateWindowEx() are called to create a window and the WndProc callback address is passed as a parameter.
No. The OS calls this function when it needs to pass a windows message to the WndProc so the user can process it. Every window in an app has it's own WndProc.
-- Best Regards, Mike
No, it's my fault. I should have remembered that embedded programmers and electrical engineers never talk.
John
Yeah, this is snipped from the "tutok" web page you referenced...
MemberTranslator1(Callee &c,const MemFunc &m): Functor1(thunk,&c,&m,sizeof(MemFunc)){} static void thunk(const FunctorBase &ftor,P1 p1) { Callee *callee = (Callee *)ftor.callee; MemFunc &memFunc(*(MemFunc*)(void *)(ftor.memFunc)); (callee->*memFunc)(p1); } };
OK, imagine trying to understand and maintain 100 millions lines of code like this. If you passed it through triple-DES encryption, it couldn't look much worse.
John
Yes, PIC is more common it seems. I come from the less popular GE/Honeywell/Bull background. Actually, the GE part was a little (and I do mean little) before my time.
You are right, of course. ;-)
What normally would be defined is only the function title and type ; void mycallback (int,int,double);
then as long as the function mycallback accepts the correct variables and returns void it would be entered later.
Windows uses this for the WinMain function in a basic C program, Windows is given a function name in the Window definition often called WinProc() windows then access that procedure rather than Main() to run the program.
Charles
[...]
Yes, assembly rocks. High level languages don't let you see what is actually happening in the registers, so you miss good ways to optimize the code. Although I prefer to let a good HLL to handle most of the interface stuff, and focus my attention on the places where assembly can really pay off in performance.
Another thing - it's amazing what can be accomplished in a few hundred bytes of assembly. So how on earth can Windows consume hundreds of megabytes to do basically the same thing? I mean, when a printer driver requires 600 megabytes, something is seriously broken. There's no way a cpu could be executing all that code all the time - in fact, there is nothing that could possibly be that complex. So what is the reason for the bloat???
Best,
Mike Monett
Correction, you mean *link* not compile. I have made quite a few libraries that compiled perfectly fine using callback functions that did not exist. Some of them were dynamic link libraries where the code that contained the callback calling code never knew of the existance of any particular callback function at compile time. Typically I would implement callback interfaces to have both a callback function pointer and an instance variable. That way the client code that contained the callback could have multiple instances usually implemented as a C++ class. The instance variable would be a void* to the library, and the client could cast it back to whatever it wanted, which was normally the "this" pointer for whatever class type it happened to be.
Frank Bemelman wrote: [...]
That number is getting smaller as the thread gets longer.
[...]
Ah. Touché.
Hmmm. Will read again. I also thought he was talking about stubs. It's not at all impossible that I'm missing something.
I'm with you. I've re-read my own definition, don't like it much, and am regretting getting involved ;).
Which returns me to the deliberate brevity of my first post. What *is* going on here? This thread has redefined not only callbacks, but "static", re-entrancy, and the value of Pi [1]. The guys here in comp.arch.embedded usually really know their stuff... ("bunch of arrogant, boring wannabees as they are" ;).) Are we being cross-contaminated by sci.electronics.design? Is it all their fault? [2]
[1] I lied about Pi. [2] Our newsgroup is better than yours. Rrrrrasp!!Steve
I wouldn't call it a callback. If you are instancing a bunch of objects, you pass them a function (java-method) pointer (java-instance variable) so they can activate a function in the instancing routine.
For instance, I have a software scope, I push a button to instance a plot, and pass each plot-object an instance of a trace object-variable (pointer), and a handle or pointer to the main scope program which refreshes it.
What your talking about sounds like a flag. Unless you are doing object-oriented programming on microcontrollers =)
Isn't that called an interface? Aren't MS COM objects (such as dhtml Active-X objects) an example of such? The COM object interface are pointers to an object-specific array of pointers.
100 million lines? Sad, but Windows is probably getting close.
I think part of the reason for code bloat is programmers have no restrictions on their code size or performance requirements. They should be given 200MHz Pentium computers with an 8 gig hard drive and 64 megs of ram. That would fix slow, bloated code real fast.
For example, my editor uses Borland SPRINT, which was last released in 1988 and was designed to run on an 8080 with 640k of ram. It handles 11 different types of files, including html, plain ascii, pascal, c, assembly, email, newsgroup postings, google groups, etc.
It can load up to 27 files simultaneously and automatically detects the file type when switching from one window to the next. It switches the command functions as appropriate for the type of file, so I don't have to memorize different commands and keystrokes depending on the file type in the current window.
The editor is very compact and and loads instantly. It rarely crashes, except when Windows crashes on a bad pointer and messes up memory. It is blazingly fast on a 200MHz Pentium, so there is little need for a 2GHz machine (except to read those #$%@&* Adobe pdf files:)
Of course, this style of thinking would probably put a lot of programmers and maybe some companies out of business. For some strange reason, making things overly complex is good for business.
Best,
Mike Monett
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.