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

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

Ну, во-первых, строители реализуют в материале готовые решения, а программисты разрабатывают новые, что не одно и то же. Во-вторых, если брать сложную программу, то число различных факторов там, влияющих на безопасность, думаю, больше, хотя на 100% утверждать не буду, т. к. не строитель. Ну и самое главное, отлаженные программы обычно нормально работают, как и хорошо спроектированные и построенные дома долго стоят. Однако существует множество людей, ищущих в этих программах уязвимости. Т. е. если бы таких людей не было вообще, то и проблем бы не было, и пароли были бы не нужны. Если сравнивать это со строительством, то тут корректнее говорить не о домах, а о крепостях, которые кто-то постоянно пытается разбомбить с воздуха, совершить подкоп и подорвать (или просто тихо проникнуть), разнести ворота и т. д. И вот с этим масса проблем. Сначала строили замки. Потом выяснили, что от пушечных ядер они не очень-то защищают, и изобрели бастионы. Затем оказалось, что против бомб и снарядов бастион тоже не долго устоит, и стали создавать подземные укрепления с использованием нескольких материалов (внутри толстый слой железобетона, а снаружи толстый слой земли). Такие доты были эффективны, но не абсолютно неуязвимы. При массированной бомбардировке или арт обстреле они тоже могли пасть. А иногда и при точном попадании в пулемётную щель гранатой (вспомни подвиг Матросова). Но с появлением ядерного оружия они стали совершенно неэффективными. Для защиты от него стали создавать шахты глубиной в десятки метров. Однако и эта защита не долго оставалась эффективной. Нынешнее ядерное оружие при прямом попадании легко разнесёт такую шахту, поэтому в случае ядерной войны очень важно выпустить ракеты, размещённые там, до того, как вражеские ракеты поразят цели, для чего решение надо принять за несколько минут (а решение такого рода принимается на уровне президента). Так что и тут не всё так просто, а ты хочешь, чтоб твоя бесплатная программа была абсолютно неуязвимой, да ещё с первого раза и навсегда.

Алло, модераторы!!!! Где вы?! Бан этому когда будет?! Установили что это троль, теперь это оскорбляет программистов и врёт паралелльно о строителях.

Вот откуда на ЛОРе такая любовь чуть что, бежать плакаться модератору? Я ещё могу понять, когда человек лично тебя оскорбляет, или откровенно спамит, или флудит. Но тут разговор вполне себе по теме. У каждого может быть своё понимание или непонимание проблемы. И форум как раз и предназначен для того, чтобы тот, кто чего-то не понимает, наконец понял, а тот, кто понимает, понял ещё лучше, возможно, скорректировав свою точку зрения или, оставшись при своём, как минимум узнал бы аргументы оппонентов. Для этого и нужны вопросы и дискуссии. А если каждого, кто говорит что-то такое, что лично тебе кажется диким (а ему может казаться дикой твоя точка зрения), объявлять тролем и банить, то зачем тогда вообще форум? Просто создай faq, и пусть все читают, внимают твоей мудрости и ни в коем случае ничего не комментируют, только лайки ставят.

Никак, и ты сам знаешь почему :)

всё же современным программистам слишком много позволено. и самое главное они думают в первую очередь о себе любимых а не о конечном пользователе. программа тормозит и жрёт память? ну и что, зато код очень красиво организован в миллион классов и объектов. писать на C++. фууу это же не модно. давайте возьмём джаваскрипт. да, тормозит, ну и что, зато каждый школьник с 7 классами образования может написать, зачем заморачиваться и напрягать мозги. протестить все варианты развития событий в коде. да нууу, будем выпускать апдейты что бы пользователь сцука не расслаблялся и выкачивал постоянно эти самые апдейты. вон на андроиде апдейты приходят чаще чем смски. дополнительно ещё и ментейнеры дистрибутивов добавят веселья тупым подбором версий библиотек с которыми вроде запускается но правда иногда падает, библиотеки то тоже надо апдейтить внося по мелочи проблемы во всех их зависимости которые проявятся никто не знает когда. программисты ни за что не несут ответственности, строителей же ждёт суд если что то развалится.

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

С этим согласен. Отчасти это связано в значительной степени с огромным числом быдлокодеров, а отчасти с общей тенденцией рассчитывать на то, что железо всё потянет, если не сразу, то в недалёком будущем. В общем-то, обе тенденции в этой ветке уже обсудили, и подробно повторять уже высказанные мысли на этот счёт не вижу смысла.

