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

Кто сказал «си»?

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

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

Зачем? Пусть тот, кто мне этот объект возвращает, выделяет сколько нужно памяти. Даже в замшелом позиксе подобные функции есть.

На момент создания объекта должен быть известен его размер. Далее ты можешь передавать по указателю или ссылке. В чем тогда проблема ? Тогда абстрактный базовый класс, он как раз для таких случаев и сделан. По указателю или ссылке можно передавать даже forward declaration (но не unique_ptr, std от мелкомякгих не проверяет этого, в отличии от гцц)

На момент создания объекта должен быть известен его размер

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

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

чтобы писать так

class A{
  int x,y;
public:
  int z;
};

void ff(){
  A a; //тут для генерации кода размещения на стеке надо знать размер класса A
  a.z = 10; //тут надо знать смещение поля z в обьекте класса A.
}

и размер обьекта и смещение публичного поля зависят от размеров приватных полей <x,y> и выравнивания полей в классе. то есть для работы с публичными полями надо знать все о приватных.

Что? Я не понял. Чтобы создать объект структуры, нужно где то взять память, на стеке или в куче, столько сколько нужно этому объекту. Для каждого поля вызывается конструктор (или поле остаётся неинициализированным). Нет памяти - нет объекта.

Чтобы создать объект структуры, нужно где то взять память, на стеке или в куче, столько сколько нужно этому объекту

Зачем мне всё это делать и знать? Ты, когда делаешь system("git clone ..."), определяешь, сколько для чего гиту нужно выделить памяти? Для 1985 года, да, тебе нужно было статически выделять память, которой было мало, но в 2022 пора бы уже разрешать внешнему коду выделять произвольные объемы памяти.

Используйте фабрики и не надо будет считать байты.

Ну так ясен пень, нигде в программе нет надобности (ну кроме хаков всяких) знать и указывать размер объекта самому, это все компилятор делает. Я же говорил о необходимости знать этот размер компилятору. Иначе говоря: нельзя создать объект, у которого в данном месте доступно только forward declaration.

Я же говорил о необходимости знать этот размер компилятору. Иначе говоря: нельзя создать объект, у которого в данном месте доступно только forward declaration

Даже стереотипный PIMPL на вложенной структуре не требует от клиентского кода знания размера реализации объекта.

Без оптимизаций с -O0 или -Ofast? Охренеть! Это и в Java, кстати, частенько такая же ботва с этой компиляцией

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

Ничего себе, в ООП объекты умеют делать что-то самостоятельно и не спрашивая разрешения у вызывающего кода, вот это да:)

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

А тут ты зачем-то мешаешь в одну кучу C++ интерфейс класса (который не зависит от приватных полей в первом приближении) и интерфейс скомпилированного класса для линкера (который зависит от всех полей класса, так как ООП к этому моменту уже не существует)

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

filosofia

Без комментариев 🙂 Вот уж действительно философия

А тут ты зачем-то мешаешь в одну кучу C++ интерфейс класса (который не зависит от приватных полей в первом приближении) и интерфейс скомпилированного класса для линкера (который зависит от всех полей класса, так как ООП к этому моменту уже не существует)

Для компилятора ООП не существует ни на каком этапе компиляции, просто он иногда притворяется, будто они существуют, прерывая компиляцию с синтаксическими ошибками.

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

Страуструп

Без комментариев 🙂 Вот уж действительно философия

А что не так? Я регулярно нахожу этому доказательства. У крестовиков есть склонность на мир смотреть с позиции «сначала был C++, потом появились машинные коды». А куда же делись остальные программисты? Остальные программисты просто ненавидят C++, не важно громко или тихо, пишут на нем или нет.

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

Страуструп

Когда поднимаетсяя вопрос «кто ответит за Си и Питон» — я всегда спрашиваю: а кто заставлял строить на них огромные системы? Кто-то запставлял превращать программно-аппаратные комплексы в монолитный клубок из «программный код оптимизирован под процессоры, процессоры оптимизированы под конкретный программный код»? Который теперь уже не видится возможным распутать и создать альтернативную архитектуру, хотя в 70-х годах очень активно к этому стремились, смотри тот же p-code и UCSD-паскаль. Но вместо этого выбрали глубоко ненадежную и непортируемую сишную модель (непортируемая портируемость, ага), потому что этот костыль просто реализовывать и переносить между платформами вследствие малого размера. ПО крайней мер в 70-х так было, в 80-х это быстро стало не так и сишный код стал о-очень плохо портироваться, поскольку всё упирается в оптимизирующие компиляторы и асмовые функции, без которых сишный код еле ползает.

