LINUX.ORG.RU

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

 , ,


0

4

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

 — непрозрачные ссылки на forward-объявления структур и функции для работы с ними;
 — публичная структура, которая агрегируется в класс-реализацию;
 — абстрактный класс, он же «интерфейс», от которого наследуется реализация.

Но у всех них есть свои недостатки. Есть ли какие-то иные приемы, которые я упустил?

★★★★

Последнее исправление: xaizek (всего исправлений: 1)

Ответ на: комментарий от ox55ff

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

zerhud
()
Ответ на: комментарий от zerhud

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

zerhud
()
Ответ на: комментарий от zerhud

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

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

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

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

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

alysnix ★★★
()
Ответ на: комментарий от byko3y

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

zerhud
()
Ответ на: комментарий от zerhud

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

X512 ★★★★★
()
Ответ на: комментарий от byko3y

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

zerhud
()
Ответ на: комментарий от zerhud

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

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

menangen ★★★★★
()
Ответ на: комментарий от byko3y

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

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

Crocodoom ★★★★★
()

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

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

Crocodoom ★★★★★
()
Ответ на: комментарий от filosofia

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

filosofia

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

Crocodoom ★★★★★
()
Ответ на: комментарий от Crocodoom

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от Crocodoom

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от Psilocybe

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

Страуструп

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

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 2)
Ответ на: комментарий от byko3y

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

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

zerhud
()
Ответ на: комментарий от zerhud

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

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

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

#include <memory>

using namespace std;

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

private:
    class Implementation;
    unique_ptr<Implementation> m_impl;
};
fsb4000 ★★★★★
()
Ответ на: комментарий от Crocodoom

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

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

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

filosofia
()
Ответ на: комментарий от filosofia

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

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

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

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

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

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

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

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

Crocodoom ★★★★★
()
Ответ на: комментарий от byko3y

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

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

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

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

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

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

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

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

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

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

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

Crocodoom ★★★★★
()
Последнее исправление: Crocodoom (всего исправлений: 1)
Ответ на: комментарий от filosofia

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

Прямо сейчас в процессе составления большого пста, в том числе про этот аспект американской культуры (псто вообще не про кресты так-то). «Ошибки и обратная совместимость» в этих условиях являются единственным способом выживания, то, что называется красивым и непонятным словосочетанием «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 ★★★★
() автор топика
Ответ на: комментарий от Crocodoom

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

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

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от Crocodoom

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

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

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

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

Конечно есть

Crocodoom ★★★★★
()
Ответ на: комментарий от Crocodoom

Короче

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

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от fsb4000

хм, возмжоно не компилируется уже, раньше студийный компилятор это пропускал (это я еще на нем по работе сидел, где-нибудь год 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 ;
};
и это в cpp
test::test() : _pimpl(std::make_unique<test_impl>()) {}
test::~test() noexcept =default;

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

zerhud
()
Последнее исправление: zerhud (всего исправлений: 1)
Ответ на: комментарий от ox55ff

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

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 2)
Ответ на: комментарий от rumgot

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

/* --- 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, что в три раза меньше по количеству.

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

ox55ff ★★★★★
()
Ответ на: комментарий от Crocodoom

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

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

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

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

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

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

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

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

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

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

filosofia
()
Ответ на: комментарий от filosofia

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

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

fluorite ★★★★★
()
Ответ на: комментарий от filosofia

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

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

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

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

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

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

eao197 ★★★★★
()
Ответ на: комментарий от ox55ff

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

rumgot ★★★★★
()
Ответ на: комментарий от eao197

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

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

yyk ★★★★★
()
Ответ на: комментарий от filosofia

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

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

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

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

rumgot ★★★★★
()
Ответ на: комментарий от yyk

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

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

eao197 ★★★★★
()
Ответ на: комментарий от filosofia

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от fluorite

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

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от eao197

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от rumgot

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

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

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

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

eao197 ★★★★★
()
Ответ на: комментарий от byko3y

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

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

Kroz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.