зато каждый школьник с 7 классами образования может написать

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

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

Выбирай стабильные дистры. Но цена стабильности — отсутствие последних версий. Оно и понятно, ведь чем дольше ты тестируешь, тем медленнее обновляешься. Но выбор тут есть.

программисты ни за что не несут ответственности, строителей же ждёт суд если что то развалится.

Если речь о свободном бесплатном ПО, то не несут, что, имхо, вполне логично: странно было бы требовать каких-то компенсаций от человека, который просто подарил тебе что-то, предупредив заранее об отказе от ответственности. А если программа коммерческая, то вполне могут нести ответственность. В лицензии для той же Windows, например, сказано (или как минимум когда-то говорилось), что MS готова нести материальную ответственность за убытки, но не превышающую стоимости ПО. А где-то ответственность может и превышать стоимость ПО. Это как договоришься. Наконец, в отдельных случаях, там, где из-за багов могут быть человеческие жертвы (на АЭС, например), думаю, возможна и уголовная ответственность, если удастся доказать, что программист допустил преступную небрежность. Ну а уж за злой умысел и сейчас сплошь и рядом судят.

там вроде было написано что несёт ответственность максимум в размере одного доллара

там вроде было написано что несёт ответственность максимум в размере одного доллара

Раньше точно признавали за собой ответственность в размере стоимости купленного экземпляра ПО. Как сейчас, не знаю, но не думаю, что в размере одного доллара, потому что такое лицензионное соглашение очень походило бы на троллинг клиентов, вызывая у них ответные чувства по отношению к MS, что последней совсем не нужно. Тогда уж проще сразу отказаться от ответственности, потому что подобный отказ вызовет меньше негатива, чем ответственность на сумму в $1.

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

слышал что вроде бы в какой то старой их версии было такое лицензионное соглашение может там 95 или 98. может не один доллар а 3 доллара но что то типа того.

может там 95 или 98. может не один доллар а 3 доллара

Ну, таких подробностей из 90-х я уже не вспомню. :-)

В смысле «бугагага оскорбился бедный оанимус»? Если какой-то регистрант, простите, нарочно обдристался рядом со мной, то я не собираюсь молчать об этом. Для справки, я не получаю за программирование деньги.

JB, я не могу постить в спец созданный топик. В треде ТС показал себя троллем, потом это было доказано, потом он просто берега потерял. Нужно с этим что-то сделать, либо отпишите, что, как минимум, 4.2 он не нарушал и т.п. Возможно, на ваш взгляд, я зря пишу модераторам, дак дайте знать. Спасибо.

писать на C++. фууу это же не модно. давайте возьмём джаваскрипт. да, тормозит, ну и что, зато каждый школьник с 7 классами образования может написать

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

протестить все варианты развития событий в коде.

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

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

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

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

Иранцы решились. :-)

В C++ самое сложное - заставить работать среду разработки.

Там ещё множество проблем с указателями и ub, как и в си.

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

Динамически типизированный язык хорош для написания небольших скриптов на 1 — 2 странички. А вот зачем такие языки используют для написания мега-проектов, я тоже не понимаю.

слышал что вроде бы в какой то старой их версии [skip] может не один доллар а 3 доллара но что то типа того.

Вот только что подумал, что может это была просто гипербола, а ты воспринял её буквально и запомнил? Типа как если бы кто-то сказал «да вопрос на 3 копейки», имея в виду, конечно, не буквально 3 копейки, а сумму, доступную практически каждому.

Там ещё множество проблем с указателями и ub, как и в си.

Не замечал, чтобы это было большой проблемой. И на управляемых языках типа Java и C# приходится решать сложные задачи, рядом с которыми эти особенности C/C++, требующие аккуратности и дисциплины, явно не являются большой проблемой. Хуже когда проект не компилируется, потому что линкер завершается с ошибкой, которую непонятно как исправить. Если я создаю проект на C# в Visual Studio или на Java в Eclipse, содержащий одну пустую форму, он сразу компилируется и запускается, хотя программа ещё не делает ничего полезного - но это заготовка, от которой можно отталкиваться. А вот чтобы то же самое сделать в CodeBlocks на C++, требуются следующие пляски с бубном:

