Какие рекомендации по кодированию на C ++ и организации файлов вы предлагаете людям, которым приходится иметь дело с множеством взаимозависимых классов, распределенных по нескольким исходным файлам и файлам заголовков?
У меня есть такая ситуация в моем проекте, и решение ошибок, связанных с определением класса, пересекающих несколько файлов заголовков, стало настоящей головной болью.
Некоторые общие рекомендации:
foo.cxx, все, что там определено, лучше объявить в foo.h.#includes whenever possible. This allows you to break the cyclic header dependencies. Essentially, for cyclical dependencies across separate files, you want a file-dependency graph that looks something like this:
A.cxx requires A.h and B.hB.cxx требует A.h и B.hA.h требуется B.hB.h является независимым (и вперед объявляет классы, определенные в A.h)Если ваш код предназначен для использования в библиотеке другими разработчиками, важно предпринять некоторые дополнительные шаги:
include/ и src/ в своих проектах C или C ++, где include/ содержит все мои общедоступные заголовки, а src/ - все мои источники. и частные заголовки.Я бы порекомендовал найти копию книги Джона Лакоса Разработка программного обеспечения на C ++ в больших масштабах. Это довольно объемная книга, но если вы просто пролистаете некоторые из его дискуссий о физической архитектуре, вы многому научитесь.
Ознакомьтесь со стандартами кодирования C и C ++ в Центре космических полетов имени Годдарда НАСА . Одно правило, которое я специально отметил в стандарте C и принятое в моем собственном коде, - это правило, обеспечивающее «автономный» характер файлов заголовков. В файле реализации xxx.cpp для заголовка xxx.h убедитесь, что xxx.h является первым включенным заголовком. Если заголовок не является самодостаточным в любое время, компиляция завершится ошибкой. Это прекрасное простое и эффективное правило.
Единственный раз, когда он терпит неудачу, это если вы переносите между машинами, а заголовок xxx.h включает, скажем, <pqr.h>, но <pqr.h> требует средств, которые оказываются доступными с помощью заголовка <abc.h> на исходной платформе (так что <pqr.h> включает <abc.h>), но возможности не предоставляются <abc.h> на другой платформе (вместо этого они находятся в def.h, но <pqr.h> не включает <def.h>). Это не ошибка правила, и проблема легче диагностируется и устраняется, если вы следуете правилу.
Ответ Тома отличный!
Единственное, что я бы добавил, - это никогда не использовать "объявления использования" в файлах заголовков. Они должны быть разрешены только в файлах реализации, например foo.cpp.
Логика этого хорошо описана в прекрасной книге «Ускоренный C ++» (Ссылка на Amazon - дезинфицирована для скрипта kiddie link нацистов)
Еще один момент в дополнение к другим здесь:
Не включайте какие-либо частные определения во включаемый файл. Например. любое определение, которое используется только в xxx.cpp, должно быть в xxx.cpp, а не xxx.h.
Кажется очевидным, но я вижу это часто.
Я хотел бы добавить одну очень хорошую практику (как на C, так и на C ++), которую часто забывают:
#include "foo.h" // always the first directive
Должны следовать любые другие необходимые заголовки, а затем код. Дело в том, что вам почти всегда нужен этот заголовок для этого модуля компиляции, и включение его в качестве первой директивы гарантирует, что заголовок останется самодостаточным (в противном случае будут ошибки). Это особенно актуально для публичных заголовков.
Если в какой-то момент вам нужно что-то добавить перед включением этого заголовка (кроме, конечно, комментариев), то, скорее всего, вы делаете что-то не так. Если вы действительно не знаете, что делаете ... что приводит к другому более важному правилу => комментируйте свои хаки!
