Это объявление в файле заголовка:
class PrimeSieve
{
populate(int lim);
vector<int> sieve;
long long limit;
public:
unsigned int limit();
};
Должен ли я определить метод доступа в файле .cpp или в .h, inline?
Я новичок в С++, но я бы хотел следовать лучшим практикам. Я видел это в некоторых книгах - считается ли это стандартом?
unsigned int limit() { return limit; };
Определенно напишите inline в файле заголовка. Это делает возможной оптимизацию и не уменьшает инкапсуляцию (так как изменения в формате частных данных требуют перекомпиляции всех единиц, которые содержат заголовок, в любом случае).
В случае сложного алгоритма вам может потребоваться скрыть определение в файле реализации. Или когда для реализации требуются некоторые типы/заголовочные файлы, не требуемые в соответствии с определением класса. Ни один из этих случаев не относится к простым аксессуарам.
Для однострочных объектов введите его в определение класса. Немного более длинные функции-члены все равно должны находиться в файле заголовка, но могут быть объявлены явно inline, следуя определению класса.
Большинство новых компиляторов достаточно умен, чтобы встроить то, что необходимо, и оставить все остальное в покое. Поэтому пусть компилятор делает то, что хорошо, и не пытайтесь его догадаться.
Поместите весь свой код в .cpp и объявления кода в .h.
Хорошее правило состоит в том, чтобы поместить весь ваш код в файл .cpp, чтобы это противоречило встроенной функции в файле .h.
Для простых типов данных в классах, полностью видимых для клиентов класса, нет никакой реальной разницы, поскольку вам необходимо перекомпилировать клиента всякий раз, когда изменяется определение класса.
Основная причина, по которой сделать аксессуар, а не напрямую использовать его, - разрешить реализации позже удалить член данных и по-прежнему поддерживать совместимость интерфейса; если интерфейс, содержащий аксессор, не изменился, результат, как правило, совместим с двоичными файлами, в противном случае он совместим с исходным кодом. Наличие встроенного средства доступа означает определение его как части интерфейса, который вы меняете, поэтому вы всегда можете быть совместимым с исходным кодом.
Другой причиной наличия доступа является граница DLL: если вашему аксессуру необходимо вызвать другую функцию, и вы разрешите ее встраивать, то этот символ функции также должен быть экспортирован на клиент.
В зависимости от сложности проекта может быть полезно определить интерфейс для вашего кода как абстрактного класса, который позволяет вам изменить реализацию до вашего сердечного контента, если клиент не увидит изменения; в этом случае аксессоры определяются как абстрактные в классе интерфейса, а клиенты не могут их встроить.
Аргумент для объявления accessor inline заключается в том, что это устраняет перегрузку вызова и может включать некоторые дополнительные оптимизации.
Моя опытная производительность - это то, что выигрыш от этого обычно довольно скромный. По этой причине я больше не делаю этого.
Больше, чем быть глобальными стандартами программирования, они варьируются от организаций к организациям. Конечно, getLimit() все равно будет лучше, чем просто limit().