Почему все же с++ такой сложный язык?

Причем в новых стандартах всякое весьма сомнительное пихается. Не особо нужное большинству обычных прикладных программистов. Но при этом нет нужного на практике многим. Стандартная библиотека С++ - это малоудобный геморрой для всех, кто имел дело не только с С++. Работа со строками - боль. Да, есть куча разнообразных библиотек, чьих то велосипедов. И очень часто все эти многочисленные велосипеды так стадии альфы с бетой и не перерастают. Обилие говна не делает жизнь сладкой. Лучше меньше да лучше. Пусть будет одна библиотека, но хорошая и стандартная. Тот же C# со своими библиотеками просто конфетка

У парня с Хабра (0xd34df00d) с его «Пора на свалку» синдром обыкновенного горя от ума. KISS принцип забыл. Делай это проще, дурачек - как раз для таких был придуман. Как и для любителей считать факториалы на стадии компиляции. На фига ?! А если у факториала не константа в аргументе, а переменная ? Всё, кончилась магия ?)))

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

Не только один С++ пошел не туда, новые ЯВУ тоже так себе, всё развитие IT. Идиотская мода на функциональщину с наркоманским синтаксисом. Суют куда попало. Такое чувство, что делали не люди, а какие то укурки в бреду. Придумывание новых терминов давно известным истинам. В стиле Канта. Чем вычурнее, тем умнее себе кажутся))).

Не только один С++ пошел не туда, новые ЯВУ тоже так себе, всё развитие IT. Идиотская мода на функциональщину

Эта мода старше чем С++, ML, Hope почти ровесники си, лисп вообще старше всех кроме фортрана.

Он работал в сфере высокопроизводительных вычислений. Как раз там, где С++ сияет, по словам адептов.

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

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

Что это значит и как должно быть?

Это значит, что чтение типа превращается в разгадывание шарады «по спирали»:

https://habr.com/ru/post/100104/
https://webhamster.ru/mytetrashare/index/mtb0/1467033248FT6hne92kG

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

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

Эта мода старше чем С++, ML, Hope почти ровесники си, лисп вообще старше всех кроме фортрана.

А толку ? До сих пор не взлетела эта функциональщина. В отличии от того же С++. Интересна по сути лишь маргиналам. И так же востребована

А должно быть как в Голанге Это дико неудобно. Так же как речь мастера Йоды.

А должно быть как в Голанге.

Как говорится, упаси бог как в Go. Дико неудобно и непривычно. Конечно, можно и справо налево переучиться писать. Но зачем ?!

Эта мода старше чем С++, ML, Hope почти ровесники си, лисп вообще старше всех кроме фортрана.

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

в остальном языки почти одинаковые

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

А должно быть как в Голанге.

Разговор же вроде про раст был, а там лучше чем в голанге, там прямо содрано с OCaml.

А толку ? До сих пор не взлетела эта функциональщина.

Вполне взлетела, начиная с полноценных языков типа scala, F# и haskell и заканчивая тем что она внедряется во все современные императивные языки включая и С++.

А должно быть как в Голанге Это дико неудобно. Так же как речь мастера Йоды.

Это как раз в си и с++ все наизнанку вывернуто. А Йода мастер программы на форт бы писал.

Счастливой отладки»?

Скорее всего получишь ошибку компиляции о несоответствии типов или что-то вроде.

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

#include <iostream>
using namespace std;
void f(int *p) {
	p += 4;
	cout << *p << endl;
}
int main() {
	int *p;
	f(p);
}

$ clang-tidy --checks=cppcoreguidelines-pro-bounds-pointer-arithmetic 1.cc
197 warnings generated.
/tmp/1.cc:5:4: warning: do not use pointer arithmetic [cppcoreguidelines-pro-bounds-pointer-arithmetic]
        p += 4;
          ^
/tmp/1.cc:11:2: warning: 1st function call argument is an uninitialized value [clang-analyzer-core.CallAndMessage]
        f(p);
        ^
/tmp/1.cc:10:2: note: 'p' declared without an initial value
        int *p;
        ^
/tmp/1.cc:11:2: note: 1st function call argument is an uninitialized value
        f(p);
        ^

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

По-моему это много гибче, чем костылить каки-то unsafe на уровне языка.

Как минимум, две очевидные причины:

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

Применительно к явной отметке unsafe в коде адепты Rust-а, мне кажется, либо лукавят, либо находятся в каких-то уютных и огороженных условиях. Мол, можно выставить флажок и компилятор откажется принимать код, в котором есть unsafe.

