Jump to page: 1 24  
Page
Thread overview
Optional name mangling
Jul 21, 2012
Stuart
Jul 21, 2012
Jonathan M Davis
Jul 21, 2012
Stuart
Jul 21, 2012
Jonathan M Davis
Jul 22, 2012
Mike Parker
Jul 21, 2012
Stuart
Jul 21, 2012
David Nadlinger
Jul 21, 2012
Stuart
Jul 21, 2012
JImmy Cao
Jul 21, 2012
Stuart
Jul 21, 2012
Adam D. Ruppe
Jul 21, 2012
Stuart
Jul 22, 2012
JImmy Cao
Jul 22, 2012
Stuart
Jul 21, 2012
Jonathan M Davis
Jul 22, 2012
Mike Parker
Jul 22, 2012
Daniel Murphy
Jul 22, 2012
Walter Bright
Jul 22, 2012
Stuart
Jul 22, 2012
Sean Kelly
Jul 23, 2012
Jacob Carlborg
Jul 23, 2012
Stuart
Jul 23, 2012
Walter Bright
Jul 23, 2012
Stuart
Jul 23, 2012
Daniel Murphy
Jul 23, 2012
Stuart
Jul 23, 2012
David Nadlinger
Jul 23, 2012
Stuart
Jul 23, 2012
dnewbie
Jul 23, 2012
Stuart
July 21, 2012
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
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
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
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
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
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
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
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
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
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.
« First   ‹ Prev
1 2 3 4