С++ идиомы - обсуждение

@Kastaneda · Регистрация: 12.12.2009

Студворк — интернет-сервис помощи студентам

Тема создана для вопросов и обсуждений С++ идиом

Croessmah · 12.10.2018, 15:15

Сообщение от hoggy

что значит неа?

"Неа" значит, что хотя library.h не включает impl.h,
тем не менее он всё равно зависит от impl.h,
и изменение последнего (в плане размера класса impl)
приведет не только к перекомпиляции того,
что зависит от impl.h, но и всего, зависящего от library.h,
конечно, если не забудем руками размер буфера поменять.

В pImpl же изменения в impl.h никак не отражаются на library.h,
не требуют его изменения и перекомпиляции зависимых от library.h "модулей".
Именно об этом говорит GbaLog-.

@hoggy · 12.10.2018, 16:11

Сообщение от Croessmah

В pImpl же изменения в impl.h никак не отражаются на library.h,

зато отражаются на library.cpp
что приводит к его перекомпиляции.

Сообщение от Croessmah

Именно об этом говорит GbaLog-.

он говорит о том, что якобы использование pImpl позволяет
избежать необходимости перекомпиляции application.exe
(dll, или чего мы там собираем)

не позволяет.

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

большинство людей не то что бы не знают, даже не задумываются,
какие изменения произошли в более старших версиях boost, или qt.

я помню, как то раз на бою сделал такую вещь.
мне нужна была функциональность boost::filesystem,
но сам буст в проект тащить было запрещено.

я римплом обернул fs::path.
далее руками cmake линкером разобрал lib на obj.
и заново их слинковал в одну большую fs.lib
все. похоронил зависимость от буста.
теперь буст за собой таскать уже не нужно.

собственно, для таких проделок и был придуман pimpl/rimpl.
только вот нафига использовать более тормозной вариант с pimpl,
который при каждом создании path будет лишний раз дергать кучу,
если можно сделать более эффективный и безопасный rimpl?

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

Croessmah · 12.10.2018, 16:29

hoggy, ну так о компиляции library.cpp никто и не спорит.
Вопрос то стоит в компиляции зависимых от library.h "модулей".
Если наша библиотека - это DLL, то в случае rImpl,
перекомпилировать придется все приложения, которые её используют,
ведь у нас теперь sizeof(agregate) поменялся.
В случае же pImpl, достаточно пересобрать только нашу DLL.
Вот здесь вылезает плюс неизменности ABI при использовании pImpl.

@hoggy · 12.10.2018, 16:38

Сообщение от Croessmah

Если наша библиотека - это DLL, то в случае rImpl,
перекомпилировать придется все приложения, которые её используют,
ведь у нас теперь sizeof(agregate) поменялся.
В случае же pImpl, достаточно пересобрать только нашу DLL.

если наша библиотека - это DLL, то пересобирать придется всю нашу библиотеку DLL.

пересборка DLL не требует пересборку чего либо ещё (других dll, или executable)
в противном случае, такая DLL - неюзабельное говно с неиллюзорной опасностью нарваться на дырявое ABI

а теперь задайте себе вопрос:
почему грамотно выполненные DLL ну прямо таки обожают сишку?

почему грамотное апи выглядит так:

C++
1
void getGroup(  char* buf, const size_t len);

а не так:

C++
1
std::string getGroup();

?

если у вас в хедере dll торчит зависимость от с++ специфики,
значит у вас есть проблема посущественнее, чем пересборка всех бинарей,
что от неё торчат.

Croessmah · 12.10.2018, 16:47

hoggy, причем здесь вообще C?
Вопрос не о C и даже не о DLL, это пример.
Удачный или нет - не так важно в данном случае.
Вопрос в том, что при использовании rImpl,
изменение реализаци "скрытого класса" приводит
изменению "не скрытого класса" и перекомпиляции
зависимых от оного частей.
То есть, фактически, при изменении класса-реализации,
изменяется и класс-интерфейс, т.е. вроде бы они и отдельно,
но ни фига не независимо.
В случае с pImpl такого не происходит.

@hoggy · 12.10.2018, 17:15

Сообщение от Croessmah

В случае с pImpl такого не происходит.

1.
ребилд сам по себе все равно никого не парит.

2.
вы можете использовать разнообразные стратегии для rimpl.
например, сделать буфер побольше с запасом.

3.
rimpl прекрасно сочетается с impl.
например, я когда то такую штуку делал:

C++
1
2
3
4
5
6
using secret = rimpl<ibase, 128>; 
...
// --- мы не можем заранее знать, с какими наследниками предстоит столкнуться
// если конкретный наследник не влазиет в хранилище
// тогда аллоцируем в куче (идем по пути pImpl)
m_data.make<derrived>(params);

4.
вот я открываю например хэдер метаковского api.
там вижу вещи наподобие:

MT4ServerAPI.h

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//+------------------------------------------------------------------+
//| Information about plugin                                         |
//+------------------------------------------------------------------+
struct PluginInfo
  {
   char              name[128];             // plugin name
   unsigned int      version;               // plugin version
   char              copyright[128];        // plugin copyright
   int               reserved[32];          // reserved
  };
//+------------------------------------------------------------------+
//| Plugin configuration structure                                   |
//+------------------------------------------------------------------+
struct PluginCfg
  {
   char              name[32];
   char              value[128];
   int               reserved[16];
  };

вот вы понимаете с какой целью были введены поля reserved ?
вот с той самой, что ежели нужно какое поле добавить,
что бы ODR как карточный домик не рассыпалось.
что бы обеспечивать обратную совместимость новых версий dll
с уже написанным старым кодом пользователей.

в реальных условиях с чем то подобным приходится жить на сопровождении.

Новые блоги и статьи Все статьи Все блоги /
Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .	Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .
Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .

@Kastaneda 5232 / 3206 / 362 Регистрация: 12.12.2009 Сообщений: 8,143 Записей в блоге: 2

	С++ идиомы - обсуждение 01.08.2016, 11:59. Показов 3345. Ответов 25 Метки нет (Все метки) Тема создана для вопросов и обсуждений С++ идиом 0

Croessmah Неэпический 18150 / 10732 / 2067 Регистрация: 27.09.2012 Сообщений: 27,047 Записей в блоге: 1
	12.10.2018, 16:29
	hoggy, ну так о компиляции `library.cpp` никто и не спорит. Вопрос то стоит в компиляции зависимых от `library.h` "модулей". Если наша библиотека - это DLL, то в случае rImpl, перекомпилировать придется все приложения, которые её используют, ведь у нас теперь `sizeof(agregate)` поменялся. В случае же pImpl, достаточно пересобрать только нашу DLL. Вот здесь вылезает плюс неизменности ABI при использовании pImpl. 0

Croessmah Неэпический 18150 / 10732 / 2067 Регистрация: 27.09.2012 Сообщений: 27,047 Записей в блоге: 1
	12.10.2018, 16:47
	hoggy, причем здесь вообще C? Вопрос не о C и даже не о DLL, это пример. Удачный или нет - не так важно в данном случае. Вопрос в том, что при использовании rImpl, изменение реализаци "скрытого класса" приводит изменению "не скрытого класса" и перекомпиляции зависимых от оного частей. То есть, фактически, при изменении класса-реализации, изменяется и класс-интерфейс, т.е. вроде бы они и отдельно, но ни фига не независимо. В случае с pImpl такого не происходит. 0