Совместимость ссылок между C ++ и D - PullRequest
Новая
       0

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

20 голосов
/ 11 июня 2010

D легко взаимодействует с C.

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

  • 1011 * пространства имен *
  • Шаблоны
  • множественное наследование
  • сочетание виртуальных и не виртуальных методов
  • больше?

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

На странице взаимодействия C ++ есть такой удручающий комментарий.

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

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

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

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

Обновление : «У D есть поддержка пространства имен в работах» от Walter Bright .

Ответы [ 3 ]

27 голосов
/ 12 июня 2010

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

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

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

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

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

17 голосов
/ 11 июня 2010

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

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

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

2 голосов
/ 21 июня 2010

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

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

...