>From the spec: There can be only one destructor per class, the
destructor does not have any parameters, and has no attributes. It is always virtual.

Yet in dmd for some reason, DtorDeclaration::isVirtual explicitly returns FALSE.

As a result, the following prints "A\nB\nA"
import std.stdio;
class A { ~this() { writeln("A"); } }
class B : A { ~this() { writeln("B"); } }
void main()
{
  A a = new B();
  a.__dtor();
}

It looks like a bug, but seems very deliberate.  Does anyone know why it's this way?

Yes, I'm aware delete uses magic behind the scenes to get the correct result.

On 1/23/2012 10:31 PM, Daniel Murphy wrote:
> > From the spec: There can be only one destructor per class, the
> destructor does not have any parameters, and has no attributes. It is always virtual.
>
> Yet in dmd for some reason, DtorDeclaration::isVirtual explicitly returns FALSE.
>
> As a result, the following prints "A\nB\nA"
> import std.stdio;
> class A { ~this() { writeln("A"); } }
> class B : A { ~this() { writeln("B"); } }
> void main()
> {
>    A a = new B();
>    a.__dtor();
> }
>
> It looks like a bug, but seems very deliberate.  Does anyone know why it's this way?
>
> Yes, I'm aware delete uses magic behind the scenes to get the correct result.
>

Because it's handled specially - not through the vtbl[].

On Tue, Jan 24, 2012 at 5:56 PM, Walter Bright <walter at digitalmars.com> wrote:
>
> Because it's handled specially - not through the vtbl[].

Hmmm ok.  Is the an optimization or is it essential?  I don't suppose it's documented anywhere?

I'm trying to improve the c++ interop and this wasn't as I expected. I can always special case it for c++ classes.

On Tue, 24 Jan 2012 12:35:42 +0100, Daniel Murphy <yebblies at gmail.com> wrote:

> On Tue, Jan 24, 2012 at 5:56 PM, Walter Bright <walter at digitalmars.com> wrote:
>>
>> Because it's handled specially - not through the vtbl[].
>
> Hmmm ok.  Is the an optimization or is it essential?  I don't suppose it's documented anywhere?
>
> I'm trying to improve the c++ interop and this wasn't as I expected. I can always special case it for c++ classes.

I case it might help you, I wrote some code to wire up C++ destructors
with D's finalizer.
https://gist.github.com/1391734

Hmm... Did you post that on the newsgroup a while back?  I remember someone had something like that working.

I'm modifying the compiler so it will link directly.  I've got static and non-virtual struct and class members working so far.  It's here if you're interested - some is working but it's not very polished.

https://github.com/yebblies/dmd/compare/master...cpplinking

It is somewhat complicated by the fact I'm testing it with the c++ codebase I'm most unfamiliar with - the d compiler.

On Tue, Jan 24, 2012 at 11:39 PM, Martin Nowak <dawg at dawgfoto.de> wrote:
> On Tue, 24 Jan 2012 12:35:42 +0100, Daniel Murphy <yebblies at gmail.com> wrote:
>
>> On Tue, Jan 24, 2012 at 5:56 PM, Walter Bright <walter at digitalmars.com> wrote:
>>>
>>>
>>> Because it's handled specially - not through the vtbl[].
>>
>>
>> Hmmm ok. ?Is the an optimization or is it essential? ?I don't suppose it's documented anywhere?
>>
>> I'm trying to improve the c++ interop and this wasn't as I expected. I can always special case it for c++ classes.
>
>
> I case it might help you, I wrote some code to wire up C++ destructors with
> D's finalizer.
> https://gist.github.com/1391734
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 24.01.2012 14:04, Daniel Murphy wrote:
> I'm modifying the compiler so it will link directly.  I've got static and non-virtual struct and class members working so far.  It's here if you're interested - some is working but it's not very polished.
>
> https://github.com/yebblies/dmd/compare/master...cpplinking
>
> It is somewhat complicated by the fact I'm testing it with the c++ codebase I'm most unfamiliar with - the d compiler.
>

I was thinking about making something similar some time ago to integrate compiler functionality in D programs: instead of trying to translate dmd, just replace the memory allocations with the D-GC and otherwise link directly to the C++ code.

I figured out some issues and made two tiny changes. Maybe your changes cover these, but in case they might help:

diff --git a/src/tocsym.c b/src/tocsym.c
index 1d614a1..4d47d18 100644
--- a/src/tocsym.c
+++ b/src/tocsym.c
@@ -356,7 +356,7 @@ Symbol *FuncDeclaration::toSymbol()
              func_t *f = s->Sfunc;
              if (isVirtual())
                  f->Fflags |= Fvirtual;
