Кто как борется с фактическим отсутствием приватных объявлений в C++?

Не то чтоб часто пишу на С++, но выбираю вариант «перекомпилирую зависящий код».

объявления де-факто являются частью интерфейса класса, их изменение приводит к перекомпиляции зависящего кода

Перекомпиляция происходит при любом изменении файла с кодом. Даже если пробел в комментарии подвинешь.

Бороться путём правильной архитектуры, чтобы пол проекта не пересобиралось от одного изменения, и forward declaration вместо include в заголовочных файлах.

Не то чтоб часто пишу на С++, но выбираю вариант «перекомпилирую зависящий код»

Хоп, и уже релизная сборка проекта на 50 тыс строк занимает полминуты. Перекомпилируйте дальше.

А мы не спешим. Код компилируется, зарплата капает.

Бороться путём правильной архитектуры, чтобы пол проекта не пересобиралось от одного изменения, и forward declaration вместо include в заголовочных файлах

В любом проекте неизбежно есть какие-то центральные компоненты, которые используются большинством других модулей. Предлагаешь все базовые функции писать на forward-объявлениях и функциях? Тогда как бы возникает вопрос «а вы зачем C++ используете?».

Конечно есть, но если спроектированно правильно, то эта общая часть не слишком частотменяется и можно пережить пересборку проекта при изменениях в этой части.

Ну а если всё в проекте в виде запутанного клубка, то нужно начинать с распутывания.

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

У меня была такая проблема: ccache, дробление популярных классов и файлов, forward declaration в заголовочных файлах, а инклюды только в .cpp

Код компилируется, зарплата капает

Сроки подходят к концу и отмазка про длительность компиляции выглядит неубедительно.

Есть ещё такой хак: 1) в заголовке пишешь определение класса без полей, но с декларациями деструктора, фабричных методов класса и публичных методов экземпляра, конструкторы удаляешь; 2) в единицу трансляции с реализацией этот заголовок не инклюдишь, а пишешь в ней определение класса ещё раз, уже с полями, приватными методами и прочим; 3) соответствие деклараций методов реализации проверяет линкер по мангленым именам.

Модули вроде должны эту херню исправить.

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

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

есть также вредное поверие собирать в огромные хидеры типа «все, что нужно». народе пресловутого windows.h

Хоп, и уже релизная сборка проекта на 50 тыс строк занимает полминуты.

Полминуты на проект? Хахахахахахах! У нас было по две-три минуты на один файл с кодом на Boost::Spirit >___<

У нас было по две-три минуты на один файл с кодом на Boost::Spirit >___<

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

У меня сомнения, что есть какая-то серебряная пуля. Очень многое зависит от того, какие есть возможности изолировать одни части кода от других. Если нормальная изоляция зависимостей невозможна из-за особенностей самой логики программы, то тут ничего особо не поделаешь.

Из некрасивых решений можно упомянуть:

• Некую форму динамической типизации. Методы интерфейса определяются в рантайме в момент вызова по строковому или числовому идентификатору.
• Разбиение программы на несколько маленьких, которые общаются друг с другом на подобии микросервисов (для большинства случаев это слишком сурово).
• Одна программа с неким механизмом обмена сообщениями. Как это любят делать в GUI.

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

Неаккуратный шаг — и программа сыпется с непонятными ошибками, поскольку статической проверки типов между интерфейсом и реализацией нет. За такое могут арестовать.

Методы интерфейса определяются в рантайме
подобии микросервисов
Одна программа с неким механизмом обмена сообщениями

Это уже какая-то скриптовуха пошла.

Это уже какая-то скриптовуха пошла.

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

Чуть ли не в стандарте уже описано. https://en.cppreference.com/w/cpp/language/pimpl

— непрозрачные ссылки на forward-объявления структур и функции для работы с ними;

ТС уже упоминал

Есть несколько простых вещей, некоторые из которых не только увеличат скорость компиляции, но и благотворно скажутся на общей архитектуре. Применять вместе или по отдельности!

• Forward Declarations
• Интерфейсы
• PIMPL
• Dependency Injection
• Не упарываться в ОПП
• Не писать сложную бизнес логику на С++

Ты тоже видишь некоторые взаимоисключающие параграфы здесь? А потому что серебряной пули не существует.

Навскидку пришло в голову еще пару способов, скорее из system-design чем С++, но они косвенно тоже ускоряют компиляцию (и замедляют рантайм):

• Динамическая линковка и плагины
• Message passing внутри приложения
• IPC (shared memory, RPC, REST/HTTP, etc.)

Этому есть общепринятое название, которое ТС было незнакомо.

Хоп, и уже релизная сборка проекта на 50 тыс строк занимает полминуты. Перекомпилируйте дальше.

Ну так учитесь писать правильно! Например, не надо бояться имплементацию выность в cpp-файлы.

А если кто-то злоупотребляет шаблонами — ну тогда ой. ССЗБ.

непрозрачные ссылки на forward-объявления структур и функции для работы с ними;

This.

Кто как обходит проблему?

Не является проблемой.

увеличат скорость компиляции

Мизерно.

благотворно скажутся на общей архитектуре.

Никак, если общая архитектура уже грамотна.

При этом все это значительно замедляет рантайм.

Про ipc и сообщения даже пояснять нет смысла.

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

Модули вроде должны эту херню исправить.

+1.

