Link-Kompatibilität zwischen C++ und D

Question

leicht Schnittstellen mit C.

genauso einfach Schnittstellen mit C++, aber (und es ist ein großes aber) die C++ muss extrem trivial sein. Der Code kann nicht verwendet werden:

• Namespaces
• Vorlagen
• Mehrfachvererbung
• Mix virtuelle mit nicht-virtuellen Methoden
• mehr?

Ich verstehe die Vererbungsbeschränkung vollständig. Der Rest fühlt sich jedoch wie künstliche Beschränkungen an. Jetzt möchte ich std::vector<T> nicht direkt verwenden können, aber ich würde wirklich gerne mit std::vector<int> als externe Vorlage verknüpfen können.

Die C++ interfacing page hat diesen besonders deprimierenden Kommentar.

D-Vorlagen haben wenig gemein mit C++ Vorlagen, und es ist sehr unwahrscheinlich, dass jede Art von angemessener Methode C++ Vorlagen in eine Link-kompatible Weise mit D.

gefunden werden konnte auszudrücken

das bedeutet, dass der C++ STL und C++ Boost, wird wahrscheinlich nie

Zugegeben von D. zugänglich sein ich werde probabl y nie brauchen std::vector während der Codierung in D, aber ich würde gerne QT oder boost verwenden.

Also, was ist das Geschäft. Warum ist es so schwer, nicht-triviale C++ Klassen in D auszudrücken? Wäre es nicht wert, einige spezielle Anmerkungen oder etwas hinzuzufügen, um wenigstens Namespaces auszudrücken?

---

aktualisieren: von Walter Bright "D Namespace-Unterstützung in Arbeit hat".

Answer 1

FWIW Qt hat ein aktiv entwickelt für D-Bindung: http://www.dsource.org/projects/qtd

ich viele Komponenten im Boost sind zu hoch gebunden an C++ denken tragbar zu sein Bedeutung mit anderen Sprachen.

Verwenden von z.B. std :: vector ist möglich, wenn Sie die Zeit damit verbringen, reguläre (z. B. Namespace-Level-) Funktionen zu schreiben, die an die entsprechenden Elementfunktionen weiterleiten. Mühsam, aber erschwinglich (für Komponenten auf höherer Ebene; wahrscheinlich nicht für std :: vector).

Außerdem habe ich vor kurzem in der Standardbibliothek ein versiegeltes Array und eine versiegelte binäre Heap-Implementierung eingecheckt, die Referenzzählung, malloc/free und deterministische Destruktion anstelle der Garbage Collection verwenden (siehe http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/container.d). Andere Container werden folgen. Diese Container verwenden drei spezielle Techniken (beschrieben in meinem nächsten Artikel "Sealed Containers"), um eine deterministische Zerstörung ohne Beeinträchtigung der Programmsicherheit zu erreichen.

Wir hoffen, dass versiegelte Container die Verbindung mit STL-Containern überflüssig machen, selbst für enge Anwendungen, die sich keine Garbage Collection leisten können.

Answer 2

Wie Hans Passant in einem Kommentar erwähnt, wird das Niveau der Interoperabilität, die Sie zwischen D und C++ wollen, von verschiedenen C++ - Compilern nicht einmal unterstützt. Es gibt einen C++ - ABI-Standard (Application Binary Interface), der anscheinend Unterstützung bietet, aber ich bin mir nicht sicher, wie umfangreich (Intel-, GCC- und ARM-Compiler scheinen den ABIs zu folgen). Ich hatte keine Notwendigkeit, es zu benutzen, und ich bin nicht sicher, ob Microsoft es für ihre x86- oder x64-Compiler hält (ich stelle mir vor, dass es für ia64 könnte, da der ABI-Standard dort begann).

Weitere Details zum C++ ABI finden Sie unter "Interoperability & C++ Compilers" by Joe Goodman.

Vielleicht kann Walter Bright überzeugt werden, D-Interoperabilität mit C++ - Bibliotheken/-Objekten zu unterstützen, die dem ABI-Standard folgen (obwohl ich nicht sicher bin, wo er es priorisieren könnte).

Answer 3

Nur zum Spaß habe ich Schnittstellen zu einigen C++ - Code.

Das wird wahrscheinlich nicht für Ihre Frage beantworten, aber ich denke, dass Sie (und einige Leute in der D-Community) an einigen Notizen interessiert sein könnten, die ich dann gemacht habe. Hier geht es: TechNotes.