Walter wrote:

> 
> "Anders F Björklund" <afb@algonet.se> wrote in message news:cp4v4t$223h$3@digitaldaemon.com...
>> gbatyan wrote:
>>
>> >>It's the same syntax :-) C linkage is C linkage.
>> >>It mostly affects the function name "mangling".
>> >
>> > excuse me for endless newbieness, but where can I read about name
> mangling?
>> > is name mangling standardised across D implementations?
>>
>> I'm not sure if name mangling in D is either
>> documented or even standard among D compilers,
>> but you can read more about mangling in general:
>> http://en.wikipedia.org/wiki/Name_mangling
>>
>> Looking at the disassembled output for some D
>> code should give you examples of what D does ?
> 
> No need to worry about name mangling, as declaring functions with extern(C) will cause them to match C's name mangling.

Not strictly.  Declaring extern(C) only works if you do it within the global
module scope (I guess that's where it's assumed to be used?).  I've found
that if you try to declare functions extern(C) within a class, you lose
access to those functions at link time because their symbol names become
part of the package/module namespace no matter what you intended with the
extern(C) declaration. :-)

John Reimer wrote:
> Walter wrote:
> 
> 
>>"Anders F Björklund" <afb@algonet.se> wrote in message
>>news:cp4v4t$223h$3@digitaldaemon.com...
>>
>>>gbatyan wrote:
>>>
>>>
>>>>>It's the same syntax :-) C linkage is C linkage.
>>>>>It mostly affects the function name "mangling".
>>>>
>>>>excuse me for endless newbieness, but where can I read about name
>>
>>mangling?
>>
>>>>is name mangling standardised across D implementations?
>>>
>>>I'm not sure if name mangling in D is either
>>>documented or even standard among D compilers,
>>>but you can read more about mangling in general:
>>>http://en.wikipedia.org/wiki/Name_mangling
>>>
>>>Looking at the disassembled output for some D
>>>code should give you examples of what D does ?
>>
>>No need to worry about name mangling, as declaring functions with
>>extern(C) will cause them to match C's name mangling.
> 
> 
> Not strictly.  Declaring extern(C) only works if you do it within the global
> module scope (I guess that's where it's assumed to be used?).  I've found
> that if you try to declare functions extern(C) within a class, you lose
> access to those functions at link time because their symbol names become
> part of the package/module namespace no matter what you intended with the
> extern(C) declaration. :-)

OK, but couldn't you get around that with a pretty simple wrapper function?

Something like this...

class myClass
{
   this(){}
   void someFn(){}
}

extern(C) void fnForC() {myClass c = new myClass(); c.someFn }


Sounds like more fun that worrying about name mangling.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

J C Calvarese wrote:
> John Reimer wrote:
>>
>> Not strictly.  Declaring extern(C) only works if you do it within the global
>> module scope (I guess that's where it's assumed to be used?).  I've found
>> that if you try to declare functions extern(C) within a class, you lose
>> access to those functions at link time because their symbol names become
>> part of the package/module namespace no matter what you intended with the
>> extern(C) declaration. :-)
> 
> 
> OK, but couldn't you get around that with a pretty simple wrapper function?
> 
> Something like this...
> 
> class myClass
> {
>    this(){}
>    void someFn(){}
> }
> 
> extern(C) void fnForC() {myClass c = new myClass(); c.someFn }
> 
> 
> Sounds like more fun that worrying about name mangling.
> 

Hi Justin,

Well, I was no longer talking about "calling D from C." (your example being a perfect example of how to do that).  Here, I was playing a little devil's advocate.  My point was concerning use of extern(C) and its limitations in scope.  In order to work, it must never be used anywhere beyond global module scope.  Yet, there /are/ ways around that:

module a;

extern(C) {
void function1();
void function2();
}

module b;

class A {
import a;
}

Now we can call extern(C) functions as if they were class members!  I suppose there's also a way to use the "alias" keyword to accomplish this too.

But, you /cannot/ do:

module b;

class A {
// get access to functions from an external library
extern(C) function1();
extern(C) function2();
}

... and expect your app to link properly.

Interesting, eh?  But importing inside a class is not a wise idea because of name lookup rules.  It can cause inadvertant name hiding of other "real" member symbols.  But all that's been discussed before. :-)

My point probably was a waste of time.  I just got the urge to clarify the extent of extern(C)'s usefulness.  Urges are rarely a good thing... so take it all with a grain of salt. ;-)

- John

