Здравствуйте, Pzz, Вы писали:

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

Вы так говорите, как будто это что-то противоестественное и прямо фу-фу-фу.

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

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

Здравствуйте, Pzz, Вы писали:

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

Я почему-то уверен, что ты обычный человек, пишущий в ядро Линукс уже много лет.


Pzz>Там очень просто всё, и можно найти пример модуля, который делает что-нибудь полезное, и в нем будет всего несколько сот строк.

На плюсах это было бы несколько десятков строк.


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

Pzz>Все эти высокоуровневые абстракции C++ и автоматизмы только мешают.

Странно, а программировать под bare metal никак не мешают, а очень даже помогают. Может, с вашим Линуксом что-то не так?

Здравствуйте, пффф, Вы писали:

П>На сишечке ты эту инфраструктуру пишешь постоянно. Я когда-то писал веб сервер на сишечке. Месяца полтора потратил. Как раз на эту удобную инфраструктуру. На плюсах бы написал бы в лучшем виде за неделю

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

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

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

Здравствуйте, so5team, Вы писали:

S>А если на проекте сделали заточенную под предметную область библиотеку, которая позволяет писать 10 строк вместо 50, то неужели вы предпочтете пердолится и писать по 50 строк там, где ваши коллеги обходятся 10-ью?

Я сам люблю DSL-и. Но надо понимать, что они имеют свою цену.

Здравствуйте, Pzz, Вы писали:

П>>На сишечке ты эту инфраструктуру пишешь постоянно. Я когда-то писал веб сервер на сишечке. Месяца полтора потратил. Как раз на эту удобную инфраструктуру. На плюсах бы написал бы в лучшем виде за неделю

Pzz>А я как-то написал HTTP-proxy на Go. А потом нижний уровень HTTP-клиентской части этой прокси практически целиком переписал руками. Потому, что общался он не с нормальным веб-сервером, а с железкой. И мне надо было в точности знать, что в эту самую железку шлется, потому, что она глючила, и с этим пришлось разбираться.

Так мы не про Go же говорим, а про C++. Они тебе не мешают


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

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

И как же это я на плюсах под контроллеры пишу?

Здравствуйте, Pzz, Вы писали:

S>>А если на проекте сделали заточенную под предметную область библиотеку, которая позволяет писать 10 строк вместо 50, то неужели вы предпочтете пердолится и писать по 50 строк там, где ваши коллеги обходятся 10-ью?

Pzz>Я сам люблю DSL-и. Но надо понимать, что они имеют свою цену.

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

Простейший пример.

Версия номер раз:

const std::vector<some_data> & src = ...;
std::vector<some_data> filtered;
for(std::size_t i = 0, i_max = src.size(); i != i_max; ++i) {
  if(!some_condition(src[i]))
    filtered.push_back(src[i]);
}

Версия номер два:

const std::vector<some_data> & src = ...;
std::vector<some_data> filtered;
for(const auto & item : src) {
  if(!some_condition(item))
    filtered.push_back(item);
}

Версия номер три:

const std::vector<some_data> & src = ...;
std::vector<some_data> filtered;
std::ranges::copy_if(src, std::back_inserter(filtered),
  [](const auto & item) { return !some_condition(item); });

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

Вот в количестве багов оно точно будет. Т.к. не любители C++ первую версию норовят на int-ах написать вместо size_t.

Здравствуйте, so5team, Вы писали:

S>И вот здесь я не понимаю какой именно фидбэк Музыченко ждет от нас, от участников обсуждений. Отсюда и мой вопрос. Ну вот реально ХЗ что ТС ждет от тех, кто осилил очередной поток оторванного от реальности бреда. А если ТС не ждет ответов, то зачем все это было?

Ну очевидно же, что это реакция на соседнюю тему про ссылки.

Здравствуйте, Pzz, Вы писали:

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

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

Здравствуйте, Pzz, Вы писали:

