🚀 go-pugleaf

In article <1995Aug9.101606.1434@ittpub>, Wil Evers <wil@ittpub.nl> wrote:
>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.

I think that we're agreeing here.

If the standard says that extern "C" and extern "C++" function
pointers can't be freely intermixed, then the standard should provide
an easy and convenient way for me to express what type of linkage the
function has so that the compiler can check these silly things for me.
Also, I want to be able to write code that I don't have to resort to
the hack of

extern "C" void foo( int, int );

void foo( int a, int b)
{
	...
}

or even sillier hackes when it comes to the typedef examples that I
gave earlier.

extern "C" right now is fundamentally different than anything else in
the C++ type model.  const, volitile, et al can appear anywhere they
are for that type.  However, extern "C" can appear only in a very
limited number of contexts that limits its use and makes it harder to
write a type safe program.

I do understand that if extern "C" works or not is a different issue.
The language must say that if external linkage "X" works, and the
linkage is part of the type, then this call is safe or that call is
not safe.  If external linkage "X" doesn't work, then a compiler
diagnostic should be required.

I think the other issues raised can be delt with easily, but it will
take time to work out this dark corner of the language and I fear it
may be too late for the standards process.

Warner

-- 
Warner Losh		"VMS Forever"		home: imp@village.org
Cyberspace Development, Inc			work: imp@marketplace.com
Makers of TIA, The Internet Adapter.		http://marketplace.com/