There has been some talk recentrly on how to inter work between C++ and
other languages and that gave me an idea for a small/simple extension to C++
(or any other language that uses name mangling) basically all we need is (yet
another) a new keyword (or two), such as:

equivalence <function prototype> <string>;
and
equivalence <string> <function prototype>;

or

export <function prototype> <string>;
and
import <string> <function prototype>;

This would basically insert equivalences between the C++ mangled function name
and the "foreign" name into the output allowing either C++ to be called from
the foreign language (note the start up routines for C++ static info should be
exported this way by the compiler vendor) or the foreign stuff (which might
include characters not in the C/C++ implimentation set) to be called from C++,
boy we could even call stuff that was compiled by a different C++ compiler!
(Nah, the call sequence would probably change!).
 Alternatively to just putting a

 C++function_name = foreign_name

record into the outgoing object it might produce a "vector" this might then
allow exporting of symbols from shared library or other such clever stuff
without resort to assembler. By vector here I mean a short piece of code that
allows you to tranfer the address of the routine from where it really is to a
aknown area so that when a shared library is relinked you need not re-link all
the applications which depend on it -- this would be a highly OS dependent
function, but portable sort of! (Yes I know it is a decorated JUMP!)

Problems:
1) can most linkers handle this? or we the compiler have to produce
 vectors all the time?
2) would it be useful or do most architectures/languages have their own
 call sequences so precluding multi-language programmes without lots of
 little assembler "glue" routines? I know each compiler vendor on the
 IBM PC has their own calling conventions (and usuall several).
3) Would it be too difficult? It looks very easy to me...but what do I
 know? I've tried to keep it deliberately simple, just 1 keyword (per
 statement), a function prototype (known parser/name mangler technology)
 and a string (this allows really wierd ex/imported function names),
 which is again simple to parse, then hopefully the "code" generation phase
 would also be very simple.
4) I suppose there is no chance (tm) of getting the ISO C++ committee
 to consider this?
5) Would enough people find it useful? I know you gan get at least some
 (most?) of this functionality with extern "C", if you known soon enough
 and/or have access to the sources -- this functionality allows you to
 interface more languages at a later stage in the design cycle and
 without any of the sources(???I hope) you just build a little "kludge"
 module and relink!
6) Any other obvious problems that I've missed?

 Just a thought I had while walking the dog
   Rod B.

Usual disclaimers apply, etc. My sig has a complex number of lines, use your
imagination!

This is what the extern "C" mechanism is supposed to do.  See 4.4 of
the CPL manual.

---------------------------------------------------------

 Scott Johnson                   "Dependance on wizardry
 Digital Equipment Corporation    to mitigate the fundamental
 Colorado Springs, Co             limitations of software is
                                  called 'hacking'." Grady Booch.