Function Pointers for Methods?
BlitzMax Forums/BlitzMax Programming/Function Pointers for Methods?
| ||
Type Tight Method Action() Print "Action packed!" End Method End Type Local WhatIsIt() ItIs:Tight = New Tight WhatIsIt = ItIs.Action WhatIsIt() WaitKey() End please tell me there's a way.. |
| ||
| This the same ? |
| ||
| damn it...this is going to hurt some of my intented design...:-/...man this sucks. |
| ||
| There are no method pointers at this time. You can get the function pointer to a function within a type, though, but it will be the exact same pointer for all instances of the type, and won't be instance-specific (you'd have to pass the object handle as a paramter). I wonder if it's because, you can have a pointer to a function within a type because it's tied to the type and not the instance, so if there are no instances of the type then the function won't work anyway, logically. So this way they can create the function at compile time and get a pointer for it. It doesn't change at runtime. With methods, you would be creating new functions at new addresses with each instance at runtime, and that would break because you could create a method, get its pointer, erase the instance and then still have a method pointer pointing to a non-existent method. If you then called it it would crash. You don't get that problem with the function within the type because it's one function shared among all instances and so can be predetermined - your code would have to be logically correct to compile so there are no loopholes. To have method pointers you'd have to have a way of getting rid of the method pointer when you erase the type instance, which means keeping track of which pointers are associated with which instance, which is quite a task. |
| ||
| Not needfully ... modern managed language avoid that by using agents / delegates, something like intelligent objects that do the "function pointer" thing in a safe way ... not the C++ hacker way. Hmm, this would be an interesting idea to see if I could get something similar like this into BM ... Will need some research but would definitely beeing worth trying it. |
| ||
Since methods are really just functions with an extra hidden parameter you can create a "method pointer" of sorts. SuperStrict Type Test Field x:Int Function dummy(i:Int) EndFunction Method get:Int() Return x EndMethod EndType Local t:Test = New Test Local p:Test = New Test t.x = 5 p.x = 17 Local methGet:Int(o:Test) Local temp:Byte Ptr = Test.dummy methGet = Byte Ptr(Int(temp) + 12) Print methGet(t) Print methGet(p) Of course it defeats the whole purpose of havimg methods since you can't use the nice dot syntax. Not to mention asking for a couple hundred unhandled memory exceptions |
| ||
| haha, there's a point to my madness. It really would have allowed for some flexiblity in my design. Having to put the object in the function makes things more compliciate and almost..just almost defeats the purpose of not being concerned with the function is or came from. |
| ||
| the odds of bmax recreating new instances of program code for every method are next to zero - typically one code block is created and all intances of objects use that block..the "this" pointer is then passed to method - so the method can interface with the data - only fields that are none global will be generated for each instance of the object.. Well the truth is, i dont know how bmax works..but im guessing its similar to this. |
| ||
| Thats the problem: Methods are not global, they are per instance. Only functions are "global" (to a type) |
| ||
| yes methods are not global - thats why i said the "this" pointer is passed to them - the fact that they are not global does not mean multiple identical code blocks exist in memory..the reason you cannot access them, is beacuse they themselves access data that is local per instance data...it make no sense to have a function pointer to a member function..unless a mechanism exists for linking it to a specific intance..and blitz doesnt seem to have any machanisms for this.. Think of member functions as being pointers to functions, and that function existing in one place in memory + accepting a "this" parameter. Only when an object is created is its pointer for this method linked to the method code...without an object, the method has no meaning. If i create an intance + try to grab the method for use as a function pointer..im in effect grabbing code blocks address...now even though i accessed this block through an instance..the code block itself know nothing about the instance it was linked to... erg..this isnt fun to explain..time for sleepings |
| ||
| The problem is: Adresses do not exist in a managed environment. Only references exist and references MUST (not can) be handled and taken care of as there are some things they must guarantee (like type safeness and the like), which is why other managed languages have delegates (think of them as an intelligent objects for a function pointer). As long as you think of pointers as pointers within BM, it never can work, it would mess up with the GC. Thats why we would need delegates ... But because of their inner working, they would need to be nested in the innerst working which is definitely an extreme task ... |
| ||
| Meh, I think you're both right. Anyway, I can't think of a situation where delegates would make life a whole lot easier. Most of the time a function pointer wrapped in an object works well enough for me. |
| ||
| Anybody know how much memory instances of methods take up? I've been wondering of i should be using more functions for cases where i can. |
| ||
| Methods aren't created on a per instance basis. A method is simply a function with an extra hidden parameter which is the instance of the object being passed to the method as the Self identifyer. After the code has been parsed and broken down enough there isn't any difference between Method aMeth() and Function aFunc(_Self_:ThisType) This is what Defoc8 was trying to explain I beleive. |
| ||
| Thats why we would need delegates ... But because of their inner working, they would need to be nested in the innerst working which is definitely an extreme task ... The problem is that without them, EventHooks are almost useless. Method aMeth() This isn't quote accurate. The Method would be typesafe, the function is not (ie. you can invoke it with any type os ThisType) and Function aFunc(_Self_:ThisType) |
| ||
| And where it the problem? It is still of this type (even if it is an extended, this makes no difference, the core functionality is the same as ThisType which is needed) and because of that TypeSafe. |
| ||
| Yes FlameDuck, your statement doesn't quite makes sense. Can you elaborate? |
   |