Блог

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

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

В основном проекте у меня есть папка под названием src, содержащая мой src-код. Затем этот исходный код структурируется по различным папкам, каждая из которых содержит файлы .h и .cpp. Имена файлов соответствуют именам классов. Папки соответствуют пространствам имен, поэтому каждая папка находится в своем собственном пространстве имен.

Я думал, что это довольно разумный подход, пока не обнаружил, что при таком подходе в visual Studio 2010 возникают сбои, если два файла .cpp имеют одинаковое имя (хотя и в разных папках и пространствах имен), потому что все файлы .obj помещаются в один и тот же временный каталог (Debug или Release).

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

Итак, мне просто интересно, разве это не разумный макет? Или люди обычно компилируют каждую папку в статическую библиотеку, а затем связывают их? Или вы просто поддерживаете разные имена файлов? Продолжаете ли вы затем сопоставлять имена файлов с именами классов? Потому что, если вы это сделаете, вам также не понадобятся подпространства имен, поскольку весь проект может быть просто в одном пространстве имен…

Мне интересно, я размышляю… не уверен, что этот вопрос достаточно конкретный. Я предполагаю, что мой непосредственный вопрос (при условии, что макет несколько разумный) заключается в том, как обойти конфликтующие obj-файлы? Я просто подумываю о переименовании файлов с сохранением имен классов. Но мне не очень нравится это решение.

Спасибо (извините за длинный вопрос)

P.S. исходная папка должна быть совместима с gcc под Linux

IDE обычно позволяют логически упорядочивать ваши файлы. (Visual Studio и XCode, по крайней мере, оба позволяют создавать иерархические группы для упорядочивания ваших исходных файлов, которые не соответствуют местоположениям файлов на диске).

Поскольку большинство IDE компилируют все исходные файлы в общую промежуточную папку для этапа компоновки, любые исходные файлы с одинаковыми именами могут привести к конфликту, когда второй файл для компиляции перезаписывает файл .o или .obj предыдущей компиляции.

Таким образом, я придерживался прагматичного подхода: все файлы для одного целевого объекта (статическая библиотека, dylib, exe) содержатся в одной папке. Файлы, зависящие от платформы или специфичных функций, размещаются в определенных подпапках, поэтому становится легко перестроить проект для другой платформы / конфигурации, просто добавляя (или удаляя) папку с файлами за раз. Который действительно (оглядываясь назад) кажется наиболее полезным способом эффективного использования файловой системы.

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

Это хорошо соответствует базовой структуре проекта, которую IDE, такие как Visual Studio и XCode, обычно подразумевают в качестве наилучшей практики с их мастерами: папка проекта, содержащая несколько целевых папок, каждая целевая папка содержит свои исходные файлы.

Я установил

     Properties -> C/C   -> Output Files -> Output File Name
  

Для

     V:%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj
  

для того, чтобы OBJ-файлы оказывались рядом с исходными текстами, предполагая, что проект находится на диске V (пока не знаю, есть ли для этого макрос).