Q>>Естественно считается что ОС должна быть написана кровью на С или ассемблере потому что типа надо очень быстро а C++ это очень медленно.
Pzz>Неа. Когда у тебя ОС, и что-то идет не так, тебе надо очень хорошо понимать, что у тебя на самом деле происходит. Не на уровне сложных абстракций, которые может и работают, как обещано, а скорее всего — нет, а вот по-настоящему. Вот здесь мы ловим такое-то событие и пишем такое-то слово в такой-то регистр, а здесь — вот так вот.
Pzz>Все эти высокоуровневые абстракции C++ и автоматизмы только мешают.

Это ведь поэтому до сих пор возможны спорадические просыпания на pthread_cond_wait ?

Здравствуйте, B0FEE664, Вы писали:

Pzz>>Все эти высокоуровневые абстракции C++ и автоматизмы только мешают.

BFE>Это ведь поэтому до сих пор возможны спорадические просыпания на pthread_cond_wait ?

Я полагаю, они возможны из-за несколько своеобразной реализации posix thread в линухе. Которая связана не с языком, а с тем, что Линус "не понимает", чем процесс с нитями отличается от группы процессов с общей памятью и пулом файловых дескрипторов.

Здравствуйте, пффф, Вы писали:

Pzz>>Там очень просто всё, и можно найти пример модуля, который делает что-нибудь полезное, и в нем будет всего несколько сот строк.

П>На плюсах это было бы несколько десятков строк.

Самый маленький полезный модуль ядра, который я написал, в нем было с десяток строк. Думаешь, на C++ было бы еще меньше?

Здравствуйте, Pzz, Вы писали:

Pzz>>>Все эти высокоуровневые абстракции C++ и автоматизмы только мешают.
BFE>>Это ведь поэтому до сих пор возможны спорадические просыпания на pthread_cond_wait ?
Pzz>Я полагаю, они возможны из-за несколько своеобразной реализации posix thread в линухе. Которая связана не с языком, а с тем, что Линус "не понимает", чем процесс с нитями отличается от группы процессов с общей памятью и пулом файловых дескрипторов.

С одной стороны я может и согласился бы, но с другой: если здесь проблема не связана с языком, то почему в отношении C++ рассуждения проводятся не в том же ключе?

Здравствуйте, so5team, Вы писали:

S>на форуме куда люди приходят за конкретной помощью?

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

S>Жалко, что Евгений опять прикинулся ветошью и примолк. Хотелось бы услышать начальника транспортного цеха.

Жаль, что нам так и не удалось услышать начальника транспортного цеха...

Лично я склоняюсь сейчас к мнению, что С++ не нужен. В том плане, что нет никакой особой нужды в тех его фичах, которые он добавляет поверх С.

Т.е. я конкретно не согласен с этим утверждением:

> При этом, если писать на C, то с ростом сложности и объема трудоемкость растет экспоненциально, а C++ позволяет достаточно долго удерживать ее почти линейной

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

Когда весь мир (условно) начал писать на Go и написал на нём системы самых разных размеров и масштабов, я в этом мнении окончательно утвердился. Т.к. примитивностью Go может соперничать только с С.

И есть старый С++ можно было бы в принципе использовать, т.к. фичи он давал полезные, хоть и не необходимые, то современный С++ это, как говорится, net negative. Если его и использовать, то только с каким-то суровым линтером, который бы отключал ВСЕ фичи языка и давал бы включать их в качестве исключения. Я такого линтера не знаю.

И ещё один минус С++ в том, что он несёт новую семантику в язык. К примеру for (;) {} это валидный С, но невалидный С++. И это большая проблема — если бы С++ был надстройкой над С, то это было бы нормально, а когда получается, что вся семантика программы меняется в совсем неочевидных местах — это ещё один из net negative черт С++.

Здравствуйте, пффф, Вы писали:

П>От STL не обязательно при этом отрыватся, вполне себе используется.

STL не умеет без исключений. Обработка исключений даже на уровне раскрутки стека — вообще механизм непростой, а уж как они реализованы в C++ — это и вовсе лютый ужас. На уровне языка они принципиально не масштабируются, поэтому на самую простейшую реализацию требуется десятка полтора килобайт. В том же GCC они под 8-разрядные AVR/PIC не реализованы вообще, ибо некуда. Реализованы под AVR32 — программа из трех строчек, определяющая std::list, кладущая в него один элемент, возвращающая количество, занимает около тридцати килобайт.