Требует. При создании. Если тебе только указатель, то не надо. Поэтому в интерфейсе хранится указатель, у конечного объекта все равно есть размер - размер указателя (ну или двух если нужна виртуальная таблица). А в той единицы трансляции, где создаётся pimpl его размер должен быть известен.

Тут кстати есть подвох с деструктором, его нельзя генерировать в объявлении а таком случае (гцц отловит а вот студия прошляпит этот момент)

Тут кстати есть подвох с деструктором, его нельзя генерировать в объявлении а таком случае (гцц отловит а вот студия прошляпит этот момент)

Пример? Что имелось ввиду?

Вот такой код не компилируется не одним из компиляторов, я так понял, что он имелся ввиду:

#include <memory>

using namespace std;

class Test {
public:
    Test();
    int bar() const;
    ~Test() {}

private:
    class Implementation;
    unique_ptr<Implementation> m_impl;
};

Без комментариев 🙂 Вот уж действительно философия

Тебе просто экспертизы или смелости не хватает, чтобы признать, что С++ — результат ошибок и обратной совместимости.

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

Тебе просто экспертизы или смелости не хватает, чтобы признать, что С++ — результат ошибок и обратной совместимости.

Разберём по частям тобою написанное

1. То что C++ развивается эволюционно — то бишь новые стандарты строятся поверх старых — так это все знают. Революционный подход — «ломание» языка в каждой мажорной версии — нельзя назвать однозначно более лучшим или худшим. Это дискуссионно, и, если честно - не очень интересно :)

2. Насчёт ошибок — давай ка конкретнее, без лишней философии ;) Какие ошибки в C++?

Причём заметь, что я не хаю язык

Не заметил. Хаешь.

Но вы, некомпетентные адепты, вы достойны общественного порицания

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

У крестовиков есть склонность на мир смотреть с позиции «сначала был C++, потом появились машинные коды». А куда же делись остальные программисты? Остальные программисты просто ненавидят C++, не важно громко или тихо, пишут на нем или нет.

Здесь явно логическая ошибка, или я тебя не понял. Кто такие «крестовики»? Попробуем разобраться из твоего сообщения...

Остальные программисты просто ненавидят C++, НЕ ВАЖНО громко или тихо, ПИШУТ НА НЁМ ИЛИ НЕТ

То есть крестовики это не только лишь те, кто пишут на C++; а те, кто его не ненавидят = любят? То есть типа «адвокаты C++»?

Окей. Тогда я тебя огорчу — такой социальной группы не существует, любовь это просто эмоция (причём непостоянная), поэтому любые выводы о психологических закономерностях этой группы

У крестовиков есть склонность на мир смотреть с позиции «сначала был C++, потом появились машинные коды»

являются невалидными, мусорными.

Объясню, почему. Конкретно я в этой теме тот самый «адвокат C++», потому что ты её так подал. При этом, хорошо зная в сумме три ЯП (совершенно разных попарно) я могу вести разговор и о недостатках языка C++. Если в разговоре о недостатках оппонент со мной не согласиться, он точно так же может повесить на меня ярлык «хейтер C++».

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

////////////////////////////////////////////

Напротив, множество «программистов C++» можно определить совершенно корректно. Вот только и ты, и я к нему принадлежим. Как видишь, никакой дихотомии на самом деле нет 🙂

Тебе просто экспертизы или смелости не хватает, чтобы признать, что С++ — результат ошибок и обратной совместимости

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

https://yosefk.com/blog/what-worse-is-better-vs-the-right-thing-is-really-abo...

А выживет тот, кто окажется привычнее и удобнее для большинства принимающих решение, а принимать решения будут умственно отсталые люди, толкающие других умственно отсталых наращивать ВВП. Далее уже большинство руководителей естественным образом не пустит к себе более смышленого подчиненного, поскольку будут бояться конкуренции. Такая модель создана целенаправленно, на культурном уровне, и это хорошо работало предыдущие 50 лет: ВВП создавалось, люди не задавали лишних вопросов и не ставили под сомнение статус кво, а карьерных успехов добивался тот, кто этот статус кво яростно отстаивал и оправдывал, будь рассказы про прослушку КГБ в каждом американском туалете или гендерное равенство.