In article <cp6tcg$1qu1$1@digitaldaemon.com>, John Reimer says...
>
>J C Calvarese wrote:
>> John Reimer wrote:
>>>
>>> Not strictly.  Declaring extern(C) only works if you do it within the
>>> global
>>> module scope (I guess that's where it's assumed to be used?).  I've found
>>> that if you try to declare functions extern(C) within a class, you lose
>>> access to those functions at link time because their symbol names become
>>> part of the package/module namespace no matter what you intended with the
>>> extern(C) declaration. :-)
>> 

..

>Hi Justin,
>
>Well, I was no longer talking about "calling D from C." (your example

I guess I missed the shift. :)

>My point probably was a waste of time.  I just got the urge to clarify the extent of extern(C)'s usefulness.  Urges are rarely a good thing... so take it all with a grain of salt. ;-)

No, I think you raised an interesting issue.

Maybe D shouldn't allow us to put extern(C) on class members since it's not
particularly helpful.

Or are you trying to convince Walter to eliminate name mangling in that case, so that extern(C) would be actually useful within a class?

jcc7

Walter wrote:
> "Anders F Björklund" <afb@algonet.se> wrote in message
> news:cp56qd$2fhg$1@digitaldaemon.com...
> 
>>Is there a link to the names / ABI used for D ?
>>(when declaring them as the usual, "extern(D)")
> 
> I should write one, but at the moment all there is is the source code for
> the mangler, mangle.c.

Out of curiosity, will D 1.0 have specific ABI requirements?  I've been wondering whether it will be safe (or even possible) to share user-defined objects between units that may have been compiled with different compilers.


Sean

This question was answered already in the old newsgroups, and must be in the web archive on the digitalmars site.

One important thing is: if you have a D application, the startup code which calls main(...) will initialize the D runtime correctly. If you have a C or C++ application, you will need to initialize it manually. Get a clue on what is requiered from here:

http://www.digitalmars.com/d/windows.html

-eye

gbatyan@yahoo.com schrieb:
> Is there a way to use D from C?
> 
> What is the simple yet portable way to do the following:
> 
> - have an imaginary C/C++ SDK giving a possibility to register a
> callback function to be called upon some event in SDK.
> - want to implement the callback functionality in D.
> - If possible, make the whole thing be thread-safe
> (If SDK wishes to have several threads calling the callback concurrently).
> 
> Regards!
> 
> 

J C Calvarese wrote:
> In article <cp6tcg$1qu1$1@digitaldaemon.com>, John Reimer says...
> 
>>J C Calvarese wrote:
>>
>>>John Reimer wrote:
>>>
>>>>Not strictly.  Declaring extern(C) only works if you do it within the global
>>>>module scope (I guess that's where it's assumed to be used?).  I've found
>>>>that if you try to declare functions extern(C) within a class, you lose
>>>>access to those functions at link time because their symbol names become
>>>>part of the package/module namespace no matter what you intended with the
>>>>extern(C) declaration. :-)
>>>
> 
> ..
> 
> 
>>Hi Justin,
>>
>>Well, I was no longer talking about "calling D from C." (your example 
> 
> 
> I guess I missed the shift. :)
> 
> 
>>My point probably was a waste of time.  I just got the urge to clarify the extent of extern(C)'s usefulness.  Urges are rarely a good thing... so take it all with a grain of salt. ;-)
> 
> 
> No, I think you raised an interesting issue.
> 
> Maybe D shouldn't allow us to put extern(C) on class members since it's not
> particularly helpful.
> 
> Or are you trying to convince Walter to eliminate name mangling in that case, so
> that extern(C) would be actually useful within a class?
> 
> jcc7

I was pointing out a inconsistancy with the use of extern(C), such that it's use could be confusing in certain situations: you can import a module containing extern(C)'s into a class and it works, yet you cannot declare extern(C)'s within a class and expect it to link.

I realize it could get unreasonably complicated fixing these kinds of issues, so I'm not sure what kind of a solution is preferable.  I guess it's just important to understand that D's simplicity sometimes allows the creative programmer to do some unusual things without the compiler reporting a problem. Eventually, one does find out that something can't be done, but not necessarily via a standard error message. :-)

At present, the best solution perhaps is to stay informed, that is, to know how D works and stay away from such counter-productive techniques.   If a solution is implemented that prevents such methods, all the better, because it will keep new developers from repeating the same mistake over and over again.  Sometimes "logical" programming methods don't produce the expected result.

Later,

John

"Sean Kelly" <sean@f4.ca> wrote in message news:cp7agn$2huq$1@digitaldaemon.com...
> Out of curiosity, will D 1.0 have specific ABI requirements?  I've been wondering whether it will be safe (or even possible) to share user-defined objects between units that may have been compiled with different compilers.

It'll be as safe as mixing objects compiled with different C compilers.