RE: cdecl support
Robert Craig wrote:
> Andy Serpa writes:
> > How would the long-term solution be different from
> > this "quick hack" -- isn't that all we need?
>
> I'd like to do some research before I implement
> a solution to _cdecl. For instance, I'd be happier
> if Euphoria could detect the need for cdecl, rather
> than having the programmer worry about it.
>
> Adding "quick hack" solutions to a programming
> language is easy. Removing those quick hacks once
> people start to use them is extremely difficult.
> I don't want Euphoria to accumulate a lot of quick hacks
> that are later made obsolete when a better solution
> is implemented.
>
The technical term for what we're talking about is the "Foreign Function
Interface" for the language, a term I learned when I was trying to
figure out how to get around this. (Just do a search on that phrase to
learn more.) I checked on how some other languages handled it, and
although there are some function naming conventions that often indicate
the calling convention of a foreign function, you can't count on them
definitively. In the description of their FFI for all the other
languages I found, specifying the calling convention is always done by
the programmer themselves, so I get the impression dectecting it
reliably is dicey.
Plus, not detecting it actually has one advantage: adding support for
any other calling convention besides cdecl could be done under the same
framework, simply by adding another legal value to the parameter that
specifies the convention...
|
Not Categorized, Please Help
|
|