Да, иногда это очень больно выстреливало, когда внезапно высовывалась Япония, которая за историю как минимум дважды имела шанс уничтожить целые сектора американской промышленности под ноль, поскольку американские инженеры даже с отставанием в несколько лет не могли конкурировать с японскими ввиду тотального разложения американской научно-производственной культуры — им нужно было порядка 10 лет, чтобы догнать японцев, а к тому времени было бы уже «всё». До сих пор эти прорехи удавалось затыкать числом военных баз по всему миру, таким образом силой подавляя любые зачатки конкуренции в иных регионах — так делала еще британия в 19-м веке.

О господи. Действительно,

byko3y ★★★★ (04.05.22 14:22:57) Специалист по всему

Здесь явно логическая ошибка, или я тебя не понял. Кто такие «крестовики»? Попробуем разобраться из твоего сообщения...
То есть крестовики это не только лишь те, кто пишут на C++; а те, кто его не ненавидят = любят? То есть типа «адвокаты C++»?

«Фанаты крестов» — так яснее? Это настолько узкая и отличительная группа лиц, что я посчитал, что разъяснения излишни. А гляди ж...

Объясню, почему. Конкретно я в этой теме тот самый «адвокат C++», потому что ты её так подал. При этом, хорошо зная в сумме три ЯП (совершенно разных попарно) я могу вести разговор и о недостатках языка C++. Если в разговоре о недостатках оппонент со мной не согласиться, он точно так же может повесить на меня ярлык «хейтер C++».

Каждый человек уникален да, но и что теперь, никого никак не называть? Абсолютно любые слова в любых контекстах являются искажением реальности, но ты подразумеваешь, что есть все-таки какие-то «неискажения». Проблема начинается только тогда, когда человек дальше ярлыков ничего не видит, как собака, которая смотрит на руку, а не по указываемому направлению.

byko3y ★★★★ (04.05.22 14:22:57) Специалист по всему

«Эксперт по всем вопросам», ага.

«Фанаты крестов» — так яснее? Это настолько узкая и отличительная группа лиц, что я посчитал, что разъяснения излишни. А гляди ж...

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

Вообще, это называется strawman fallacy. И чем дальше дискуссия уходит в гуманитарную сторону от самих «крестов», тем быстрее она становится мусорной.

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

Конечно есть

Короче

• Быть C++-фанатом (что бы это не значило): ОК
• Быть C++-хейтером: ОК
• Быть (C++-фанато)-хейтером: уже не ОК, тут начинается зыбкая почва межличностных отношений

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

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

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

суть в том, что в деструкторе должен быть уничтожен pimpl, как в примере выше - объект класса Implementation. но у него есть только forward declaration, а вызывать delete для объекта только с forward declaration нельзя. поэтому я обычно делаю в таком духе. это в hpp файле

struct test_impl;
class test {
  std::unique_ptr<test_impl> _pimpl;
  test_impl& pimpl() { return *_pimpl; }
  const test_impl& pimpl() const { return *_pimpl; }
public:
  test();
  ~test() noexcept ;
};

test::test() : _pimpl(std::make_unique<test_impl>()) {}
test::~test() noexcept =default;

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

и forward declaration вместо include в заголовочных файлах

Не очень понял, а это влияет на пересборку?

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

Ну смотри. Вот есть библиотека и сторонняя программа, которая использует эту библиотеку. В библиотеке есть есть некий главный заголовочный файл header0.h, который подключает программа в своем исходнике, кроме того при сборке программы она линкуется с данной библиотекой. Также есть заголовочные файлы допустим header1.h, header2.h, header3.h, которые ты НЕ включаешь в header0.h, а включаешь в файл исходного кода source0.h. При изменении в header1.h, header2.h, header3.h или в соответствующих им файлах исходного кода библиотеки, библиотека будет пересобрана и соответственно программа, которая включает header0.h и линкуется с библиотекой все равно будет пересобираться. Так в чем профит? Или какой другой кейс?