П>Что не так со стандартом и с сообществами?

Там задают тон люди, воспринимающие C++, как просто один из компилируемых промышленных ЯВУ со статической типизацией.

П>шаблон на шаблоне и constexpr'ами погоняет.

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

П>Вот под PIC — там по-моему, плюсов нет и видимо не будет. Потому что не нужно. Там такие смешные возможности, что что-то сложное на нём просто невозможно не сделать, и софт, соответственно, самый примитивный, который и на чистой сишечке за полдня с перекурами пишется

Самое смешное — не нужно как-то специально делать C++ хоть для PIC, хоть для любой другой платформы. Достаточно прикрутить соответствующий кодогенератор. Именно так к GCC прикрутили кодогенератор для AVR, и можно писать на C++ хоть для ATTiny13 (1k для программы, 64 байта RAM), хоть для старших ATMega.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Судя по всему, это происходит потому, что и в Комитете, и среди "активистов развития" все меньше и меньше людей, не только лично способных работать "снизу доверху", но и просто достаточно хорошо знакомых с работой вычислительной системы на всех уровнях. И само по себе это не плохо, если б речь шла об эволюции какого-нибудь нишевого языка, вроде Fortran или LISP. Но беда-то в том, что изначальная универсальность и широта применения C++ привела к тому, что он давно и прочно стал эталоном программирования, как профессии. Если когда-то "всемогущим" программистом считали только того, кто умеет в ассемблер, то сейчас им считают того, кто умеет в C++. Но умеющий в ассемблер, как правило, достаточно хорошо понимает, каким образом к нему сводятся все остальные языки. Когда-то и средний программист на C++, даже не зная ассемблера, неплохо понимал "кухню" вычислительной системы, и хотя бы примерно представлял, как в итоге будет организовано "на железе" выполнение программы, обработка данных, взаимодействие и т.п. А средний современный программист на C++ понимает все это не лучше, чем средний программист на той же Java. Он считает, что программирование — это просто запись алгоритма конструкциями языка, а достойный результат — это просто программа, которая работает в соответствии с ТЗ и не слишком выделяется на общем фоне по требованию к ресурсам.

Мне кажется, что тут ситуация "когда ты молоток, всё выглядит как гвоздь". В том смысле, что дело не в недостаточных знаниях основ ЭВМ, а в том, что такая их (людей из комитета) работа — придумывать что-то новое для С++. Если посмотреть видео с CppCon из секции "Core" или почитать статьи те же людей, то там будет куча искусственных примеров и почти ноль реального кода. Так что по моему мнению, С++ стал заложником корпораций с их неуёмных желанием объять и уничтожить (см. embrace-extend-extinguish).

ЕМ>У того, кто понимает C++ не только со стороны идеологии/стандарта, но и со стороны реализации, крайне редко возникает ощущение, что на нем "невозможно" или "очень трудно" реализовать какую-либо задачу. У того, кто столь же хорошо понимает любой другой язык, такое ощущение возникает гораздо чаще. Программист, хорошо владеющий C++, четко понимает, что он в состоянии реализовать на нем любую парадигму, переписать на него программу с любого другого ЯВУ, пусть и не слишком легко и очевидно. Программист, сколь угодно хорошо владеющий другими языками, такой возможности не имеет — там границы применимости очерчены достаточно четко.

ЕМ>Тем, кто думает, будто программирование на одном языке "ограничивает мышление", надо напомнить, что практически вся современная наука и техника возникла в среде английского языка. Он оказался одновременно и достаточно емким, и достаточно простым, чтобы одинаково удобно выражать как простые понятия, так и сложные. Инженеру, изначально хорошо знающему английский, изучение других языков не поможет развиться в профессии, хоть и обогатит культурно; любую идею материального мира нетрудно выразить на английском.

