составление частей модулей (без заголовков)

Question

Этот вопрос относится к предложениям «Модули в С ++», а в более широком смысле к языкам, подобным С, которые нуждаются в аналогичной функции (например, мой игрушечный язык, с которым я в настоящее время ... играю). В моем мире «заголовочные файлы» не существуют, предварительные объявления будут вредными для поддержки при написании любого вида кода, и один модуль может состоять из нескольких исходных файлов.

Проблема заключается в следующем:

Исходный файл A использует функцию или класс из исходного файла B в том же модуле, который в настоящее время компилируется.

Почему это проблема?

• Не существует файла модуля для вещей, содержащихся в файле B, он будет сгенерирован при компиляции всех исходных файлов.
• Я не хочу компилировать файл B дважды, а также принудительно компилировать все файлы в модуле одновременно. Это должно сделать возможную сборку простой и легкой.
• Я не хочу, чтобы пользователь был вынужден сначала скомпилировать файл B. Я не говорю, что циклические зависимости должны быть разрешены, я просто хочу иметь возможность компилировать оба файла параллельно. Черт, автоматическое определение необходимого порядка компиляции подразумевало бы компиляцию файлов более одного раза, чего я бы хотел избежать любой ценой.

Любые мысли и, конечно, решения приветствуются!

Answer 1

Я бы скомпилировал файл A таким образом, чтобы он имел определенные ожидания от файла B. Если файл A использует функцию neatofunction, которой переданы int, char* и std::string, а результат сохраняется в short, то он отмечает, что во время связывания фаза, где-то должна быть функция с именем neatofunction, чьи три параметра могут быть преобразованы из int, char* и std::string, тип возвращаемого значения которых , может быть преобразован в a short.

Если он использует класс vector<int>, то он отмечает, что где-то должен существовать класс с именем vector, единственным параметром шаблона которого не является параметр по умолчанию, это тип, удовлетворяемый int, который должен иметь конструктор по умолчанию ( если вы создаете его по умолчанию), деструктор и все члены, которые вы используете (присваивание, begin, end и т. д.).

Это задерживает множество (что есть в C ++) ошибок компилятора до стадии компоновки (и делает стадию компоновки намного сложнее), но позволяет переносить компиляцию. (И экспортированные шаблоны!) Я думаю, что все это на намного легче сказать, чем сделать.

Answer 2

Забывание циклов ... (это часть, о которой я больше всего думаю):

Автоматическое определение необходимого порядка компиляции НЕ подразумевает компиляцию файлов более одного раза.

Все, что для этого требуется, - это определить, был ли файл B, от которого зависит A, (a) уже скомпилирован, или (b) находится в процессе компиляции, или (c) еще не начал компилироваться. И я полагаю, (г) вы, возможно, даже не планировали компилировать B.

Если (а), хорошо, нет проблем.

Если в любом другом случае компиляция A должна быть приостановлена ​​до тех пор, пока компиляция B не будет завершена. Это все.

Я предполагаю, что у вас есть какой-то параллельный менеджер заданий или планировщик. Если (d), вы указываете менеджеру работ запланировать компиляцию B. Если (c), вы говорите, чтобы компиляция B имела более высокий приоритет, чем она уже есть. Если (b), вы просто ждете, когда компиляция B уже выполняется, и / или приостанавливаете компиляцию A, возможно, переключитесь на выполнение чего-то еще, пока компиляция B не будет завершена.

Если у вас нет сложного менеджера заданий, возможно, просто наберите -j 8, вы можете зайти в тупик, потому что все ваши 8 параллельных заданий могут ожидать какого-то зависимого. В этом случае вам, возможно, придется остановить один из них, и latyer перезапустить его полностью.

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

---

Я испытываю желание предложить вам вспомнить граф зависимостей от одной компиляции до следующей перекомпиляции. Это было бы хорошей эвристикой. А простые не совсем полные компиляции, такие как сканирование на #include, могут помочь получить правильный порядок. Но вы могли бы расценить это как дух.