Ты немного про другое говоришь.

/* --- header0.h --- */
struct Header0_Data { int a; };

/* --- header1.h --- */

// здесь вместо инклюда header0.h делаешь
// forward declaration
struct Header0_Data;

class Header1 {
   Header0_Data* d1; // ок
   std::shared_ptr<Header0_Data> d2; // ок

   // пару лет назад на gcc прокатывало
   // msvc кидал static_assert на отсутствие определения Header0_Data
   // Не знаю кто по c++ стандарту себя ведёт, а кто по понятиям
   std::unique_ptr<Header0_Data> d2; 

   void create1() { d1 = new Header0_Data(); } // error, тип Header0_Data не определён
   void create2();
};

/* --- header1.cpp --- */

// В cpp файле уже делается include,
// если нужно работать с членами Header0_Data
#include "header0.h"

void Header1::create2() { d1 = new Header0_Data(); } // ок

Например, если header3.h включает в себя header2.h, который включает header1.h, который включает header0.h, то при любом изменении в header0.h вся эта цепочка (их cpp файлы) будет пересобрана. В случае же когда в header1.h только forward declaration, вся эта цепочка пересобираться не будет. Только файл header1.cpp, что в три раза меньше по количеству.

Вот так ты, юзернейм, остановил эффект домино.

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

1. Стандарт языка намеренно избегает реального мира, это такое описание языка, оторванного от компьютера, от ОС, от окружения. Результат — не учитываются реальные юзкейзы и проблемы разработчиков. Как следствие множество Implementation-defined behaviour, Undefined behaviour и Unspecified behaviour. И да, это все разные вещи! То есть ты как бы можешь написать программу, которая синтаксически корректна на всех компьютерах во Вселенной, но на практике она не совместима между ними из-за различий в архитектуре, ОС, и т.д.
2. Реализации языка используют архаичный сишный тулчейн для сборки. Все так или иначе упирается в Makefile или его аналог, который компилирует .cpp файлы в объектные, а затем их линкует между собой. И самое смешное, что это все нестандартное, даже близко, каждый натурально дрочит как он хочет. И да, то, что хорошо работает для си, из рук вон плохо показывает себя в С++. Весь этот головняк с вечнокомпилирующимися header-only библиотеками, распухающие из-за них бинарники (фактически копипастить код для каждого T — еще одна гениальная придумка плюсовиков, но я обещал уложиться в два пункта!), попытка хоть как-то это побороть precompiled-headers, для которых тоже нужен тулчейн, который еще более нестандартный. Заголовочные файлы — это мрак, кошмар и архаика.

Теперь перечитай каждый пункт пару раз и сложи два-плюс-два.

И все благодаря этому ТС в 2022 году ебется с невменяемым временем (пере)компиляции С++-ного кода! Зато у плюсовиков есть рецепты, а главное оправдания, всему этому неописуемому пиздецу.

Не заметил. Хаешь.

Нет, я принимаю его таким какой он есть. Давай вернемся к изначальному комментарию, с которого ты триггернулся:

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

Я хаю вас, слепых защитников своего любимого инструментика.

А ты в каких языках компетентен, мэтр?

С++ — один из основных моих языков, внезапно.

Один костыль логически обосновывает другой, и так по кругу, концов не найти.

Напомни, это свойство в математике называется «полнота» или «непротиворечивость»?

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

Я хаю вас, слепых защитников своего любимого инструментика.

Такое ощущение, что вы вкладываете в «оправдывать» всего лишь один, нужный вам смысл. Для вас «оправдывать» выглядит тождественным «одобрять».

Тогда как в большинстве случаев люди, более-менее знакомые с историей развития C++, в «оправдывать» вкладывают смысл «объяснимо». Многие недостатки (реальные и мнимые) C++ «оправдываются» (т.е. «объясняются») вполне себе объективными причинами, существовавшими на том или ином этапе развития языка. И да, эти причины как раз таки логичны и объяснимы.

Так что из того, что многие косяки C++ логически оправдываются не следует то, что эти косяки одобряются сиплюсплюсниками, даже вполне себе увлеченными этим языком.

