Optional name mangling
Stuart
stugol at gmx.com
Mon Jul 23 06:02:53 PDT 2012
On Monday, 23 July 2012 at 06:44:22 UTC, Walter Bright wrote:
> On 7/22/2012 6:12 AM, Stuart wrote:
>> Okay, but if you had a keyword - say, "extern(rawC)" - that
>> did no mangling
>> whatsoever, then I could run implib without manually editing
>> every single damn
>> line in every Microsoft .def file by hand!!! Surely that's a
>> good idea?
>
> I agree, it's a pain, and a pointless one at that.
>
>> I don't know why implib is ignoring the /s switch, but it is.
>> My .lib file
>> doesn't have underscores, and there doesn't seem to be much I
>> can do about it.
>> Do I need a different version of implib or something?
>> Shouldn't the /s switch
>> add underscores to everything?
>
> There's no magical way for implib to figure out what the nn in
> @nn must be.
Granted, but IMPLIB IS NOT PREFIXING THE NAMES WITH AN
UNDERSCORE, even when used with the /s switch. Hello? Houston? Am
I getting through?
In any case, adding support for importing unmangled function
names in D would help in these cases; and also allow us to import
unmangled functions that were exported from C using the "extern
C" instruction in C++.
Correct me if I'm wrong, but isn't it only C++ that does
mangling? As I recall, straight C doesn't support overloading and
doesn't mangle names. Therefore, I reckon your "extern (C)"
instruction ought instead to be written "extern (C++)", and a new
"extern (C)" should be introduced that does no name mangling.
Alternatively, I may be wrong, but even so, a non-mangling
keyword would be helpful. And surely it wouldn't be difficult to
implement?
More information about the Digitalmars-d
mailing list