лучшие статьи об организации файлов кода в [закрытом] C
После прочтения ветки комментариев, я считаю, что использовался OP актива, который поставляется в комплекте с HOTween, и должен иметь свои проблемы, которые блокировали OnComplete от обратного вызова.
похоже, что я использовал устаревшую версию HOTween, которая шла с другим пакетом, который я использовал. После обновления все работает как шарм.
Поскольку я импортировал HOTween в Unity2018.2 из хранилища активов и протестировал обратный вызов OnComplete, он по-прежнему работает, поэтому проблема связана с устаревшим / модифицированным плагином HOTween, который использовал OP.
4 ответа
Характерный для Unix (а не для c, естественно), но тем не менее:
С описанной структурой сборки можно позволить себе использовать много файлов. Таким образом, каждая логическая единица получает заголовок и исходный файл.
Хорошая книга, которая касается большого количества этого (и для C и для C++) является Крупным масштабом Разработка программного обеспечения C++ John Lakos:
Кроме того, хорошее эмпирическое правило для запоминания, "Никогда не делают ничего, что выделяет память в заголовочном файле"
Я думаю лучшее образовательное чтение, Вы собираетесь войти в этот предмет, читает что-то как источник Ядра Linux. Это имеет хорошее исходное расположение и является в основном стандартным большим проектом C. Вот руководство для того, как исходные файлы должны быть соединены для источника BSD, также.
Серьезно, только начните читать источник Ядра и получите ощущение того, как все соединено. Это - очень хорошо запланированный проект, очевидно.
Что касается разметки файлов, альтернатив не так много.
Как правило, выполняется одно из следующих разделов (пакет - это отдельная библиотека или двоичный файл):
- ... / project /.../ package / module. {C, h}
- ... /project/.../{src,include}/package/module.{c,h} // неинтерфейсные заголовки переходят в src
- ... / project /.../ package / { src, include} / module. {c, h} // неинтерфейсные заголовки идут по адресу src
Разделение (1) удобно тем, что все файлы, принадлежащие определенному пакету, хранятся в одном каталоге, поэтому пакет можно легко перемещать, но при таком подходе отделение заголовков API от частных и обнаружение изменений API не является тривиальным. (2) и (3) очень похожи, они делают выпуск API и обнаружение изменений API тривиальным, в то время как (2) немного проще для случая, когда вы всегда выпускаете весь проект, и (3) немного лучше, когда вы выпускаете отдельные пакеты (например, в целях исправления)
В любом проекте C / C ++ обычно есть следующие общие пакеты:
- Общие макросы и типы данных
- Пакет регистрации
- Пакет начальной загрузки приложения (в случае, если есть более 1 бинарных файлов в проекте).