Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

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


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

4b9b3361

Ответ 1

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

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

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

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

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

Ответ 2

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

См. "Совместимость и компиляторы С++" Джо Гудмана для некоторых подробностей о С++ ABI.

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

Ответ 3

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

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