1. Скачать исходники wxWidgets 2. Скомпилировать их тем же компилятором, который используется в CodeBlocks (причём из командной строки и с кучей неочевидных опций). Отдельно для debug, отдельно для release. 2. Создать в CodeBlocks глобальную переменную, в которой указан путь к установленной и собранной wxWidgets 4. Создать проект в CodeBlocks, в котором указаны опции, соответствующие тем, которые использовались при компиляции wxWidgets.

Я вообще не представляю, как в принципе в таком можно разобраться самостоятельно, когда никто тебе это наглядно не показывает. И это - только чтобы начать работать, чтобы просто скомпилировалась программа с пустым окном. Но вот дальнейшие шаги в C++, на мой взгляд, даже несколько проще, чем в Java, поскольку объектная модель в wxWidgets интуитивнее, чем в Swing/AWT. А уж как скомпилировать программу в QT Creator для меня до сих пор тайна за семью печатями, т.к. я пока не нашёл человека, который бы мне это показал.

И то, если использовать C++ Builder, там вообще всё работает из коробки, никаких плясок с бубном не требуется. Единственное, с чем приходится повозиться - это редистрибьюция vcl.

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

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

да миллион классов всё усложняет ещё больше

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

С предсказуемым результатом )))

Вы сейчас хотите поговорить о полиморфизме или просто от балды брякнули?

Там ещё множество проблем с указателями и ub, как и в си.

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

Это как раз лучше, потому что проблема очевидна. В случае же с ub и некорректным использованием указателей программа может нормально выполняться при отладке и тестировании, а потом в один прекрасный момент упасть или выполниться некорректно. И хорошо, если только упадёт: это, по крайней мере, сразу будет заметно. А ведь может ещё и отработать и даже выдать правдоподобный, но неправильный результат. Ну и если пользователь заметит, что программа лагает, и напишет баг-репорт, этот баг ещё надо воспроизвести, что тоже может быть непросто, особенно когда нет постоянного личного контакта с пользователем.

А вот чтобы то же самое сделать в CodeBlocks на C++, требуются следующие пляски с бубном:

1. Скачать исходники wxWidgets 2. Скомпилировать их тем же компилятором, который используется в CodeBlocks (причём из командной строки и с кучей неочевидных опций).

Ну, это уже, имхо, проблема не си++, а конкретно вижуал студии при использовании в ней свободных компонентов.

А уж как скомпилировать программу в QT Creator для меня до сих пор тайна за семью печатями

А в чём проблема? qmake -project, далее при необходимости редактируем pro-файл (а можно его сразу создать руками), потом qmake && make. Подробнее см., например, здесь.

Единственное, с чем приходится повозиться - это редистрибьюция vcl.

У всех этих проприетарных компонентов одна проблема: они существуют ровно до тех пор, пока их поддерживает производитель и ровно на тех платформах, на каких производитель считает нужным. А чтобы что-то форкнуть, надо начать с нуля. Если речь идёт о давно существующем проекте, то это одно дело. А в новых проектах я бы не стал завязываться на такое без особой нужды. Благо, и под оффтопиком есть версии свободных компиляторов и свободных библиотек.

Все хотят в быстрые сроки, стабильно, производительно и красиво, но выделяют деньги только на первое и иногда на второе. Не работает так.

Такое тоже есть.

какой идиот позволил

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

молодцы кто подсунул аллабабахнутым коня

У всех этих проприетарных компонентов одна проблема: они существуют ровно до тех пор, пока их поддерживает производитель

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

Ну, это уже, имхо, проблема не си++, а конкретно вижуал студии при использовании в ней свободных компонентов.

Вообще-то я сейчас про свободный CodeBlocks. В Visual Studio как раз всё работает без плясок с бубном.

А в чём проблема?

В Windows свои проблемы, в Linux свои. В Windows ошибка линкера, в Linux не находятся заголовочные файлы. И если в Windows я хотя бы вижу, что куда ставлю, Linux всё ставит куда сам хочет. Ладно бы работало после этого. Не говоря уж о том, что почему-то мейнтейнеры почему-то не сделали QT зависимостью QT Creator, небось, ещё чего-то упустили.

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