Не ограничивает мышление, а ограничивает производительность. Я могу почти весь дом построить с помощью одного молотка, но зачем? Я люблю и могу смешивать в проектах разные языки и программы. Мне нравится кодо-генерация, мне нравится интероперабельность. Потому что это быстро и проверено многими людьми. Если мне нужен CRUD, я возьму Rails. Ни для одной другой задачи я не буду использовать Ruby, потому что как язык сам по себе — так себе, но Rails закрывает 99.9% того, что мне может понадобиться в типичном CRUD. А если мне нужно простенькое приложения с парой контроллеров, я возьму Flax, потому что я не хочу держать весь путь, который проходит запрос от браузера до контроллера, со всеми рельсовыми middleware. Я пишу на Си, если мне нужно дёрнуть пару системных библиотек, но если нужно работать со строками или массивами, я пишу на С++, потому что безопасность важнее. Если я обрабатываю данные, то, конечно же, я смотрю в сторону R или Python. Не потому что языки хорошие — языки очень сомнительные, но зато есть большая инфраструктура для моих задач. И если мне нужно написать приложение, где есть немного интерфейса, немного манипуляции данными, работа с ФС и всё в таком духе, то конечно же Java, потому что я не хочу думать про приведение типов, знаковость или особенности перехвата исключений внутри конструктора перемещений временной переменной типа с перегруженными деструктором. Писать всё на одном языке ознает обрекать себя на рутину и написание стаей на Хабр в духе "как мы сделали что-то на языке X как на языке Y" или "ускоряем приложение на языке X путём ассемблерных вставок и переписывания 99% кода на Си".

ЕМ>Это всё я не к тому, что всем нужно ограничиться только C++ или только английским. Но английский, став по факту "языком мировой науки и техники", ничуть не потерял в своем качестве. Специфические понятия из других языков, вроде zen, nirvana, ordnung или vodka, лишь расширяют его, никак не затрагивая основ — все сколько-нибудь базовые понятия по-прежнему легко и компактно выражаются на английском, не требуя привлечения другого языка лишь для того, чтобы описать понятие или явление. А включение в C++ идей и парадигм из других языков привело к тому, что "настоящим C++" стал считаться этот самый "современный диалект".

Вот тут 100% мимо. Английский очень бедный язык в плане описательности или выражения чувств и эмоций, "на первое место выходит умение вставить подходящую цитату, крылатое выражение, картинку/комикс, фрагмент из фильма" это целиком и абсолютно про английский. По крайней мере про американский английсикий. Не знаешь правильное слово или словосочетание? — Не поймут. В России можно сказать одно и то же 1001-им способом, в английском почти всегда только один правильный способ. НО! К программированию это не относится. Тут совсем другая ситуация. До конца нулевых-десятых многие самовыражались, поэтому в мире накопилось куча софта с ошибками и уязвимостями. Когда дело касается обыденного функционала, то я всему руками и ногами за стандартизированный и выверенный, пусть и как две капли воды похожий, код. Всё ещё свежи воспоминания о том, как в каждом очередном форумнов движке были детские уязвисомти по типу включения SQL или HTML. Но поможет ли тут выход новых версия С++? Я очень сомневаюсь. Если со стандартом самого языка всё выглядит более-менее, то попытка добавить в стандарт работу с ФС или графикой ничего кроме смеха не вызывает. Я вообще с трудом понимаю, зачем такие высокоуровневые вещи запихивать в стандарт? Да даже в Java этого нет. Есть всякие JSR, а реализации уже лежат за пределами Java Runtime. Более того, многие JSR типа real-time или распознавания речи настолько устарели и оторвались от реальности, что едва ли кто-то применяет их. Да и зачем? Смысл стандарата в переносимости. А какой смысл в переносимости приложения между совершенно разными по идеологии платформамы? Чтобы потом, как Дум, запускать его повсюди и говорить: "Пацаны, смотрите, прикол!"?

