Должны ли средства доступа быть встроенными?

Question

Это объявление в заголовочном файле:

class PrimeSieve  
{
    populate(int lim);
    vector<int> sieve;
    long long limit;

    public:
        unsigned int limit();
};

Должен ли я определить метод доступа в файле .cpp или в .h, встроенный?

Я новичок в C ++, но я хотел бы следовать рекомендациям. Я видел это в некоторых книгах - это считается стандартом?

unsigned int limit() { return limit; };

Answer 1

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

В случае сложного алгоритма вы можете скрыть определение в файле реализации. Или когда реализация требует некоторые типы / заголовочные файлы, которые не требуются для определения класса. Ни один из этих случаев не распространяется на простые методы доступа.

Для однострочников, поместите его в определение класса. Чуть более длинные функции-члены все еще должны быть в заголовочном файле, но могут быть объявлены явно inline, следуя определению класса.

Answer 2

Большинство новых компиляторов достаточно умны, чтобы встроить то, что необходимо, и оставить все остальное в покое.Поэтому позвольте компилятору делать то, что у него хорошо, и не пытайтесь угадать его.

Поместите весь свой код в .cpp, а объявления кода в .h.

Answer 3

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

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

Answer 4

Для простых типов данных в классах, полностью видимых для клиентов класса, нет никакой разницы, поскольку вам нужно перекомпилировать клиент всякий раз, когда изменяется определение класса.

Основная причина создания средства доступа, а не непосредственного использования элемента, состоит в том, чтобы позволить реализации впоследствии удалить элемент данных и при этом поддерживать интерфейс совместимым; если интерфейс, содержащий метод доступа, не изменяется, то результат, как правило, является двоично-совместимым, в противном случае он совместим с источником. Наличие аксессора во встроенном состоянии означает его определение как части изменяемого интерфейса, так что вы всегда можете быть только совместимым с источником.

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

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

Answer 5

Хорошее практическое правило - помещать весь ваш код в файл .cpp, поэтому это противоречит встроенной функции в файле .h.

Answer 6

Это не просто глобальные стандарты программирования, они варьируются от организаций к организациям. Конечно, getLimit() все равно будет лучше, чем limit().