Thread overview | |||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 21, 2012 Optional name mangling | ||||
---|---|---|---|---|
| ||||
Hi. Is there any way to instruct the D compiler not to use name mangling when referencing an external C++ function? For example: extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR pszExt); In this particular case, the exported function being referenced is not called _PathRenameExtension@8 - it's just called PathRenameExtension. Now, it's great that D helpfully mangles the name for me when appropriate, but we really need some way to disable it when necessary. Is there any way to import this function without creating a .def file with "_PathRenameExtension@8 = PathRenameExtension"? And if not, why not? |
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stuart | On 21-07-2012 21:24, Stuart wrote: > Hi. Is there any way to instruct the D compiler not to use name mangling > when referencing an external C++ function? > > For example: > > extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR pszExt); > > In this particular case, the exported function being referenced is not > called _PathRenameExtension@8 - it's just called PathRenameExtension. > Now, it's great that D helpfully mangles the name for me when > appropriate, but we really need some way to disable it when necessary. > > Is there any way to import this function without creating a .def file > with "_PathRenameExtension@8 = PathRenameExtension"? And if not, why not? Shouldn't you be using extern (Windows) ? -- Alex Rønne Petersen alex@lycus.org http://lycus.org |
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | On Saturday, July 21, 2012 21:56:36 Alex Rønne Petersen wrote:
> On 21-07-2012 21:24, Stuart wrote:
> > Hi. Is there any way to instruct the D compiler not to use name mangling when referencing an external C++ function?
> >
> > For example:
> > extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR
> > pszExt);
> >
> > In this particular case, the exported function being referenced is not called _PathRenameExtension@8 - it's just called PathRenameExtension. Now, it's great that D helpfully mangles the name for me when appropriate, but we really need some way to disable it when necessary.
> >
> > Is there any way to import this function without creating a .def file with "_PathRenameExtension@8 = PathRenameExtension"? And if not, why not?
>
> Shouldn't you be using extern (Windows) ?
extern(System) should be fine in that it's the same as extern(Windows) on Windows, but since it's a Windows-specific function, it probably _should_ be using extern(Windows).
Of course, since PathRenameExtensions does what std.path.setExtension does, it would probably be better to just use that, but the OP's question _does_ apply to other functions which may not have D replacements, so the question is still relevant.
- Jonathan M Davis
|
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen wrote:
> Shouldn't you be using extern (Windows) ?
Yeah. I changed it to (System) in the hope it'd try *not* mangling the name; and didn't bother changing it back when I discovered it didn't help.
The language (which, let me say, is looking pretty damn good!) really, desperately needs an "extern(C)" keyword. I mean, like, yesterday!
|
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Saturday, 21 July 2012 at 20:07:00 UTC, Jonathan M Davis wrote:
> Of course, since PathRenameExtensions does what std.path.setExtension does, it
> would probably be better to just use that, but the OP's question _does_ apply
> to other functions which may not have D replacements, so the question is still
> relevant.
I didn't know about std.path.setExtension. Is there some kind of table where I can look up D equivalents to API function calls?
In any event, yes, my question is still relevant. What if I want to call some other API function? Or OpenGL? Or something I wrote in C++ with "extern(C)" linkage? (Something I do from time to time)
|
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stuart | On Saturday, 21 July 2012 at 21:17:17 UTC, Stuart wrote:
> The language (which, let me say, is looking pretty damn good!) really, desperately needs an "extern(C)" keyword. I mean, like, yesterday!
extern(C) exists … and we couldn't even have made it to "yesterday" without it.
David
|
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stuart | On Saturday, 21 July 2012 at 21:17:17 UTC, Stuart wrote:
> On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen wrote:
>> Shouldn't you be using extern (Windows) ?
>
> Yeah. I changed it to (System) in the hope it'd try *not* mangling the name; and didn't bother changing it back when I discovered it didn't help.
>
> The language (which, let me say, is looking pretty damn good!) really, desperately needs an "extern(C)" keyword. I mean, like, yesterday!
D already has extern(C).
|
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stuart | On Saturday, July 21, 2012 23:18:46 Stuart wrote:
> On Saturday, 21 July 2012 at 20:07:00 UTC, Jonathan M Davis wrote:
> > Of course, since PathRenameExtensions does what
> > std.path.setExtension does, it
> > would probably be better to just use that, but the OP's
> > question _does_ apply
> > to other functions which may not have D replacements, so the
> > question is still
> > relevant.
>
> I didn't know about std.path.setExtension. Is there some kind of table where I can look up D equivalents to API function calls?
No. If you want to know what's there, you need to look at the documentation. For the most part, the module names are reasonbly well named after what they do, so you should be able to figure out what module contains the functionality you're looking for without too much difficulty. As for this case, Path-related stuff goes in std.path, stuff that operates on a file as a whole is in std.file, and stuff that involves more general I/O (including reading a file in pieces) is in std.stdio.
- Jonathan M Davis
|
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stuart | On Saturday, July 21, 2012 23:17:16 Stuart wrote: > On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen > > wrote: > > Shouldn't you be using extern (Windows) ? > > Yeah. I changed it to (System) in the hope it'd try *not* mangling the name; and didn't bother changing it back when I discovered it didn't help. > > The language (which, let me say, is looking pretty damn good!) > really, desperately needs an "extern(C)" keyword. I mean, like, > yesterday! http://dlang.org/interfaceToC.html http://dlang.org/cpp_interface.html http://dlang.org/htomodule.html - Jonathan M Davis |
July 21, 2012 Re: Optional name mangling | ||||
---|---|---|---|---|
| ||||
Posted in reply to JImmy Cao | On Saturday, 21 July 2012 at 21:25:29 UTC, JImmy Cao wrote:
> On Saturday, 21 July 2012 at 21:17:17 UTC, Stuart wrote:
>> On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen wrote:
>>> Shouldn't you be using extern (Windows) ?
>>
>> Yeah. I changed it to (System) in the hope it'd try *not* mangling the name; and didn't bother changing it back when I discovered it didn't help.
>>
>> The language (which, let me say, is looking pretty damn good!) really, desperately needs an "extern(C)" keyword. I mean, like, yesterday!
>
> D already has extern(C).
Well, yes and no:
extern (C) bool PathRenameExtension(LPSTR pszPath, LPCSTR pszExt);
Attempts to bind to a function called _PathRenameExtension. Which is, naturally, of no use whatsoever.
|
Copyright © 1999-2021 by the D Language Foundation