ЕМ>Получилось сумбурно. По-хорошему, такие вопросы надо рассматривать, как минимум, в большой статье, но нет ни времени, ни желания ее сочинять — все равно мало кто поймет.
Зато интересно ) В наши дни почти не удаётся обсудить фундаментальные вещи. Знакомые или ушли из программирования, или разбежались ко компаниями, где платят за JS и докер. Остались только те, кто работает во всяких НИИ, но с ними обсуждать новые стандарты С++ это сомнительное удовольствие.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Мне всегда казалось

Вам казалось.

ЕМ>а на форумы — главным образом с целью обсуждения.

Посмотрите на перечень тем, которые сейчас в хронологическом порядке висят вверху этого форума:

Позиция C++ среди популярных ЯП и его изучение
Вопрос про ссылки - что бы сломалось, если...
C++ теперь точно конец
narrowing в конструкторе
Это UB ?
проблема с memcpy на Linux
Есть ли в плюсах контейнер типа вектора, но
"Трехтомник" по UB в Си
Среда для разработки на С++
Не могу понять ссылки в C++
Исключения
Подсчитыватель Cloc
Подскажите за параметр пак

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

— кто-то обратился за помощью. Мол, не понимаю, не работает, не могу разобраться;
— кто-то поделился информацией. Мол, рефлекшен и экзекушен в C++26 будут, вот пропозалы + некая своя боль (или радость) от этой информации;
— кто-то поделился тем, что сделал. Мол, вот запилили такую вот фигню, кто еще не начал пилить свою может посмотреть на нашу;
— кто-то поделился тем, что собирается сделать. Мол, собираюсь написать пропозал на вот такую вот фигню, кто поддержит/поможет или отговорит.

Так что, как минимум, вы ошиблись форумом со своим спичем.

ЕМ>Но возможно, я снова отстал от жизни, и тренды поменялись.

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

Здравствуйте, vsb, Вы писали:

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

Если мне не изменяет склероз, то:

* в C нет никакой модульности. Хотя бы даже на уровне пространств имен. Следствием чего является необходимость использования уникальных префиксов для имен функций и типов;
* в C нет никаких средств инкапсуляции, которые бы ограничивали доступ к содержимому экземпляров данных. Если структура определена, то в любом месте кода вы можете обратиться к любому её полю. Альтернатива в виде opaque types с вынужденной аллокацией динамической памяти такое себе, т.к. лишает нас возможности для дешевой агрегации и/или размещения экземпляров opaque types на стеке;
* в C нет жесткого контроля за преобразованиями типов;
* в C нет встроенных средств поддержки динамического полиморфизма;
* в C нет стандартизированных встроенных средств очистки ресурсов при выходе из скоупа.

Кстати говоря, в "примитивном" по вашему мнению Go, все это есть.

vsb>И в С++ нет ни одной фичи, которая была бы крайне необходима для борьбы со сложностью.

lavrov.jpg

Здравствуйте, so5team, Вы писали:

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

S>Если мне не изменяет склероз, то:

S>* в C нет никакой модульности. Хотя бы даже на уровне пространств имен. Следствием чего является необходимость использования уникальных префиксов для имен функций и типов;
S>* в C нет никаких средств инкапсуляции, которые бы ограничивали доступ к содержимому экземпляров данных. Если структура определена, то в любом месте кода вы можете обратиться к любому её полю. Альтернатива в виде opaque types с вынужденной аллокацией динамической памяти такое себе, т.к. лишает нас возможности для дешевой агрегации и/или размещения экземпляров opaque types на стеке;
S>* в C нет жесткого контроля за преобразованиями типов;
S>* в C нет встроенных средств поддержки динамического полиморфизма;
S>* в C нет стандартизированных встроенных средств очистки ресурсов при выходе из скоупа.

S>Кстати говоря, в "примитивном" по вашему мнению Go, все это есть.

vsb>>И в С++ нет ни одной фичи, которая была бы крайне необходима для борьбы со сложностью.

S>lavrov.jpg

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

Здравствуйте, vsb, Вы писали:

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

Наличие программ написанных исключительно на ассемблере доказывает, что даже отсутствие структур данных, if-ов и for-ов с while-ми, не мешает писать программы.

lavrov.jpg в квадрате.