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

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

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

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

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

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

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

Но Josh упомянул серьезное основание поместить их в .cpp так или иначе: если заголовок для наружного применения.

Я предпочитаю сохранять.h файл максимально чистым. Поэтому небольшие функции, которые так просты, как получают/устанавливают меня часто, используют, чтобы вставить отдельный файл как встроено определенные функции и затем включать тот файл (где я использую расширение .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 операторах).

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

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

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

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

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