Это не будет работать в реальном мире, когда вам нужно использовать стороннюю библиотеку с кучей unsafe внутри. Ибо выбор простой: либо вы закрываете глаза на наличие этих unsafe, либо же реализуете ее функциональность сами (что может вылиться в тысячи человекочасов работы и на это, естественно, никто не пойдет, кроме совсем уж повернутых на безопасности).

Мол, можно выставить флажок и компилятор откажется принимать код, в котором есть unsafe.

Мне кажется ты не совсем понимаешь, unsafe это такая же неотъемлемая часть раста как тот же боров чекер, без него раст просто не полноценный. Так что цели обходится совсем без unsafe быть не может, даже та же системная библиотека это тупо не позволит. Другой вопрос это минимизировать использование unsafe, это вполне хорошая годная практика.

Применительно к явной отметке unsafe в коде адепты Rust-а,

Это гораздо лучше чем неявный unsafe везде.

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

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

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

Так а зачем явный unsafe? Кто-то ведь ревьюить должен и обращать внимание на опасные места. И я просто к тому веду, что «подчеркнуть маркером» в цпп все «опасные» места не сложно:

1. включить ворнинг с-каст стиль.
2. grep’нуть на наличие reinterpret_cast, new.
3. отловить всю адресную арифметику через анализатор.
4. всякие штуки вроде out of range stdc++ сама отлавливать умеет.
5. может еще что-то анализатором по желанию посмотреть.
   reinterpret_cast под лупой проанализировали, new в умные указатели переписали, говнокодеров выгнали ).

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

Так а зачем явный unsafe?

В Rust-е это естественный способ указать компилятору «не проверяй меня, здесь я зуб даю, что знаю, что делаю». Поэтому в Rust-е unsafe неотъемлемая часть языка (как goto в C++).

Мой поинт был в другом: адепты Rust-а, утверждающие, что unsafe легко взять под контроль и не допускать появления unsafe в кодовой базе за счет флажков компилятора, недооценивают тот факт, что большой софт строится на базе сторонних библиотек. В которых unsafe вы не контролируете. Либо же вынуждены делать свои версии этих библиотек, без unsafe. И тратите на это кучу времени и ресурсов.

И я просто к тому веду, что «подчеркнуть маркером» в цпп все «опасные» места не сложно:

Это все из категории: опасной бритвой запросто можно пользоваться не причиняя себе вреда, достаточно только a)…, b)…, c)… и т.д.

Оно-то, в принципе, так. Но ведь взять безопасную бритву гораздо проще.

Оно-то, в принципе, так. Но ведь взять безопасную бритву гораздо проще.

Ну хз, вроде не сложно, в конце концов, даже на уровне стандарта можно рекомендовать набор проверок, который надо делать компилятору через какую-нибудь -Wcheck специально для поиска небезопасностей. Раст же ансейф сделал, почему цпп опцию компилятору нельзя? Без всякого уродства кода. Вообще минимум телодвижений для прогера.

Без всякого уродства кода

Вкусовщина и уродство разума. Переубеди меня.

Кроме того, что unsafe не работает в реальном мире, он дает ложную надежду что всё что не unsafe - безопасно. А как показывают недавние новости с firefox/redox - это не так.

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

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

Я кисейная барышня, которая думает что раст безопасный везде кроме unsafe. При этом я пишу хелловорды и переписываю coreutils. Да и вообще, отвечать мне тебе некогда, тут еще много разработчиков в опенсурсе не задавались вопросом переписать программу на раст. Надо бежать. Цемики всем в этом чятики.

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

а чего их противопоставлять – лучше найти общее.

императивный, это «программирование на побочных эффектах». структурный императивный – это структуры данных и алгоритмов, упрощённая верификация (запретом трюков вроде продолжений, замыканий, сопрограмм, octopus stack-ов). модульный императивный – это «скрытие реализации» + «расширяемые записи», которых внезапно, достаточно для реализации компонентной object-based (в духе Ады 83 или VB 6) но не object-oriented парадигмы.

разница между парадигмой X и парадигмой Y, а также между языком который «позволяет программировать на парадигме XXX» (используя костыли и подпорки, а также какую-то магию механизмов реализации костылей и подпорок) и который полноценно её использует – проходит по границе понятия first-class object где object = это понятие, парадигма.

в этом смысле разница между предметно-ориентированными object-based которые позволяют программировать используя или не используя это понятие и object-oriented в котором это ориентированное понятие есть first-class object проходит между некоторым умозрительным операционным замыканием (вроде кольца, поля).