А вот персонажи, подобные вам, в 2020-х выглядят уже откровенно убого, ибо все ваши «претензии» (в том числе и озвученные в вашем комментарии) уже по 100500 раз разбирались и переразбирались.

Короче. Давай на более низком уровне. В твоем случае не будет перекомпиляции единиц трансляции header1.cpp, header2.cpp, header3.cpp, которые включают header1.h, header2.h, header3.h, т.е. не будут заново создаваться соответствующие объектные файлы header1.o, header2.o, header3.o. Но при этом последующая линковка будет и будет пересоздан выходной исполняемый (или библиотечный) файл. Т.е. если мы понимаем под сборкой компиляцию+линковку, то пересборка уменьшается частично.

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

Понять - не значит простить (с)

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

Ну не все так плачевно. Под сколько архитектур ты обычно разрабатываешь?

Реализации языка используют архаичный сишный тулчейн для сборки. Все так или иначе упирается в Makefile или его аналог, который компилирует .cpp файлы в объектные, а затем их линкует между собой. И самое смешное, что это все нестандартное, даже близко, каждый натурально дрочит как он хочет. И да, то, что хорошо работает для си, из рук вон плохо показывает себя в С++. Весь этот головняк с вечнокомпилирующимися header-only библиотеками, распухающие из-за них бинарники (фактически копипастить код для каждого T — еще одна гениальная придумка плюсовиков, но я обещал уложиться в два пункта!), попытка хоть как-то это побороть precompiled-headers, для которых тоже нужен тулчейн, который еще более нестандартный. Заголовочные файлы — это мрак, кошмар и архаика.

Ух. На все это отвечать нет времени. Но вот последнее замечание про заголовочные файлы. Я вот считаю, что заголовочные файлы - крайне удобная штука. Вот берешь ты либу и сразу по клику на функции/классе попадаешь в ее объявление - по моему супер удобно. Не нужно сразу в доки лезть. Можно быстро оценить интерфейс класса, посмотреть, кто от кого наследуется и т.д. А без этого нужно было бы искать все в документации по либе, которая не всегда подробная или вообще есть.

Понять - не значит простить (с)

Такой смысл так же мог бы быть, если бы не одно но: что значит «простить» для инструмента?

И все благодаря этому ТС в 2022 году любится с невменяемым временем (пере)компиляции С++-ного кода! Зато у плюсовиков есть рецепты, а главное оправдания, всему этому неописуемому звездецу

Всё так, тут оратор выше мне в одном из прошлых крестосрачей пытался рассказать, что у C++ самый быстрый компилятор в индустрии. Хотя де-факто медлененее компилятор разве что у Rust, и то только потому, что его писали крестовики, которые в упор отказывались видеть проблемы в двухчасовой перекомпиляции проекта, потому что «ничего страшного, мы параллельно будем заниматься другой веткой».

Один костыль логически обосновывает другой, и так по кругу, концов не найти.

Напомни, это свойство в математике называется «полнота» или «непротиворечивость»?

Это полнота и противоречивость.

Многие недостатки (реальные и мнимые) C++ «оправдываются» (т.е. «объясняются») вполне себе объективными причинами, существовавшими на том или ином этапе развития языка. И да, эти причины как раз таки логичны и объяснимы

Даже сам Страуструп отмахивается и отказывается технически обосновывать недостатки языка, одним махом находя маркетинговое оправдание всем недосттакам: «есть языки, которые все ругают, и есть языки, которыми никто не пользуется». То самое «worse is better», которое на самом деле «survival is better», и по итогу не имеет никакого отношения к техническим деталям, а основывается на популярности любой ценой. В случае C++ за популярность Страуструп заплатил вполне конкретным техническим убожеством наспех слепленных несогласующихся фич, и он вполне осознает этот факт.

Я вот считаю, что заголовочные файлы - крайне удобная штука

Подъехало очередное неоправдание...

Даже сам Страуструп отмахивается и отказывается технически обосновывать недостатки языка

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

Во-вторых, прочитайте Design And Evolution of C++. Хотя бы.

Да, если захотите мне еще какую-то портянку из бреда написать, то посмотрите внимательнее на «во-первых».

Подъехало очередное неоправдание…

И это твой аргумент? Блин. Да ты сам как фанатик себя ведешь.

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

(Я не программист, но) ccache? Модульная архитектура?