А что, для этого обязательно нужно неопределённое поведения? Любая программа может отвалиться в непривычном окружении, даже если писать её на надёжной и кроссплатформенной Java. Думаете, сборщик мусора гарантирует, что не будет утечек памяти? При неаккуратном написании кода утечка возможна и в управляемом коде.

Против полиморфизма ничего не имею. Читал о нём в книге «Thinking in C++». А то что бывает даже на сраном PHP наворочают таких классов что страшно становится глядя на миллионы файлов ссылающихся друг на друга в хрен пойми какой последовательности хотя в то же время чисто средствами PHP без всякого ооппа тоже самое сделать было бы понятнее проще и работало бы в 100 раз быстрее.

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

Все хотят в быстрые сроки, стабильно, производительно и красиво

А что, на C++ можно что-то написать красиво?

У всех этих проприетарных компонентов одна проблема: они существуют ровно до тех пор, пока их поддерживает производитель

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

С гномом пример неудачен, потому что есть целых 2 форка: mate и cinnamon. Причём 1-й из них и выглядит как старый гном.

Можно было бы привести пример с kde4, от которого в своё время многие плевались, как сейчас плюются от kde5, и неудачным форком tde. Но в любом случае, если есть достаточное число людей, которые хотят и могут что-то форкнуть, то ничто им не мешает это сделать. В случае же с проприетарщиной форкнуть не получится, всё надо писать с нуля.

В Windows ошибка линкера, в Linux не находятся заголовочные файлы.

Ну, про проблемы с заголовками в Linux можно создать здесь отдельную тему в разделе development с описанием конкретики (какие заголовки, какой компилятор, какая версия Qt, какой дистр и вывод ошибок). Уверен, что проблема быстро решится.

Вопросы про Windows здесь оффтопик, это на каком-нибудь win-форуме. Ну или вкратце вместе с линукс-вопросами под шумок. :-)

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

А что, для этого обязательно нужно неопределённое поведения? Любая программа может отвалиться в непривычном окружении, даже если писать её на надёжной и кроссплатформенной Java. Думаете, сборщик мусора гарантирует, что не будет утечек памяти?

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

Я уже нашёл рабочий инсталлятор QT Creator, программа с пустым окном скомпилировалась. Вот теперь можно спокойно изучать туториалы и пробовать.

А что, на C++ можно что-то написать красиво?

В одной из моих тем мне дали как-то такую ссылку: http://files.rsdn.org/58130/cpp.jpg

Но если серьёзно, я думаю, что на чём угодно (ну или почти на чём угодно) можно написать красиво, если задаться целью.

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

Уже неактуально. Хотя, вообще говоря, было бы неплохо разобраться с тем, почему именно не получалось, чтобы потом знать, как починить, если сломается. У меня уже было несколько успешно починенных проектов в CodeBlocks на wxWidgets, но если что-нибудь сломается в QT, я не смогу это починить. Но меня ждут клиенты, поэтому как-нибудь позже.

Почему то никому не приходит в голову сделать автомобиль весом в 100 тонн пожирающий 500 литров бензина на 100 км и называть это прогрессом. Ни в одной другой сфере разработчики не могут позволить себе так извращаться, ни в одной кроме мать их дестопных говноразработчиков!!!

При проектировании авто аппетит разработчиков ограничен параметрами изделия, которые более чем за 100 лет разработки выжраны и в них нужно вписываться, а в компах и смартфонах их ещё не выжрали. Процесс жора ты и наблюдаешь. Раньше было крутью одноядерник с 512 метрами памяти, а сейчас - ~12 ядерник с ~64 гигами памяти, ССД и винтом от 4Тб - надо вписываться в новую круть чтобы её выжрать. Кто в круть не вписался, его проблемы;)

Ну вот у меня есть представление, что красиво можно писать только на чистом C. На C++ не получится из-за отсутствия интерфейсов (вместо множественного наследования), кривоватой реализации перегрузки операторов (из-за которой приходится объект в правой части оператора делать через функцию, а не метод). На Java не получится из-за стирания обобщённых типов, отсутствия передачи параметров по ссылке и в целом громоздкого синтаксиса. На Java Script из-за динамической типизации. Даже в C# красоте кода мешают кривовато реализованные делегаты и DependencyProperty. Без второго можно пережить, а вот без первого вряд ли - невозможность присваивания разных делегатов одной сигнатуры вынуждает городить определённые костыли.

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

писать на C++. фууу это же не модно.

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

