Насколько я понимаю, идиома pimpl существует только потому, что C++ заставляет вас размещать все члены закрытого класса в заголовке. Если бы заголовок содержал только общедоступный интерфейс, теоретически любое изменение в реализации класса не потребовало бы перекомпиляции остальной части программы.
Я хочу знать, почему C++ не предназначен для такого удобства. Почему вообще требуется, чтобы частные части класса открыто отображались в заголовке (без каламбура)?
Это связано с размером объекта. Файл h используется, помимо прочего, для определения размера объекта. Если бы в нем не были указаны частные члены, вы бы не знали, насколько велик новый объект.
Однако вы можете имитировать желаемое поведение следующим образом:
class MyClass
{
public:
// public stuff
private:
#include "MyClassPrivate.h"
};
Это не навязывает поведение, но извлекает приватные данные из файла .h. С другой стороны, это добавляет еще один файл для обслуживания. Кроме того, в Visual Studio intellisense не работает для приватных участников — это может быть как плюсом, так и минусом.
Я думаю, что здесь есть путаница. Проблема не в заголовках. Заголовки ничего не делают (это просто способ включить общие фрагменты исходного текста в несколько файлов с исходным кодом).
Проблема, насколько она есть, заключается в том, что объявления классов в C++ должны определять все, публичное и приватное, что экземпляр должен иметь для работы. (То же самое верно и для Java, но то, как работает ссылка на классы, скомпилированные извне, делает ненужным использование чего-либо вроде общих заголовков.)
В природе обычных объектно-ориентированных технологий (не только C++) кому-то нужно знать конкретный класс, который используется, и как использовать его конструктор для доставки реализации, даже если вы используете только общедоступные части. Устройство в (3, ниже) скрывает его. Практика в (1, ниже) разделяет проблемы, независимо от того, делаете ли вы (3) или нет.
Используйте абстрактные классы, которые определяют только общедоступные части, в основном методы, и позвольте классу реализации наследоваться от этого абстрактного класса. Таким образом, используя обычное соглашение для заголовков, существует файл abstract.hpp, который используется повсеместно. Существует также реализация.hpp, которая объявляет унаследованный класс и передается только модулям, реализующим методы реализации. Файл реализации.hpp будет #include "abstract.hpp" для использования в объявлении класса, которое он делает, чтобы была единая точка обслуживания для объявления абстрактного интерфейса.
Теперь, если вы хотите принудительно скрыть объявление класса реализации, вам нужно каким-то образом запросить создание конкретного экземпляра, не обладая конкретным полным объявлением класса: вы не можете использовать новые и вы не можете использовать локальные экземпляры . (Хотя вы можете удалить его.) Введение вспомогательных функций (включая методы других классов, которые доставляют ссылки на экземпляры классов) является заменой.
Вместе или как часть файла заголовка, который используется в качестве общего определения для абстрактного класса/интерфейса, включите сигнатуры функций для внешних вспомогательных функций. Эти функции должны быть реализованы в модулях, которые являются частью конкретных реализаций класса (чтобы они видели полное объявление класса и могли использовать конструктор). Сигнатура вспомогательной функции, вероятно, очень похожа на сигнатуру конструктора, но в результате она возвращает ссылку на экземпляр (этот прокси-конструктор может возвращать указатель NULL и даже генерировать исключения, если вам нравятся подобные вещи). Вспомогательная функция создает конкретный экземпляр реализации и возвращает его как ссылку на экземпляр абстрактного класса.
Миссия выполнена.
Да, и перекомпиляция и повторное связывание должны работать так, как вы хотите, избегая перекомпиляции вызывающих модулей, когда изменяется только реализация (поскольку вызывающий модуль больше не выделяет памяти для реализаций).
Вы все игнорируете суть вопроса -
Почему разработчик должен вводить код PIMPL?
Для меня лучший ответ, который я могу придумать, заключается в том, что у нас нет хорошего способа выразить код C++, который позволил бы вам работать с ним. Например, отражение во время компиляции (или препроцессор или что-то еще) или DOM кода.
C++ крайне нуждается в том, чтобы один или оба из них были доступны разработчику для выполнения метапрограммирования.
Затем вы можете написать что-то вроде этого в своем общедоступном MyClass.h:
#pragma pimpl(MyClass_private.hpp)
А затем написать свой собственный, действительно довольно тривиальный генератор обертки.
У кого-то будет гораздо более подробный ответ, чем у меня, но быстрый ответ двоякий: компилятору нужно знать все члены структуры, чтобы определить требования к пространству для хранения, и компилятору нужно знать порядок этих членов для генерировать смещения детерминированным образом.
Язык уже довольно сложен; Я думаю, что механизм разделения определений структурированных данных по коду был бы чем-то вроде бедствия.
Как правило, я всегда видел классы политики, используемые для определения поведения реализации в стиле Pimpl. . Я думаю, что есть некоторые дополнительные преимущества использования шаблона политики - проще обмениваться реализациями, можно легко объединить несколько частичных реализаций в один блок, что позволяет разбить код реализации на функциональные, многократно используемые блоки и т. д.
Может быть, потому что размер класса требуется при передаче его экземпляра по значениям, агрегации его в других классах и т. д.?
Если бы C++ не поддерживал семантику значений, все было бы хорошо, но это так.
Да, но...
Вам нужно прочитать книгу Страуструпа "Design and Evolution of C++". Это затормозило бы внедрение C++.