-            else if (isMember2())
+            else if ((storage_class & STCstatic) && isMember2())
                  f->Fflags |= Fstatic;
              f->Fstartline.Slinnum = loc.linnum;
              f->Fstartline.Sfilename = (char *)loc.filename;
@@ -406,12 +406,16 @@ Symbol *FuncDeclaration::toSymbol()
  #endif
                      s->Sflags |= SFLpublic;
                      Dsymbol *parent = toParent();
-                    ClassDeclaration *cd = parent->isClassDeclaration();
-                    if (cd)
+                    if (ClassDeclaration *cd =
parent->isClassDeclaration())
                      {
                          ::type *tc = cd->type->toCtype();
                          s->Sscope = tc->Tnext->Ttag;
                      }
+                    else if (StructDeclaration *sd =
parent->isStructDeclaration())
+                    {
+                        ::type *tc = sd->type->toCtype();
+                        s->Sscope = tc->Ttag;
+                    }
                      break;
                  }
                  default:

I also noticed that calling a virtual function of a derived extern(C++) interface uses a wrong offset into the virtual function table, but did not try to fix it yet.

Rainer

On Wed, Jan 25, 2012 at 6:35 AM, Rainer Schuetze <r.sagitario at gmx.de> wrote:
> I was thinking about making something similar some time ago to integrate compiler functionality in D programs: instead of trying to translate dmd, just replace the memory allocations with the D-GC and otherwise link directly to the C++ code.
>

That's getting quite close to possible.  So far static member functions, free functions and normal member functions link and run correctly.  I've got virtual member functions and ctors/dtors linking as well, but making them work is today's task.

My initial goal is to port the lexer to d, then hopefully package it for phobos.  Being able to link c++ code makes it possible to run the complete test suite on it without having to port the rest of dmd.

> I figured out some issues and made two tiny changes. Maybe your changes cover these, but in case they might help:
>
>[snip]

I did something similar to get the struct symbol, but not as clean. To mangle/link the members correctly, dmd needs more modifications as final functions that don't override anything always have a vtable slot.  And destructors don't for some reason.

>
> I also noticed that calling a virtual function of a derived extern(C++) interface uses a wrong offset into the virtual function table, but did not try to fix it yet.
>
> Rainer
>

Yeah, this bug has been on my radar for a while.  Hopefully it shouldn't be to hard to fix, com classes should be using the correct mechanism somewhere in there.

Update:
I've patched dmd to link with c++ static member functions, non-virtual
member functions, constructors, destructors, template structs and
classes, and static variables. (windows only)

If anyone wants to try it out (and send me test cases!) it's here:
https://github.com/yebblies/dmd/compare/master...cpplink4
I'd be especially please with comments from anybody that understands
the glue/backend about what I've done wrong - a lot of it was
guesswork.

I consider it 'barely tested'.

Please make a pull request out of it. It'll at least go through the auto-pull-tester that way!

On 1/27/2012 2:07 AM, Daniel Murphy wrote:
> Update:
> I've patched dmd to link with c++ static member functions, non-virtual
> member functions, constructors, destructors, template structs and
> classes, and static variables. (windows only)
>
> If anyone wants to try it out (and send me test cases!) it's here:
> https://github.com/yebblies/dmd/compare/master...cpplink4
> I'd be especially please with comments from anybody that understands
> the glue/backend about what I've done wrong - a lot of it was
> guesswork.
>
> I consider it 'barely tested'. _______________________________________________
>

Ok, I opened one, although it is not even slightly ready to pull. https://github.com/D-Programming-Language/dmd/pull/644

Any feedback about the glue/mangling code would be very much appreciated, I don't think there are many people around other than you who understand it.

On Fri, Jan 27, 2012 at 9:17 PM, Walter Bright <walter at digitalmars.com> wrote:
> Please make a pull request out of it. It'll at least go through the auto-pull-tester that way!
>
>
> On 1/27/2012 2:07 AM, Daniel Murphy wrote:
>>
>> Update:
>> I've patched dmd to link with c++ static member functions, non-virtual
>> member functions, constructors, destructors, template structs and
>> classes, and static variables. (windows only)
>>
>> If anyone wants to try it out (and send me test cases!) it's here:
>> https://github.com/yebblies/dmd/compare/master...cpplink4
>> I'd be especially please with comments from anybody that understands
>> the glue/backend about what I've done wrong - a lot of it was
>> guesswork.
>>
>> I consider it 'barely tested'. _______________________________________________
>>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals