Aarti_pl wrote:
> I just wonder if it wouldn't be better to allow external plugins for DMD. This way you could just create different plugins to allow different name mangling and different interpretation of data in extern() sections...
> 
> We could have then different plugins written by external vendors eg:
> CPP_GCC
> CPP_MSVC
> Pascal
> etc.
> 
> Walter, did you think about solution like this?

No.

> Is there possibility to implement this?

I think the number of different calling conventions in use is pretty limited, so the benefit may not be there.

Walter Bright pisze:
> Aarti_pl wrote:
>> I just wonder if it wouldn't be better to allow external plugins for DMD. This way you could just create different plugins to allow different name mangling and different interpretation of data in extern() sections...
>>
>> We could have then different plugins written by external vendors eg:
>> CPP_GCC
>> CPP_MSVC
>> Pascal
>> etc.
>>
>> Walter, did you think about solution like this?
> 
> No.
> 
>> Is there possibility to implement this?
> 
> I think the number of different calling conventions in use is pretty limited, so the benefit may not be there.

Real advantage would be that someone (some company?) could implement everything necessary to easily link D with C++ (you wrote that it needs 10 man-years, so I prefer you won't do it :D ).

Also it would allow to prepare plugins for other languages, without bloating D compiler itself.

Maybe it would be even commercial C++ plugin. But I guess that for companies which want to start working with D and connect new D code with old C++ code, price will be no-issue.

It is possible that also some other functionality of compiler could be delegated to plugins, but currently I have in mind only this extern() thing...

BR
Marcin Kuszczak
(Aarti_pl)

Walter Bright Wrote:

> Aarti_pl wrote:
> > I just wonder if it wouldn't be better to allow external plugins for DMD. This way you could just create different plugins to allow different name mangling and different interpretation of data in extern() sections...
> > 
> > We could have then different plugins written by external vendors eg:
> > CPP_GCC
> > CPP_MSVC
> > Pascal
> > etc.
> > 
> > Walter, did you think about solution like this?
> 
> No.
> 
> > Is there possibility to implement this?
> 
> I think the number of different calling conventions in use is pretty limited, so the benefit may not be there.

I was going to post a similar question. I do most of my development via gcc. I'm only using DMD on windows rather than gdc because its more reliable (relative to the current state of gdc on cygwin). I have a lot of current C++ code working under gcc which is one thing holding me back from adopting D wholesale. A way of supporting gcc style name mangling as opposed to M$ would be very useful.

Regards,

Bruce.

Bruce Adams wrote:

> 
> I was going to post a similar question. I do most of my development via gcc. I'm only using DMD on windows rather than gdc because its more reliable (relative to the current state of gdc on cygwin). I have a lot of current C++ code working under gcc which is one thing holding me back from adopting D wholesale. A way of supporting gcc style name mangling as opposed to M$ would be very useful. 
> 
> Regards,
> 
> Bruce.

I would not be a bit surprised if DMD linux does uses GCC naming right now.

Bruce Adams wrote:
> I was going to post a similar question. I do most of my development
> via gcc. I'm only using DMD on windows rather than gdc because its
> more reliable (relative to the current state of gdc on cygwin). I
> have a lot of current C++ code working under gcc which is one thing
> holding me back from adopting D wholesale. A way of supporting gcc
> style name mangling as opposed to M$ would be very useful.

Supporting gcc name mangling isn't enough, as dmd on Windows doesn't generate ELF and is incompatible with gcc on many levels.

A more practical approach is to recompile your C++ source using DMC++.

Sean Kelly wrote:
> Walter Bright wrote:
>> David Brown wrote:
>>> On Sun, Oct 07, 2007 at 10:57:31AM -0700, Walter Bright wrote:
>>>> David Brown wrote:
>>>>>   - 'pause/resume' is not a useful thread primitive.  As we've seen by
>>>>>   sample code, just doing simple things is dreadfully difficult, and
>>>>>   very easy to get wrong, having deadlocks, starvation, and other
>>>>>   issues.
>>>>
>>>> The main reason for the existence of pause/resume is so the garbage collector can pause all the threads, do a gc sweep, then resume them.
>>>
>>> I don't think they should go away :-)  I just think there needs to be
>>> something else to use for synchronization.  Just because it is possible to
>>> synchronize with pause/resume, doesn't mean one should.
>>
>> It never occurred to me that someone would use pause/resume for syncing. I thought the concepts were orthogonal.
> 
> For what it's worth, Java has pause/resume as deprecated members of its Thread class.  I suspect they originally included them for garbage collection as well, and deprecated them when people started using them for synchronization (they're a fantastic way to deadlock an app).  Doug Lea's containers and such use them, for example, because Java does not offer standalone mutexes, semaphores, etc.
> 
> 
> Sean

Hum, what do you mean by "standalone mutexes, semaphores, etc."?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Sean Kelly wrote:
> For what it's worth, Java has pause/resume as deprecated members of its Thread class.  I suspect they originally included them for garbage collection as well, and deprecated them when people started using them for synchronization (they're a fantastic way to deadlock an app).  Doug Lea's containers and such use them, for example, because Java does not offer standalone mutexes, semaphores, etc.

I seem to remember darkly, there were at least monitors in Java.
It might be a bit of an abstraction inversion, but other synchronisation
primitives might be built from them, if they are indeed present...

Regads, frank

Bruno Medeiros wrote:
> Sean Kelly wrote:
>>
>> For what it's worth, Java has pause/resume as deprecated members of its Thread class.  I suspect they originally included them for garbage collection as well, and deprecated them when people started using them for synchronization (they're a fantastic way to deadlock an app).  Doug Lea's containers and such use them, for example, because Java does not offer standalone mutexes, semaphores, etc.
> 
> Hum, what do you mean by "standalone mutexes, semaphores, etc."?

I mean standalone synchronization primitives.  As far as I know, the only way to suspend a thread in Java is via Thread.pause().  This makes it possible to /implement/ a semaphore, but doing so basically requires implementing a scheduling/priority policy as well.  By comparison, a D app can simply use the OS API for this stuff, because there's no VM to worry about.


Sean

BCS wrote:
> I would not be a bit surprised if DMD linux does uses GCC naming right now.

It does :-)

Walter Bright wrote:
> Bruce Adams wrote:
>> I was going to post a similar question. I do most of my development
>> via gcc. I'm only using DMD on windows rather than gdc because its
>> more reliable (relative to the current state of gdc on cygwin). I
>> have a lot of current C++ code working under gcc which is one thing
>> holding me back from adopting D wholesale. A way of supporting gcc
>> style name mangling as opposed to M$ would be very useful.
> 
> Supporting gcc name mangling isn't enough, as dmd on Windows doesn't generate ELF and is incompatible with gcc on many levels.

Correct me if I'm wrong, but if mangling was taken care of such code could still be linked if for example the C++ code was in a DLL, right?
Or is the C++ parameter & result passing of mingw/cygwin g++ so different from any method supported by DMD?
(IIRC on Linux it's basically the C calling convention with an implicit first 'this' argument for member functions and s/&/*/ on all types)

> A more practical approach is to recompile your C++ source using DMC++.

That would depend on how much of it there is to recompile, wouldn't it? :P
(Also, the code may use GNU extensions to C++ not present in DMC, requiring more work to port than a simple recompile)