IOW, the pointer to Xyz must equal the pointer to Abc and, pointers to both must be obtainable.Not sure me understand rest you write but answer quote is have keyword "absolute" and make do.
understand rest you write but answer quote is have keyword "absolute" and make do.
The absolute keyword can be used only to declare variable. So if you want to declare function in this way, you need to get the procedural variable or constant and declare your own that will point to the original one. Something like this:Yes that correct. I add example later for see.
Not sure me understand rest you write but answer quote is have keyword "absolute" and make do.
@440bx: to be able to pass different functions with the same parameters list and the type of the result, you can declare a procedural type and use it to declare a parameter in the function import.Yes, using a procedure variable would definitely be a way to create an alias for a function/procedure.
...Is pitty but i not know if make better language Pascal if have. Time is telling ? :)
But it is a pity, however, that type inference is not supported in such cases and the following declaration is incorrect and can not be compiled:
If you want to define aliases, use the "alias" modifier; the following defines fopendir, exports it as FPC_SYSC_OPENDIR and reimports it as fpopendir2Reimporting it... that's a good idea, I like it.
Slight discretion advised, do not overuse. You pollute the global namespaceYes, definitely. Not to mention that, likely, both the Import and Export tables of the executable get larger and larger.
Alternatively you could use a macro.That's a good idea too. I have a tendency to forget that FPC does have a simple macro facility. It has the advantage of not cluttering the exe's import and export tables with potentially misleading data.
If it isn't imported from a library why would it be in the Import and Export tables?Slight discretion advised, do not overuse. You pollute the global namespaceYes, definitely. Not to mention that, likely, both the Import and Export tables of the executable get larger and larger.
If it isn't imported from a library why would it be in the Import and Export tables?I have no doubt you know the internals of the FPC compiler better than I do, therefore, I will take your word for it. The presence of the keyword "external" gave me the impression that it could end up in the exports and imports tables. Your point that without the keyword "exports" that doesn't happen makes sense.
Only those with export modifier or in the exports section are put into the Export table and only those with external <LIBRARY> or external <LIBRARY> name <FUNC> are part of the Import table (and the suggestion by marcov is external name <FUNC> which has a small, but in this case significant different meaning due to the missing library name).
On the other hand, doesn't it end up creating symbols for each alias in the DWARF/Stabs debugging symbol tables ?Yes. But that is probably what you want:: the debugger making a choice between any of whatever you aliased.... That's commonly known as DWIM and not yet achieved by human kind. ::) ::) ::) ::)
YOU should think first,You occasionally manage to have such profound insights as to reach the obvious. Impressive!.
let the compiler think. This will stay so for a very, very long time...(In my opinion... O:-) )that sounds right... waiting for the compiler to think probably involves a "very, very long time...". Very insightful of you.