-ftime-trace и делать выводы

Модули вроде должны эту херню исправить.

и уже давно. В смысле кому-то должны. :-)

Есть ещё такой хак

Прямое нарушение ODR ломающее очень много чего. В приличных домах за такое…

Пиши на Java/любом языке без магии сопроцессора.

Как мы все знаем, private объявления де-факто являются частью интерфейса класса, их изменение приводит к перекомпиляции зависящего кода.

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

и поскольку «зависящий код» зависит обычно именно в этом смысле - надо все перекомпилировать.

Ну кто ж виноват, что в C++ кроме как через жопу ничего нельзя.

Пиши на Java/любом языке без магии сопроцессора

Если бы меня попросили назвать популярный язык, который хуже C++, то я бы проголосовал на Java. Код, который пишется в языках программирования в три строчки, в жаве пишется в три класса. А дальше уже не важно, насколько эти три класса «удобно» писать.

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

А еще потому, что любой код, использующий объявление класса, должен генерировать код инициализации и финализации приватных членов, плюс другие инлайн методы. Это такой «не интерфейс», что даже хочется назвать его интерфейсом. Какой же это «не интерфейс», если любой внешний код модифицирует приватные члены? Есть лишь нонсенс синтаксической ошибки, когда компилятор не дает модифицировать извне приватные члены больше, чем того позволяет стандарт.

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

Какой же это «не интерфейс», если любой внешний код модифицирует приватные члены?

Можно пример «любого внешнего кода модифицирующего приватные члены»?

причем тут «технические изьяны c++», если это будет справедливо для любого компилируемого языка со структурами. чтобы структуру разместить в памяти, надо знать ее размер. нельзя вычислить размер структуры, если ни видны все ее поля в точке вычисления размера.

тут модули всякие вообще не причем, модули ничего не изменят.

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

Можно пример «любого внешнего кода модифицирующего приватные члены»?

Можно. Почти любой контейнер STL создает чуть более, чем полностью, из-за инлайнящихся шаблонных методов, дергающих приватные поля в любом коде, который эти контейнеры использует. Я давно пишу, что крестовые шаблоны — это макросы на кокаине стероидах.

причем тут «технические изьяны c++», если это будет справедливо для любого компилируемого языка со структурами. чтобы структуру разместить в памяти, надо знать ее размер. нельзя вычислить размер структуры, если ни видны все ее поля в точке вычисления размера

Прикинь, в сишке можно зааллоцировать структуру, не знаю ее размера. Причем, с LTO оно еще и может быть заинлайнено.

Использовать фабрики и не допускать прямого вызова конструктора в клиентском коде.

Можно зарезервировать место для полей класса и виртуальных методов чтобы можно было потом добавить не нарушая бинарной совместимости. Такой подход используется в Haiku.

Прикинь, в сишке можно зааллоцировать структуру, не знаю ее размера.

Вопиюще ложная информация.

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

Я уж было подумал, что вы перестали быть несущим откровенную херню балаболом. Но нет, не перестали.

Я давно пишу, что крестовые шаблоны — это макросы на кокаине стероидах.

Да совершенно фиолетово как вы относитесь к шаблонам. Они вот такие. Можно их любить, можно обсирать, но другими они не станут.

Нормальные люди принимают все как есть, но некоторым что-то где-то припекает, никак угомониться не могут.

У меня обычно есть файл declarations, там лежат forward объявления. Иногда операторы всякие кладу. Короче он заточен под то, чтобы быть перманентным.

Иногда использую пимпл. У него есть подводный камень с константностью: указатель будет типа T* const а не const T* поэтому константные функции смогут «изменять» объект.

Хотя чаще всего делаю header only либы, и все ок, достаточно быстро компилируется.

Зы: сорян если что, весь тред не читал

Че? Как? Ты должен куда то ее поместить, нужно место в памяти.

Но возможно ты подразумевал не зная ее объявления? Так можно и в плюсах, нужна просто память куда ее положить. Но памяти должно быть достаточно , в любом случае.

Не скажи. У тебя есть огромный проект, почти везде нужна какая то подсистема. Вот и будешь без пимпола каждый раз перекомпиливать. А так фасад для подсистемы перманентный, меняется только если меняется апи системы.

это не «интерфейс класса», а его декларация. А декларация должна быть полной, поскольку размер обьекта класса должен быть вычислим при декларации переменной класса.

Могли бы сделать, чтобы в operator new передавался не размер класса, а указатель на дескриптор, содержащий размер. Тогда изменение размера приватных полей не приведёт к нарушению ABI. Так например в Оберонах сделано.

Не писать сложную бизнес логику на С++

Си тут никак не поможет. struct some_object *create_object(); – это тоже самое что и фабрика в C++. А прямое выделение памяти в клиенте создает туже самую проблему что и приватные поля класса.

Могли бы сделать, чтобы в operator new передавался не размер класса, а указатель на дескриптор, содержащий размер

обьекты еще на стеке размещаются. если их например два, то смещение второго статически невычисляется, если размер первого непонятен во время компиляции.

int fun(){
  classA a;
  classB b; //<если неясен размер <a>, то непонятен адрес <b>.
}

продолжение предыдущего поста:

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

То что ты описал решается с помощью интерфейса с чисто виртуальными методами. Пока интерфейс не трогаешь ничего пересобираться не будет. Пимпл здесь не нужен.