например, в смоллтоке инстанс объекта – объект типа класс. класс объекта – объект типа метакласс (и конструктор это метод метакласса). класс метакласса – объект метакласса, в итоге получаем то самое умозрительное замыкание.

вспоминаем из функциональщины насчёт high-ordered functions, partitial application (currying), partitial evaluation (residual, остаточная программа из суперкомпиляции Турчина).

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

то есть: метакласс объекта это моноид, который поддерживает интерфейсы метакласса (тайпклассы) которые возвращают ещё один моноид (эквивалентный ему в смысле метаобъектного протокола этого метакласса, то есть: интерфейсов механизмов реализации объектной модели, какой-то разновидности ООП).

механизмов реализации ОО модели, таких как: наследование, инкапсуляция, полиморфизм, композиция, агрегация, стереотипы, ассоциации (из UML). это всё тайпклассы = интерфейсы метакласса = интерфейс метаобъектного протокола (ср. протоколы и категории в Objective C, CLOS и MOP в CL, Julia).

если так посмотреть, то объектный моноид это способ локализации побочных эффектов на уровне ООП, его объектов и метаклассов, тайпклассов и отношений в ООП = то есть, монады в функциональном, классы, метаклассы, отношения между ними и объекты в ООП, замыкания в функциональном (например реализация в Scheme объектной модели через замыкания) – это про одно и то же самое, с разных точек зрения.

приходим к идее функциональных объектов (см. Goo, Dylan, частично Clojure) и функционально-объектно ориентированной парадигмы. это тоже объектный моноид, с более чистыми интерфейсами метаобъектного протокола = сиречь, тайпклассами.

если посмотреть на язык LogTalk (= Prolog + SmallTalk), то там реализована объектная модель смоллтока как метаязыка трансляцией в объектный язык пролог. получаем там логические объекты как запросы, логические уравнения, CPLd по ним работает с рефлексией уровня пролога например. и логически-объектно ориентированную парадигму

Вы же умудрились скрестить их

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

и получившегося ежа противопоставить ОО-подходу.

а противопоставлять тут их странно – нужен синтез.

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

привычнее противопоставлять императивный (делай, как я сказал) и декларативный (DWIM: Do What I Mean и догадайся мол сама по какой-то предопределённой стратегии вычислений).

хотя в функциональном противопоставлять императивный Eval и декларативный Apply довольно глупо.

ведь суть метациклического вычислителя и прочих self-interpreter и состоит в том, что в некое умозрительное замыкание кододанных транслируется сначала некий код через Eval + готовые данные, затем некие данные + готовый код через Apply.

в этом смысле это эквивалентные уравнения – ну почти как «амальгама в категории». кододанные = кододанные подействовав разными морфизмами слева и справа.

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

то метапрограммирование это написание метапрограмм. которые конструируют «программу, пишущую программы» из базовых объектных программ.