Вообще-то зависимости - это не свойство именно C++. И Java-программа может зависеть от каких-то внешних пакетов, и .NET-программа может зависеть от внешних сборок. Зависимости - это просто разделение труда программистов, один написал какой-то инструмент, который другой использовал в своей программе. Точно так же это не свойство Open Source - можно использовать и платные компоненты. А уж как организовать работу с зависимостями - это дело индивидуального разработчика. Можно все зависимости включить в свой продукт, а можно вытащить наружу. Если говорить именно о C++, то этот язык, напротив, позволяет подключить зависимость как статическую библиотеку, вшив её прямо в свой исполняемый файл. Другое дело, что это приводит к разбуханию исходного кода - если одна и та же библиотека статически используется в нескольких программах, она будет дублироваться в системе столько раз, сколько она вшита в эти программы. А вот разделяемая библиотека займёт своё место на диске только один раз. Кроме того, я сталкивался с тем, что даже если wxWidgets используется в программе лишь единожды, программа весит вместе с этой библиотекой в несколько раз меньше, если wxWidgets выделена в отдельный файл, чем если она вшита прямо в исполняемый файл. Не знаю, с чем это связано.

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

Bro, кто ж виноват, что прогресс не является тем, что ты о нем себе придумал?!

А что это тогда? ИМХО, это когда что-то работает лучше и быстрее, чем предыдущее поколение при прочих равных условиях.

Пример — ДВС: лет 50 назад двигатели употребляли литров 10, выдавали, скажем порядка 60 л.с., лет 30 назад стали потреблять 8, выдавать 80 л.с., и т.д. Никто же не говорит, что давайте в машину поставим ещё один мотор, чтобы получит 120 л.с.?

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

Мне чистый си тоже нравится больше, чем кресты. Но объективно у каждого (или почти у каждого) языка свои фичи и свои недостатки, и надо просто пользоваться фичами и стараться не использовать неудачные вещи.

На C++ не получится из-за отсутствия интерфейсов (вместо множественного наследования)

А что мешает создать базовый класс, ничего кроме чистых виртуальных функций не содержащий? Чем не интерфейс в ява-стиле? Или не хватает самого слова interface? Ну так его можно задать define'ом как пустую строку, только это избыточно.

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

Во-первых, можно и через метод:

struct S
{
  int n;
  struct S operator+(struct S other)
  { struct S res; res.n=n+other.n; return res; };
};

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

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

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

В принципе, есть ещё язык D, в котором попытались устранить все недостатки всех C-подобных языков, но он как-то не взлетел.

Сейчас многие ещё на rust переходят, надеются, что он и си, и кресты вытеснит, хотя я в этом не уверен.

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

Об этом есть неплохая статья https://habr.com/post/150327/.

Во-первых, можно и через метод:

Можно, если текущий тип данных в левой части тоже. А для переопределения cin>> / cout<< уже требуется городить функции, причём в случае cin ещё и скорее всего дружественные. В C#, просто для сравнения, перегруженные операторы - это статические методы того класса, для которого они перегружаются. И если оператор бинарный, неважно, справа или слева будет объект текущего класса - он должен быть хотя бы одним формальным параметром. Ну и для индексаторов в C# отдельная конструкция, которая позволяет не делать костыль, как если в C++ во время поиска по ключу в map не найдено значение, создаётся новая пара ключ-значение. Оно так сделано в C++ не потому что это логично, а потому что единственный способ сделать в C++ индексатор на чтение и запись - это перегруженный оператор [], возвращающий ссылку, и если ссылки нет, её приходится создать - вдруг его хотят использовать для записи в контейнер.

Вот с этим категорически не согласен.

Использование неинициализированных переменных, неправильные имена переменных, повторное определение типа данных, вызов функции без предшествующего прототипа, изменение сигнатуры функции при разыменовывании указателя на функцию, забытый return в функции, которая должна возвращать значение, директивы препроцессора в теле макрофункций. Некоторые неоднозначности, которые могут возникнуть при использовании библиотечных функций, в принципе, понятно, почему не являются ошибками компиляции, но, например, GCC при неправильных фактических параметрах функций printf / scanf выдаёт предупреждение вместо молчаливого ухода в UB.

