Совместимость ссылки между C++ и D

D легко интерфейсы с C.

D так же, как легко интерфейсы с C++, но (и это - большое, но), C++ потребности быть чрезвычайно тривиальным. Код не может использовать:

  • пространства имен
  • шаблоны
  • множественное наследование
  • соединение, виртуальное с невиртуальными методами
  • еще?

Я полностью понимаю ограничение наследования. Остальные однако, чувствуйте себя подобно искусственным ограничениям. Теперь я не хочу мочь использовать std::vector непосредственно, но я действительно хотел бы смочь связаться с std::vector как шаблон externed.

Страница взаимодействия через интерфейс C++ имеет этот особенно угнетающий комментарий.

D шаблоны имеют мало общего с шаблонами C++, и очень маловероятно, что любой вид разумного метода, как могли находить, выражал шаблоны C++ совместимым со ссылкой способом с D.

Это означает, что STL C++ и Повышение C++, вероятно, никогда не будут доступны от D.

По общему признанию мне, вероятно, никогда не будет нужно std::vector при кодировании в D, но я хотел бы использовать QT или повышение.

Таким образом, каково соглашение. Почему настолько трудно выразить нетривиальный C++ классы в D? Разве это не стоило бы того для добавления некоторых специальных аннотаций или чего-то для выражения, по крайней мере, пространств имен?


Обновление: "D имеет поддержку пространства имен в работах" от Walter Bright.

20
задан deft_code 22 February 2012 в 19:42
поделиться

3 ответа

FWIW Qt имеет активно развивающуюся привязку для D: http://www.dsource.org/projects/qtd

Я думаю, что многие компоненты в ускорении слишком сильно привязаны к C ++ для значимой переносимости на другие языки.

Используя, например, std :: vector возможен, если вы потратите время на написание обычных (например, на уровне пространства имен) функций, которые направляют соответствующие функции-члены. Утомительно, но доступно (для компонентов более высокого уровня; вероятно, не для std :: vector).

Кроме того, я совсем недавно проверил в стандартной библиотеке реализацию запечатанного массива и запечатанной двоичной кучи, которые используют подсчет ссылок, malloc / free и детерминированное уничтожение вместо сборки мусора (см. http: //www.dsource. org / projects / phobos / browser / trunk / phobos / std / container.d ). Другие контейнеры последуют. В этих контейнерах используются три специальных метода (описанных в моей предстоящей статье «Запечатанные контейнеры») для достижения детерминированного уничтожения без ущерба для безопасности программы.

Будем надеяться, что запечатанные контейнеры избавят от необходимости связываться с контейнерами STL, даже для труднодоступных приложений, которые не могут позволить себе сборку мусора.

27
ответ дан 29 November 2019 в 23:29
поделиться

Как упоминает Ханс Пассан в комментарии, желаемый уровень взаимодействия между D и C ++ даже не поддерживается различными компиляторами C ++. Существует стандарт C ++ ABI (Application Binary Interface), который, кажется, имеет некоторую поддержку, но я не уверен, насколько он обширен (компиляторы Intel, GCC и ARM, похоже, следуют ABI). У меня не было необходимости использовать его, и я не уверен, придерживается ли Microsoft этого для своих компиляторов x86 или x64 (я полагаю, что это может быть для ia64, поскольку именно там начался стандарт ABI).

См. «Взаимодействие и компиляторы C ++» Джо Гудмана для получения более подробной информации о C ++ ABI.

Возможно, Уолтера Брайта удастся убедить поддержать совместимость D с библиотеками / объектами C ++, которые следуют стандарту ABI (хотя я не уверен, где он мог бы сделать это приоритетом).

17
ответ дан 29 November 2019 в 23:29
поделиться

Ради забавы я подключился к некоторому коду C ++.

Вероятно, это не ответ на ваш вопрос, но я думаю, что вам (и некоторым людям из D-сообщества) могут быть интересны некоторые заметки, которые я тогда сделал. Вот оно: Технические примечания .

2
ответ дан 29 November 2019 в 23:29
поделиться
Другие вопросы по тегам:

Похожие вопросы: