Стиль программирования объявления методов получения / установки переменных метода в C ++?

Question

Если вы объявите методы получения / установки класса в файле .h, а затем определите их в .cpp, или сделайте оба в файле .h. Какой стиль вы предпочитаете и почему? Мне лично нравится последний, в котором все они находятся в .h и только методы, с которыми связана логика, кроме сеттеров / геттеров в .cpp.

Answer 1

Для меня это зависит от того, кто будет использовать .h файл. Если это файл, в основном внутренний для модуля, то я склонен помещать крошечные методы в заголовок. Если это более внешний заголовочный файл, представляющий более фиксированный API, то я помещу все в файлы .cpp. В этом случае я часто буду использовать PIMPL Idiom для брандмауэра полной компиляции.

Компромиссы, которые я вижу, помещая их в заголовки:

• Меньше печатать
• Упрощенное встраивание для компилятора (хотя компиляторы иногда могут делать встраивание между несколькими модулями перевода в любом случае.)
• Больше зависимостей компиляции

Answer 2

Я бы сказал, что заголовочные файлы должны быть связаны с интерфейсом, а не с реализацией. Я бы положил их в .cpp.

Answer 3

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

• Файл .h может оставаться разреженным как документация для людей, которые хотят искать определения функций и методов.
• В правилах кодирования моей группы говорится, что мы помещаем все в файл .cpp и хотим следовать им, даже если определение функции занимает только одну строку. Это исключает игры с угадыванием о том, где на самом деле живут вещи, потому что вы знаете, какой файл вы должны изучить.
• Если вы часто выполняете перекомпиляцию большого проекта, сохранение определения функции в файле .cpp экономит ваше время по сравнению с хранением определений функций в заголовочных файлах. Это было актуально для нас совсем недавно, так как мы недавно просмотрели код и добавили много операторов assert во время выполнения для проверки входных данных для наших классов, и это потребовало многих изменений для методов получения и установки. Если бы эти объявления методов жили в файлах .cpp, это превратилось бы в чистую перекомпиляцию для нас, что может занять ~ 30 минут на моем ноутбуке.

Это не значит, что я не время от времени играю по правилам быстро и грязно и не помещаю вещи в файлы .h при реализации чего-то очень быстрого, но для кода я серьезно отношусь ко всему коду (независимо от длины ) в файле .cpp. Для больших проектов (некоторые из них) правила существуют по определенной причине, и их соблюдение может быть достоинством.

Говоря об этом, я только что подумал о еще одном скрипте Perl, который я могу взломать, чтобы найти нарушения правил кодирования. Хорошо быть популярным. :)

Answer 4

Я предпочитаю, чтобы файл .h был максимально чистым. Поэтому небольшие функции, такие же простые, как get / set, я часто использую, чтобы поместить в отдельный файл как встроенные функции, а затем включить этот файл (где я использую расширение .inl) в файл заголовка .h:

// foo.h

class foo
{
public:
   int bar() const;

private:
   int m_bar;
};

#include "foo.inl"

// foo.inl

inline
int foo::bar() const
{
   return m_bar;
}

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

Answer 5

Я помещаю все однострочные в заголовок, если они не требуют слишком большого количества дополнительных заголовков (потому что вызывают методы других классов). Также я не пытаюсь поместить весь код в одну строку, чтобы я мог поместить большинство методов в заголовок: -)

Но Джош упомянул хорошую причину, чтобы в любом случае поместить их в .cpp: если заголовок для внешнего использования.

Answer 6

Я предпочитаю помещать их в файл .cpp ради быстрого времени компиляции / компоновки. Даже крошечные однострочники (пустые виртуальные деструкторы!) Могут взорвать ваше время компиляции, если они будут созданы много. В одном проекте я мог сократить время компиляции на несколько секунд, переместив все виртуальные деструкторы в файлы .cpp.

С тех пор я продан на этом, и я бы снова поместил их в заголовок, только если профилировщик скажет мне, что я могу получить прибыль от встраивания. Единственным недостатком является то, что вам нужно больше печатать, но если вы создаете файл .cpp при написании заголовка, вы часто можете просто скопировать и вставить объявления и заполнить их в файле .cpp, так что это не так уж и плохо. Хуже, конечно, если позже вы обнаружите, что хотите переместить материал в файл .cpp.

Приятным побочным эффектом является то, что чтение становится проще, когда в заголовке есть только документация и объявления, особенно если к проекту присоединяются новые разработчики.

Answer 7

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

Answer 8

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