🚀 go-pugleaf

In article <406nqo$2ul@rover.village.org> imp@village.org (Warner Losh)  
writes:
> In article <4068ab$o58@senator-bedfellow.mit.edu>,
> John Carr <jfc@mit.edu> wrote:
> >Linkage is part of the type of a function (and therefore a function
> >pointer type includes this information).  A "C" function can be called
> >just like a C++ function except for overloading and possibly default
> >arguments.
> 
> I have two objections to this.
> 
> First, how do I declare a type that is a pointer to an extern "C"
> function that returns void and has no args?
> 
> extern "C" { typedef void (*fp)(); }
> 
> or
> 
> typdef extern "C" void (*fp)();
> 
> The second form gives me compiler errors.  I'm fairly sure that it
> isn't allowed by the current grammar, the couple of quick compiler
> tests show that no one accepts it.
> 
> The second is realted.  This would be the only type specifier that
> applies only to functions, and its expression is non-orthogonal to the
> rest of the language.  Since you can't easily declare these beasts, it
> becomes much harder to use them.

[snip]

Please note that even if pointers to functions with extern "C" and extern  
"C++" linkage could safely be assigned to each other, the syntactic  
problems you mention remain. Requiring a C++ compiler to use the same  
calling conventions for both extern "C" and extern "C++" seems technically  
feasible, although it may be difficult to express this in standardese.

But what if a compiler vendor decides to add support for extern "Pascal"  
to provide linkage to a large collection of routines written in that  
language? If this is to have any real use, it seems highly unlikely the  
calling conventions for extern "C++" and extern "Pascal" can be the same.  
Therefore, I think C++ should provide a mechanism to express pointers to  
functions with foreign linkage.

- Wil