[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: External (C++) interfaces
> I also would like to define some interfaces to C++ classes.
>
> Umpf. I don't have much experience with C++, but someone told me that
> C++ uses the standard C linker to put programs together. That means
> that C++ maps any function (even overloaded ones) to a unique name.
> This is (probably) accomplished by converting each function parameter
> (ie, its type) into a string and appending them to the functions name.
> You would need to know the scrambling function that builds the linker
> names. I don't think that this function is the same for any two
> different C++ compilers.
This is from the manpage for 'demangle' from the GNU binutils:
--format={gnu,lucid,arm}
GNU nm can decode three different methods of mangling,
used by different C++ compilers. This option selects
which method it uses: the one used by the GNU compiler,
the one used by the Lucid compiler, or the one
specified by the C++ Annotated Reference Manual. The
default is the GNU style.
Since the ARM seems to have specified a specific 'mangling' algorithm,
perhaps ANSI have adopted it?
> I'm not so keen on language extensions. If we start a discussion
> about it: I have two pet extensions of my own (concatenation of string
> constants and interface types a la Objective-C)... ;-)
I would also hate to see any language changes. I'm sure we all
have our own favourites, and its great fun thinking about it,
but for obvious reasons: just say NO.
OTOH If Michael got to mention his pet extensions I want to mention
mine ;-)
From Oberon-V:
remove LOOP..END
enforce side-effect free functions
remove structure assignment
clarify (and simplify) the type-extension concept
From 'Metaprogramming In Oberon':
Specification and static enforcement of abstract type-bound procedures.
Allow comparison of PROCEDURE variables.
Also, perhaps we can optimize away the WITH statement, and allow
dereferncing of function returns.
etc....
OK, I'll stop wasting time.
Guy.