Понятное дело, что если совсем выпилить из языка неопределённое поведение, то мы лишимся возможности сделать эффективный оптимизатор, которая является основной сильной стороной C/C++. Меня напрягает именно то, что в C оно возникает далеко не только там, где в этом есть необходимость. Конечно же, упомянутый Вами алиасинг может «выстрелить в ногу» не в том месте, где произошло преобразование, поэтому на этапе компиляции это не отследить. Поэтому в данном случае использование неопределённого поведения оправдано.

Сейчас многие ещё на rust переходят, надеются, что он и си, и кресты вытеснит, хотя я в этом не уверен

Меня смущает, что rust как-то слишком не похож на С, чтобы его вытеснить. Даже в D есть странное решение - вместо угловых скобок для работы с шаблонами, как в любом из его предшественников (C++, Java, C#) сделали обычные скобки с восклицательным знаком. Не очень понимаю, в чём был смысл менять привычный устоявшийся синтаксис, да ещё и так, что надо писать на 1 символ больше ))). Хотя в целом максимальная привычность синтаксиса D - это его сильная сторона, просто именно в этом месте его создатели решили пооригинальничать.

Об этом есть неплохая статья https://habr.com/post/150327/.

Статья даже отличная. Но я не понял, как из неё следует наблюдаемая мной ситуация с wxWidgets.

Вообще-то зависимости - это не свойство именно C++. И Java-программа может зависеть от каких-то внешних пакетов, и .NET-программа может зависеть от внешних сборок.

Жаба с нет - развитие тех мусорных технологий что принесли плюсы.

А уж как организовать работу с зависимостями - это дело индивидуального разработчика. Можно все зависимости включить в свой продукт

И легко это делать на цпп в линуксах? Шило из мешка так и прёт. Гцц такой няшка - у самого туева куча зависимостей от внешней системы, уже с него возникает порочный круг.

Если говорить именно о C++, то этот язык, напротив, позволяет подключить зависимость как статическую библиотеку, вшив её прямо в свой исполняемый файл.

Ну да;) запускаешь конфигурацию исходников нового гимпа - подай ему свежую версию плюсов, для той - новый гцц, а тому - другой линукс. Это звиздец какой-то.

Другое дело, что это приводит к разбуханию исходного кода - если одна и та же библиотека статически используется в нескольких программах, она будет дублироваться в системе столько раз, сколько она вшита в эти программы. А вот разделяемая библиотека займёт своё место на диске только один раз. Кроме того, я сталкивался с тем, что даже если wxWidgets используется в программе лишь единожды, программа весит вместе с этой библиотекой в несколько раз меньше, если wxWidgets выделена в отдельный файл, чем если она вшита прямо в исполняемый файл. Не знаю, с чем это связано.

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

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

По идее это тоже порочные практики. НЕТ тоже системный, а значит стимулирует использование зависимостей системы. Обрубят поддержку версии НЕТ когда эти зависимости устанут поддерживать - и хана. Хороший компилятор должен не быть системным и использовать из системы только одобренные его разрабами ништяки, как это сделано в fpc. За это придётся заплатить небольшим снижением производительности, зато больше ПО сможет работать нативно и без эмуляции среды.

Можно, если текущий тип данных в левой части тоже. А для переопределения cin>> / cout<< уже требуется городить функции, причём в случае cin ещё и скорее всего дружественные.

В этом случае — да.

в C++ во время поиска по ключу в map не найдено значение, создаётся новая пара ключ-значение.

Но всегда можно воспользоваться методом find(). Хотя согласен с тем, что автоматическое добавление элемента при обращении к несуществующему ключу не очень логично.

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

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

например, GCC при неправильных фактических параметрах функций printf / scanf выдаёт предупреждение вместо молчаливого ухода в UB.

Имхо, такая реакция должна быть на любое ub.

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

Однако Visual C++ разрешает такое, не выстреливая в ногу. И gcc при задании опции -fno-strict-aliasing такое позволяет. Так что не всё так однозначно.

Статья даже отличная. Но я не понял, как из неё следует наблюдаемая мной ситуация с wxWidgets.

Непосредственно — никак. А опосредованно — через работу линкера, которая там подробно описывается.

Вот вот о чём я говорю. Насрать на тормоза у пользователя главное нам же не красиво писать «class» вместо «interface» и операторы определять. Ну нееет давайте напишем на джаве там очень красивое слово есть «interface». Что память кушает, ой да ладно сейчас она не дорогая.

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