what's a callback?

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

Reply to
Rene Tschaggelar
Loading thread data ...

"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)
Reply to
Frank Bemelman

I'd say yes, now that you described it a bit better.

--
Thanks, Frank.
(remove 'q' and 'invalid' when replying by email)
Reply to
Frank Bemelman

Not even remotely true, let alone possible to compile. The function

*must* exist, however you can select a function and pass a pointer at runtime.

You can't even compile a function in C++ without an implementation.

I think there's a terminology problem, here.

Prototype:

Function(int num, double, mag);

Definition - this is implementation:

Function(int num, double, mag) { // some crap code - or none at all return num; //default return is int :) }

Even an empty function is an *implementation* of a function.

I can write:

call bogus_pointer

for PIC and as long as there's a label "bogus_pointer", it'll go there. That's an implementation. But that doesn't mean it won't execute right on past the return that I forgot to include and f*ck everything up.

So I include the return stmnt and everything's fine.

But to get back OT :) a good example of a call back is the function pointer that must be passed to the "CreateWindow()" function in winders API. It's the "WndProc" function in the prototype.

When winders OS needs to send a message (you clicked the little "x" in the text editor) to a window it calls that WndProc function with a handle to that window.

The callback can be static, i.e., it is shared by all processes calling it.

The neat thing is that in the WndProc function, you can create a controller object that stores (via SetWidowsLong(hWnd, ...) you pass the window handle to identify which window) a pointer to itself in the window's reserved data space.

Now the callback can access the controller object for that particular window (say you have 2 text edit windows open in the same app) and check whether you saved that text file yet. Or whatever.

But f*ck all that noise. Just use wxWidgets ! :) That's open source and cross platform and used by major corps.

-- Best Regards, Mike

Reply to
Active8

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.

Reply to
Steve at fivetrees

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.
Reply to
Hans-Bernhard Broeker

Something has to be declared or it won't compile. I know, that's not a definition, just a generic function pointer. As you go on, it becomes more clear what you're trying to say (I practiced this same excersize with Kevin :) ) so don't feel compelled to comment on all my comments.

That's called function overloading and another way is polymorphism.

You can't *link* a function call to a function with no definition, If it's *declared" in a header or somewhere "in scope", it will

*compile* but if the definition hasn't been written, the linker won't find it's entry point in any modules and it won't *link*. But that's not a generic function pointer I'm talking about.

IOW, you can't assign a *valid* pointer at runtime unless the function is defined somewhere.

pfunc = atan;

won't work if the linker can't find atan.

pfunc = NULL;

pfunc = atan;

function(pfunc);

groovy, now hit "execute".

As I said, I can pass any bogus pointer in a function. The fact is, that function must have been defined (implemented) somewhere or it won't link. At design time, not run time. You can grab a valid pointer at runtime, but there *will be no valid pointer unless the function was implemented and compiled in a module that the linker can see.*

Period.

None of this changes the fact that it won't link. Won't even compile without a declaration.

function(void){}

void (*pfunc) ();

function(pfunc);

This will compile and link, but if you run this code, you have to assign a value (address) to the function pointer pfunc and you can't get that address if it's stilll vaporware.

None of this changes the fact that this ain't the definition of a callback function.

This is funny. I just typed __define callback function__ into google and didn't get any returns about phones.

formatting link

A callback function is one that is not invoked explicitly by the programmer; rather the responsibility for its invocation is delegated to another function that receives the callback function's address.

Period.

where's the linker gonna get the damn valid pointer from, it's ass?

Good. Now click "Execute". Oh. You're waiting on another group to implement your function? So you wrote what's known to me as a "stub". You could just as easily write an empty function if you don't need the flexibility of function pointers.

say

func(){}

function(func);

and the function "function" will get the pointer to func and execute it as a "callback". It's still a callback regardless of whether it's implemented.

- Best Regards, Mike

Reply to
Active8

Like when the code executes it. You're talking about an event with a callback. Normally you wait on that in a thread callback function.

Example: My sound recorder/scope. The soundcard API funcs set an "Event" when there's data ready. I passed the address of a callback to whatever it was. The callback function (I wrote) sets an event and my processing thread (also has a callback) deals with the data when it returns from WaitForSingleOblect(my_event_handle) . I think I used an unneccessary indirection there, but wtf?

It would have been better to get a handle to that event and just wait on it in a thread callback.

pass the thread callback func pointer to the API func.

then in my thread callback:

WaitForSingleObject(HANDLE event_handle);

But you need the event handle. So I set my own event in a separate callback. Oh! I can't pass the thread callback to the api because it gets called when the thread is created and the thread terminates when the callback function returns.

Thanks for the refresher.

--
Best Regards,
Mike
Reply to
Active8

That's called static linking.

--
Best Regards,
Mike
Reply to
Active8

Reentrant code means that a program can have more than one thread executing concurrently.

formatting link

--
Best Regards,
Mike
Reply to
Active8

"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

a

from

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.

a

static

I don't know ;) It's getting hairier.

--
Thanks, Frank.
(remove 'q' and 'invalid' when replying by email)
Reply to
Frank Bemelman

Right. As opposed to "absolute", IIRC.

"Static" referes to local variables that retain their values between calls. Static linking of a function (declared in a class declaration) means that all instances of that class use the same function at the same location.

My def?

Reentrant code means that a program can have more than one thread executing concurrently.

formatting link

Eh? Kinda general really.

If you do something to modify a variable and another thread executes the function it may or may not get a valid value. First, "concurrently". It's an illusion for a single processor system. They get a time slice. But when the threads pause, the code where execution left off is reentered.

--
Best Regards,
Mike
Reply to
Active8

Ah. Thanks. I didn't stop to think that templates are the way to deal with unknown return types. Problem is that you can't actually use that kind of function without passing the type as a template parameter.

I had a prob with a template in a dll. It wouldn't link because the implementation wasn't there.

Like

dll header template class MyClass{}

The program wouldn't link because there was no implementation.

I couldn't declare

MyClass myClass;

--
Best Regards,
Mike
Reply to
Active8

My illustrative example is a cooking school. One big recipe is posted on the wall, and lots of students are reading it and cooking, each at their own pace. They maintain their own local variables, the stuff in their pots. The code remains pure as long as nobody splashes anything on it.

John

Reply to
John Larkin

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. ;-)

Reply to
Anthony Fremont

Good grief, but that's hairy stuff. No wonder Windows is such a flakey pos. Makes me glad I program in assembly, where everything's in plain sight.

As I now recall, the first time I encountered the "callback" concept it was in a realtime assembly-language app. If an ISR didn't have time to finish something, it poked a pointer to the "rest" of its code somewhere and let the RTOS execute that later when resources were available. DECs later OSs (RSXnn and VMS, I think) had a "fork" facility that was similar.

John

John

Reply to
John Larkin

Yup. I'm still talking of static storage but thinking of linking.

--
Best Regards,
Mike
Reply to
Active8

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. ;-)

Reply to
Anthony Fremont

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

Reply to
Charles W. Johson Jr.

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.

Reply to
FLY135

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.