Сокрытие данных и odr

Question

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

С точки зрения ООП, разве это правильно?

/* МоиРассуждения/b/

Можно бы было сделать "публичный" .h файл, в котором только публичные объявления, и "приватный", в котором бы были и публичные и приватные объявления, который будет инклюдить только файл определения реализации .cpp.

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

Какая разница компоновщику с private: сокрытых данных при связывании? Только если это файл опеределения реализации .cpp.

*/

Знаю что не прав, поправьте меня пожалуйста.

Пользуясь случаем, ради интереса, как это правило (odr) реализовано в true-ооп java?

(разницу между include и import понимаю)

Answer 1

Да, вы понимаете правильно: сокрытие данных в данном случае условное, и не защищает от повторной компиляции при изменении приватных данных. Это и правда не очень хорошо с точки зрения инкапсуляции, но с этой технической проблемой не так просто бороться в рамках языка C++.

К сожалению, вы не можете так просто разделить данные между несколькими файлами, потому что для компиляции необходимо знать memory layout класса, который включает в себя и приватные данные.

Общепринятый подход для решения этой проблемы — идиома pimpl: вы делите класс на публичную часть и приватную имплементацию, публичная часть содержит только публичные данные, а приватная часть содержит реальную имплементацию и приватные данные:

// dog.h
class Dog
{
    class DogImpl;
    DogImpl* p_impl;
public:
    Dog(std::string name);
    void bark();
    ~Dog();
};

// dog.cpp
#include "dog.h"
using namespace std;

class DogImpl
{
    string name;
    string barkRepresentation;
public:
    DogImpl(string name) : name(name), barkRepresentation(computeBark()) { }
    void bark() { cout << barkRepresentation; }
    static string computeBark() { return "Wow wow wow!"; }
};

// proxy functions
Dog::Dog(string name) : p_impl(new DogImpl(name)) { }
Dog::bark() { p_impl->bark(); }
Dog::~Dog() { delete p_impl; }

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

Вот обсуждение по теме PImpl на английском.

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

---

Правило ODR нужно по существу лишь из-за модели компиляции C++, в которой куски текста (header-файлы) включаются несколько раз в разных местах. Для языков с более современной моделью компиляции всё гораздо проще: никаких заголовочных файлов нет, так что правило сокращается до «класс с данным именем должен быть определён только один раз».

Answer 2

Ценой предлагаемого вами способа сокрытия реализации является то, что пользователь вашего класса не сможет самостоятельно объявлять объекты вашего класса, расположенные целиком в локальной или статической памяти. Раз компилятору не видно полное определение класса, то ему не известен и полный размер этого класса и, соответственно, создавать объекты такого класса в коде пользователя компилятор не может. Поэтому создавать объекты придется где-то в недрах кода, знакомого с полным устройством класса, и возвращать их наверх пользователю по указателю. Это означет, что обязательно придется использовать какую-то форму динамической памяти для хранения объекта или хотя бы "скрытых" его частей.

Например, в самом экстремальном варианте, содержимое класса не видно пользователю вообще

class CFileHandle;

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

CFileHandle *create_file(/* whatever */);

Разнообразные "промежуточные" варианты сокрытия реализации, как популярная PIMPL idiom, описанная в ответе @VladD, точно таким же образом вынуждены пользоваться динамическим выделением памяти для сокрытой части объекта.

Требование безусловного использования динамической памяти испокон веков считалось неприемлемым языках С и С++, ориентированных на эффективность генерируемого кода (в языке С эта же проблема предстает в точно такой же форме). Также факт сокрытия реализации части класса не позволяет обрабатывать соответствующие скрытые части объектов при помощи inline-функций.

Поэтому сам язык С++ на его базовом уровне настроен именно на определение всего класса, со всеми потрохами, в заголовочном файле, тем самым давая пользователю возможность самостоятельно определять объекты такого класса и работать с ними максимально эффективно (без ненужных накладных расходов). А уж если вас не устраивает такая полная видимость определения класса и вы готовы немножко пожертвовать производительностью, то вам предлагается пользоваться рукописными идиомами типа PIMPL idiom.