отделение декларации от определения

Если я напишу файл D, подобный этому: http://arsdnet.net/dcode/iface/test.d и вы скомпилируете с помощью dmd -c, вы увидите, что он проходит без ошибок; это действительный файл D. Язык позволяет писать прототипы функций без реализации.

Файл .di такой же, просто у него другое имя файла.

Затем указан main: http://arsdnet.net/dcode/main.d, если вы компилируете dmd main, он будет автоматически искать iface/test.d, когда увидит «import iface.test;», найдет этот файл .d или .di, если вы переименуете его, но то же самое, и получите определение вашего интерфейса.

dmd main завершится ошибкой компоновщика, поэтому нам нужно реализовать его: http://arsdnet.net/dcode/impl.d Примечание: impl НЕ импортирует модуль, поэтому он никогда не проверяет другой файл. Синхронизация файлов .di и .d является одной из сложных частей здесь, если только вы не сгенерируете файл интерфейса автоматически, поскольку неопределенные методы дадут ошибки компоновщика, но порядок методов важен: он должен совпадать, и так должно быть. список переменных, если есть общедоступные. В противном случае код использования и код реализации не будут согласовываться с макетом класса.

Опять же, он не проверяет это автоматически, файл реализации вообще не смотрит на "заголовочный" файл, так что это большое отличие от C++, где вы пишете файл заголовка один раз, а затем используете это как в программе использования, так и в файле реализации.

Вы заметите, что в файле реализации также указан класс и т. д. D не поддерживает синтаксис void MyClass::add(int a) {} C++ должен писать метод вне класса.

Насколько я знаю, нет способа заставить файл реализации искать заголовок, если поставить оба в командной строке, то получится: "Ошибка: модуль iface.test из файла iface/test.d конфликтует с другим модулем тест из файла impl.d"

Файлы .di рекомендуется использовать для автоматического создания с помощью dmd -H. Это считывает полный файл реализации и удаляет тела функций, оставляя только определения. Эта часть, вероятно, является ключевой, когда говорят, что это особенность компилятора - файл .di является допустимым и стандартным D, но генерируется с помощью опции компилятора, которая не обязательно должна быть частью других компиляторов.

Вы можете объявлять функции без указания их реализации, используя extern, например:

extern(D):
void foo(string name);

Затем просто предоставьте объектный файл/архив с реализацией для связывания. Обратите внимание, что имя модуля является частью искаженного имени функции, поэтому либо для файла заголовка требуется то же имя модуля, что и для скомпилированного модуля, либо вы можете использовать extern(C) для отключения искажения (предотвращает перегрузку и использует соглашение о вызовах C).

Адам уже все объяснил. Я просто попытаюсь добавить дополнительный пример:

Допустим, вы разрабатываете библиотеку под названием mylib, в которой есть функции foo() и bar(). Ваше тестовое приложение с кодом и библиотекой может выглядеть так при запуске:

mylib.d — файл интерфейса

module mylib;

void foo();
void bar();

mylib_impl.d — определения здесь

module mylib;

import std.stdio;

void foo() {
  writeln("foo()");
}

void bar() {
  writeln("bar()");
}

mylib_test.d — тестовое приложение

// To compile: dmd mylib_impl.d mylib_test.d
// NOTE: we do not compile the "interface" file mylib.d !!
module mylib_test;

import mylib;

int main() {
  foo();
  bar();

  return 0;
}

Теперь не должно быть сложно понять, что у нас есть файлы .di исключительно для удобства и ясности. Если мы решим использовать файл интерфейса, мы переименуем mylib.d в mylib.di, а mylib_impl.d в mylib.d. mylib_test.d останется нетронутым.