PureBasic Forums - English

Good Day,

I don't know where is my error:

acreis wrote: Mon Oct 06, 2025 3:22 pm Good Day,

I don't know where is my error:

Code: Select all

Prototype proto_void()

Declare MyFun(sString$, *ptrFunction.proto_void)

Procedure MyFun(sString$, *ptrFunction.proto_void) ;Declare doesn't match with real procedure
  
  
EndProcedure

Do not use a pointer. Prototypes are defined without pointer * character.

Thank you very much!

I've always used *ptr.prototype as a parameter as it's used to denote that it receives an address to a function of the prototype. It also explains why one of my include files doesn't compile anymore as the ide makes the check but the compiler doesn't and I was very confused and being dyslexic I cant see the differences of which there wasn't any.

I really don't get the logic behind forbidding it as it makes no difference as far as the compiler goes and make a big difference to users of a lib so they know that they're supposed to pass in the address of their function.

Huh?

Prototypes (according to help) are "a way to EXPLICITLY declare an external function"…
…that's mostly win stuff…

But they can be useful to process "global data" with "variable" runtime procedures, by calling the right procedure by name (or passing the name as parameter)…

Am I wrong? I feel like if I just wrote a complicated "pineapple pizza"

A prototype is a description of how to call a function so the compiler knows how to execute it.
In my recent display list tip it uses prototypes in a structure union to dynamically call the native functions via a raw untyped pointer which is cast to the prototype automatically rather than using a bunch of selects, there's 60 odd functions in it.
prototypes are generally accesed via pointers so why shouldn't they work as parameters to a function.
*pfn.doit is clearer than pfn.doit as a parameter the pointer is a hint to the user, pfn.doit suggest it's a structure but we can't pass structures to procedures
So it makes little sense to me and should be considered a bug because it's technically a pointer to a function.
I'm not sure when it was changed but it did my head in when I saw the error message as I was compiling the project fine and it was only when I tested the file that included the file that it popped up the error.
So yes pineapple pizza indeed

idle wrote: Wed Oct 08, 2025 11:51 pm I really don't get the logic behind forbidding it as it makes no difference as far as the compiler goes and make a big difference to users of a lib so they know that they're supposed to pass in the address of their function.

In the procedure definition *foo.bar show you that you have to pass a pointer to a structure,
foo.bar show you that you have to pass a function, because foo.bar is not allowed, if bar is a structure.

Inside the procedure *foo is highlighted as pointer (to a memory or structure).
foo() is highlighted as a function, because it is callable, while *foo() is highlighted as a pointer, and looks also kind of wrong to me.
Don't you define DLL functions also without * ?

I just think it's ambiguous and prefer to use them as pointers in parameters.
The behavior changed with PB 6.30b1 but either way there's a bug as it doesn't fire the error if the include is nested as in main.pb -> inc1.pbi -> inc2.pbi which contains the offending *pfn.CBFunction as a parameter.
Also if the function isn't declared there is no problem.
So it's a bug but should it be enforced or not, I'm on the not side here, as I use it all the time.

I will take a closer look

Fixed.

Thanks Idle (also for the Vector drawing display List thing!) and all; use of prototypes is more clear for me now! (I also erroneously thought that "calling runtime procedures by name" was more limited )