если макросами лиспа в нетипизированном лямбда исчислении – посредством примитивов метаязыка макросов, метапроцедурами Quote, Unquote, Splice которые позволяют последовательность вычислений AST -> кододанные задать вручую. или отложить на другую стадию вычислений (REPL : Read, Eval интерпретатор интерпретированного или скомпилированного, Print, Loop + трансляция AST кододанные абстрактные -> AST кододанные интерпретируемые -> AST кододанные компилируемые. плюс тайптеги для различий типов значений разных стадий.

если конструируют метапрограмму механизмами наподобие MultiStaged Programming (MetaOcaml, Template Haskell, MetaLua, Lua+Terra, …).

то макросами метаязыка в типизированное лямбда исчисление – посредством немного других примитивов немного другого метязыка макросов: Brackets, Escape, Run. где раз AST получается типизированный, то лямбда от int -> int возвращает значение типа int, а лямбда от int -> code int возвращает AST от int.

из которого может быть затем сконструирован через Escape гарантированно well-formed и well-typed AST, и затем (в другой стадии) вычислен через Run другой сконструированный объектный язык, гарантированно корректный.

здесь получается что раз компилятор производит стирание типов, в макросах лиспа они частично остаются в тайптегах в рантайме. в MSP – переходят на high-ordered типизированное лямбда-исчисление, ну или подобное можно изобразить на зависимых типах и GADT. и иметь например метаинформацию модуля на зависимых типах уровня компиляции (в MSP): staged interpreter метаязыков = translator из одного объектного языка одной стадии в другой объектный другой стадии

казалось бы, причём же тут макросы раста и зависимые типы. и обработка ошибок через монады и коды возврата. и ООП через трейты через отношения механизмов реализации объектной модели ООП (более других, чем в С++: инкапсуляция, наследование, полиморфизм – более общих тайпклассов метаобъектного протокола метаклассов, например мультметоды, специализация, делегирование, полиморфная диспетчеризация и т.п.).

догадаться не сложно же.

Причем какими-то верхними уровнями мы можем еще и не владеть, тогда придется делать пулл-реквест и ждать у моря погоды.

Это работает только в примитивных случаях. Вот давай возьмём твой же пример: где-то глубоко у тебя есть T, который ты хочешь «распечатать в лог». И что делать будешь? Надеяться, что для типа есть to_string или реализован оператор вывода в поток?

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

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

Это ведь вообще о другом.

описывать не то что мы разрешаем делать с типом, а то что запрещаем

Это ты static_assert предлагаешь обмазываться?

забавно, что морфизмы могут быть разные.

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

в этом смысле, Literate Programming можно понимать как ещё одну парадигму метапрограммирования.

которая из single source моноида кододанных блок документации >= блок кода >= блок данных конструирует посредством метапрограммы tangle описанной декларативно на метаязыке описания блоков кода (normal define head, additive define tail, define outlet + juxtaposition для splice/quasiquote/escape для разворачивания макросов на блоках кода) вычисляет её в императивную метапрограмму, конструирующую все эти outlet в отдельных product files.

и через другую метапрограмму weave конструирует из блока документации добавлением pretty printed блоков кода, с индексами, перекрёстными ссылками между индексами – конечную метапрограмму на метаязыке программирования документации (TeX, LaTeX, troff, …) – которая конструируется из кусочков которые вполне себе могут использовать результаты предыдущей стадии, все эти сгенерированные только что product files.

если говорят о Literate DevOps, почему бы не развить в Literate CM.

где First class object таких метаязыков будет конфигурационная единица, базовая конфигурация, ветка/вариант исполнения, версии, сборки, варианты для артефактов.

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

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

А должно быть как в Голанге.

Погоди, ты критиковал раст:

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

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

А должно быть как в Голанге. Жалко, что это осознание появилось настолько поздно.

Ну и, кстати, это придумали не в Go и по моему сейчас так везде (в относительно свежий языках): Scala, Swift, Kotlin и т.д.

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

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

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

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

стираются типы в рантайме, но метаинформация о типах куда они стираются – или выкидывается и существует только в компайлтайме или вполне себе может быть распространена на следующую очередную стадию (если понятно как её распространять: typeinfo модуля в CTFE в D, метаинформация модуля для рефлексии в BBCP, аннотации, зависимые типы, типизированный AST code of int и т.п.)

Язык без либ ничто.

Так точно. Или велосипед на велосипеде. Характерный пример: C, C++ туда же. Обратный пример: JVM-языки за счет интероперабельности с библиотекой Java.

Характерный пример: C, C++ туда же.

Да, языки, на которых написано большинство софта в мире, включая ту же jvm - ничто. Сильно.

а вообще-то морфизмы это какая-то магия , конечно же :)

мало того что кода больше, он не совсем эквивалентный.

цепочка из 7 ифов и одного эсла – в худшем случае исполняется за 8 сравнений.

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

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

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

опять же, паттерн матчинг это скорее всего гомоморфизм.

то есть, гомоморфизм композиции равен композиции гомоморфизмов.

в итоге можно свести полуавтомаГически ещё к более простому.

гомоморфизм слова к гомоморфизму букв.

а цепочка ифов это какое-то расслоение на разные. которые исполняются разное время ибо императивщина. в итоге не все гомоморфизмы равны в смысле сложности вычислений.

неувязочка, ога.

Для многих понимание ПМ в C++ как был, так и остается в категории «а что это и зачем?»

ещё один типичный моноид в категории , для с++-нутых.

в категории непонимания.

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

что характерно, уже в каком-то сноболе где pattern-matching строк это first-class object было понятно что это и зачем.

и что мышление в паттерн-матчингах такого рода навязывает/навязано, обуславливает и обусловлено, порождает и порождено by : ну эндоформизм то есть – немного другие структуры. архитектуры. кода и данных.

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

Они чемпионы по закату Солнца вручную. Когда нужно написать сложный ответственный софт, что делаем? Правильно: используем С++ Builder, Qt.

сложный ответственный софт

Qt

Ой, уморил. Я смотрю, тут клоуны на клоунах, даже если на никнеймах не палятся.

Приведи примеры сложного и ответственного софта на билдере(только под винду, не так ли?) и qt. Без конкретики это ни о чём.

сам билдер?

На электроне и LabView, как в SpaceX.

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

Странно, что такое проговаривать отдельно приходится.

#define простой и безответственный

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