Тут периодически поминают А.В. Столярова, известного своими ортодоксальными взглядами, ненавистью к Комитету и т.п. Почитав дискуссии с его участием, однозначно вижу, что во многом он перегибает палку, но многое становится понятным, если учесть, что он преподаватель, и много лет проработал на кафедре ВМК МГУ — одном из немногих мест в России, где еще более-менее умеют адекватно учить программированию.

У меня в архиве давно валялась его книга "Введение в язык C++", но я даже не пытался ее читать, поскольку основная масса таких книг, написанных за последние двадцать лет, выглядит довольно уныло. А вчера, чисто интереса ради, открыл, и прямо с введения затащился от того, насколько хорошо дядька понимает суть программирования, как профессии (собственно, у него во всех книгах акцент на профессии, как таковой, а не на конкретных языках/системах). Он пишет о многом из того, что я тут регулярно поминаю уже много лет — а ведь мы с ним, судя по всему, вообще никак не общались, даже косвенно.

Он совершенно прав в том, что C/C++ — уникальные языки, по меньшей мере среди известных:

Автору этих строк представляется очевидным, что язык Си (чистый Си) смог стать тем, чем он стал, и занять его нынешнюю нишу благодаря двум своим очевидным свойствам: во-первых, жесткой и очевидной границе между самим языком и его библиотекой, сколь бы "стандартной" она ни была, и, во-вторых, достижимости "zero runtime", т.е. возможности использования созданных компилятором объектных модулей без поддержки со стороны поставляемых с компилятором библиотек. В отсутствие любого из этих свойств язык программирования оказывается неприменим для программирования на "голом железе" (т.е. для ядер операционных систем и для прошивок микроконтроллеров) и, как следствие, не может претендовать на универсальность. Тем удивительнее, сколь упорно создатели "стандартов" пытаются изничтожить оба этих свойства, причем как в Си++, так и в чистом Си".

Подавляющее большинство «современных программистов» реально не видят принципиальной разницы между Си++ и, к примеру, тем же Питоном или Джавой, a все «новые технологии» (включая и новые «стандарты») предпочитают встречать с каким-то нездоровым восторгом, полностью отключив свои способности к критическому мышлению.

Большинство нынешних программистов не мыслит использования Си++ в отрыве от стандартной библиотеки шаблонов (STL)

исходно Си++ представлял собой интереснейшее явление в мире программирования — единственный в своём роде язык произвольного уровня, то есть такой, который позволял заниматься как низкоуровневым (почти ассемблерным), так и сколь угодно высокоуровневым программированием, причём все нужные здесь и сейчас абстракции высокого уровня можно было тут же и создать, не полагаясь на «доброго дядю». Логику построения языка (в той его версии) нельзя было назвать совсем безупречной, но она хотя бы существовала, и, более того, на все её недочёты можно было не обращать внимания как нечто не слишком важное. В «современном» Си++ всего этого уже давно не видно под горой семантического хлама. Следует подчеркнуть, что изначальный Си++ никуда не делся, его возможности по-прежнему используются (хоть в реализации той же пресловутой стандартной библиотеки) — но уловить существовавшую когда-то концептуальную структуру практически невозможно, слишком много чужеродных возможностей этому мешает.

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

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

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

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

Следствием такого подхода становится то, что C++ уверенно дрейфует с позиции уникального и универсального языка к позиции "просто еще одного ЯВУ". И если его приверженцы долгое время согласны были терпеть многие недостатки языка лишь ради этих самых уникальности/универсальности, то с каждой новой версией стандарта становилось понятно, что ряд этих недостатков, скорее всего, не будет устранен никогда — то, что с ними связано, удобнее объявить устаревшим, а взаимен предложить очередную идею, философия которой вроде бы изящна, а техническая реализация — уродлива. Это чем-то напоминает пожилую черную актрису в роли Белоснежки: с одной стороны — "сняты дискриминационные ограничение по возрасту и цвету кожи", а с другой — есть ощущение чего-то фундаментально неправильного.

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

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

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

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

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

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

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

ЕМ>Поначалу, переход от C к C++ вообще никак не затронул нижней границы применимости, но очень серьезно поднял верхнюю границу. Но с течением времени Комитет упорно двигает C++ к такому состоянию, в котором нижняя граница поднимается качественно (систем, в которых можно реализовать хотя бы такое подмножество, без которого большинство программистов попросту неспособно пользоваться языком, все меньше и меньше)

Суть всего текста, как я понимаю, в этой фразе?

Расскажи же, что мешает? На C++ даже для чайников прошивки пишут без всяких проблем. Это дцать лет назад частенько было так, что под железку кроме голенькой сишечки ничего нет, но это давно уже не так

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

ЕМ>Получилось сумбурно. По-хорошему, такие вопросы надо рассматривать, как минимум, в большой статье, но нет ни времени, ни желания ее сочинять — все равно мало кто поймет.

Это точно. Не понял, как люди в комитете не дают писать без стандартной либы, большая часть которой к тому же header-only и тоже вполне себе zero-runtime. Просто не линкуйся с ней и всего делов-то. Линкер скажет, что тебе надо выкинуть

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

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

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

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

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

Да всё правильно, C++ развивают куда-то не в ту сторону, и под действием тяжелых наркотиков.

ЕМ>Получилось сумбурно. По-хорошему, такие вопросы надо рассматривать, как минимум, в большой статье, но нет ни времени, ни желания ее сочинять — все равно мало кто поймет.
Меня так очень напрягает закрытость C++ например таблица виртуальных методов, недоступна так еще и может изменяться компилятором, указатели на члены классов. Это очень хреново для экспорта интерфейсов.
Так же и с корутинами всё спрятано, от глаз долой и сериализация или взаимодействие со сторонним кодом, примерно никак. Вообще изначально C++ была просто надстройкой над C. А со временем
превратилось в черте что, непредставимые значения, указатели и метаинформацией не представимой в runtime и куча других з@&6ов.
Теперь есть скриптовые языки (например lua) которые могут выполнять роль этой надстройки и генерить bolerplate код и язык можно развивать в любом гараже, не оборачиваясь на стандарт. И для этого достаточно любого c-ного компилятора любой древности.

ps: почему php взлетел, потому как там весь набор инструментов был из коробки. В c++ стандартная библиотека даже растровую графику еще не осилила, не говоря уже о gui. Подключение всяких opengl, vulkan идёт через генерацию кода на python-не. Динамические библиотеки для c++ вообще спотыкач знатный. Про совместимось вообще можно только плакать. Трамплины для вызова функций для разных реализаций в зависимости от возможностей процессора, выполняются костылями или еще лучше просто забивают и требую наличие, используемых расширений, а если нет просто падают с загадочными ошибками.

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

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

ЕМ>Фишка в том, что современные железки размером с ноготок, для которых пишутся те прошивки, предоставляют ресурсы, которые во времена становления C++ выглядели пределом мечтаний для многих серьезных систем. Для них любой чайник напишет прошивку хоть на питоне, будь он там реализован, и во многих случаях она даже будет работать с пристойной скоростью.

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

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

А зачем вы этот текст на форуме запостили?

Если это ваше личное мнение, то для такого мнения самое место в персональном блоге. Ну или на Хабре.

Здесь то вы какой фидбэк от людей хотите получить?

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

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

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

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

Сколько Вы, например, знаете разработчиков для мелких МК, которые действительно пишут свои прошивки на С++? Большинство тех, кого знаю я, пишет исключительно на "голой сишечке", воспринимая плюсы, как лютого монстра. В этом заслуга и сообщества программистов, и преподавателей.

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

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

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

Полагаю, можно и без отключения фич. А так — ну, обычно RTTI/исключения отрубаются, но, полагаю, и с ними можно, просто не нужно и место лишнее занимает. Динамическая память? С ней вполне можно. Что ещё?

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


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

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


ЕМ>Сколько Вы, например, знаете разработчиков для мелких МК, которые действительно пишут свои прошивки на С++? Большинство тех, кого знаю я, пишет исключительно на "голой сишечке", воспринимая плюсы, как лютого монстра. В этом заслуга и сообщества программистов, и преподавателей.

Хм, в разное время в разных конторах — ну, человек 50 знаю. В третьей конторе работаю под железки, везде на плюсах пишут. И это не какие-то академические круги, а вполне себе обычная промышленность. В последней так вообще, шаблон на шаблоне и constexpr'ами погоняет. А вот сишечников знал ровно одного — он с PICа пришел, старый дедпожилой мужчина за 60.

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

выделю ключевое для меня.

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

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

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

Для таких средних создан язык Go, который делали как раз НЕ средние программисты.

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

S>А зачем вы этот текст на форуме запостили?

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

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

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

R>что комитет создал рабочую группу если не ошибаюсь, как минимум несколько лет назад
R>которая следит за тем что бы язык развивался в нужном направлении
R>что бы С++ не уходил в абсурд и не становился слишком сложным для изучающих его

Точно следят? Вы новую рефлексию видели?
Что мешает для любой сущности иметь имя? Нафига польскую нотацию из закорючек добавлять?

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

S>>А зачем вы этот текст на форуме запостили?

A>Извините, но наш сайт предназначен именно для обсуждения подобных тем.

Что, правда?

И, я так полагаю, мне это пишет человек, который уже что-то добавил в эту самую тему. Как нет?

Мне думается, что данный форум полезен для вещей вроде:

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

Т.е. есть конкретная польза.

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

Такой спич где-то в личном блоге, в каком-нибудь LinkedIn или на каком-нибудь Habr-е или Medium -- более чем OK.

Но вот здесь, на форуме куда люди приходят за конкретной помощью?

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

A>Не всё же время нам Шимжу и Химика обсуждать!

Да, поэтому давайте добавим клоунов из другого б**дского цирка.

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

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

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

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

R>если кому не лень
R>найдите документы декларирующий все это
R>пусть все узрят

Это? https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2000r4.pdf

S>Какая польза от спича в заглавном сообщении этой темы именно на форуме я не понимаю.
S>Такой спич где-то в личном блоге, в каком-нибудь LinkedIn или на каком-нибудь Habr-е или Medium -- более чем OK.

Если я правильно понимаю, то даже если бы статья была размещена в блогах (blogs.rsdn.org), то обсуждение (комменты) всё равно было бы в тематическом форуме.
Например смотрите статьи в блоге Велкина: http://blogs.rsdn.org/effective/8733954
Комментарии к статье повторяют тему в форуме "Управление проектами" http://rsdn.org/forum/management/8733954

Автор: velkin
Дата: 18.04.24

Т.е. статьи обсуждают в форумах, и это by design на RSDN.

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

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

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

EM>И все это без проблем может совмещать один человек — многие параллельно делают на C/C++ и прошивки к самым мелким МК, и весьма навороченный софт для "большого" компьютера, к которому этот МК подключается.

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

ЕМ>Тем, кто знаком с электроникой, это напоминает идею "давайте забудем про транзисторы и принципы их работы, и все активные узлы будем делать в виде функциональных микросхем, внутреннее устройство которых непринципиально". Тем, кто разбирается в автомеханике — "водителю не нужно знать устройства трансмиссии и подвески, его дело — крутить руль и нажимать педали газа/тормоза".

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

ЕМ>Следствием такого подхода становится то, что C++ уверенно дрейфует с позиции уникального и универсального языка к позиции "просто еще одного ЯВУ".

Я б не стал сейчас начинать новый проект ни на Си, ни на C++. Ну, по крайней мере, при наличии у меня выбора.

ЕМ>Получилось сумбурно. По-хорошему, такие вопросы надо рассматривать, как минимум, в большой статье, но нет ни времени, ни желания ее сочинять — все равно мало кто поймет.

Такие вопросы надо рассматривать за кружкой пива

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

LVV>Происходит ровно то, что и со всеми предметными областями и мастерами в них.
LVV>Инфляция профессии.

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

Вот в автомобилестроении, по большому счету, за последние 100 лет не произошло ничего нового. Автомобили можно смело ставить на конвеер и выпускать на заводе. Что Генри Форд, собственно, и сделал.

А с програмизьмом поторопились.

LVV>Для таких средних создан язык Go, который делали как раз НЕ средние программисты.

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

Судя по тому, что Пайк свалил таки на пенсию, Go выполнил свою задачу.

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

R>что бы С++ не уходил в абсурд и не становился слишком сложным для изучающих его

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

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

LVV>Но для "среднего" потребителя клепают "средние" скрипки в массовом порядке.

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

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

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

Комитет создал подкомитет для борьбы с комитетами. Исчерпывающее объяснение, почему всё так, как оно есть.

2ТС. Нет ничего плохого в желании иметь в стандартной (а не хрен знает откуда взятой) библиотеке всё, что нужно каждый день, от коллекций до регэксов. Другое дело, что STL это самая нечеловеческая куча кода, которая явилась степанову под грибами, как метко написал один автор на лурке.

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

ЕМ>Тут периодически поминают
Музыченко снова бургундии перебрал, похоже. Ты, эта, поосторожнее с этим.

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



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

Pzz>Вот с этим не соглашусь. Экспоненциально она растет, когда сложность переполняет голову автора, и он теряет контроль над собственной программой. Но это не свойство языка, а свойство головы автора, его способность держать под контролем возрастающую сложность системы.
C++ как раз предоставляет средства для управления сложности, как поделить экспоненциальную сложность на меньшие сложности. Думать о том как они (обьекты) взаимодействуют друг с другом, есть разные способы соединить и вширь и вглубь. А меньшими сложностями не забивать голову когда не надо, можно отдать реализовывать другим людям и т.п. Надо тебе две сложности с разными параметрами создал два обьекта, надо что-то поменять создал производный класс. Надо связать разнообразные сложности вместе и потом по ним походить — пожалуйста, создал общий класс для всех и контейнер из него, все сложности туда — ходишь по ним и делаешь чего надо. Надо создал сложность динамически, надо статически... На С такого не особо поделаешь. В смысле на С можно все сделать но как только начинаешь делать чтото большое, расширяемое, красивое так и выходит что изобретаешь фичи C++, правда в которых порой только ты разумеешь. Зачем изобретать то когда уже есть?

фифти фифти
это больше на род мап похоже

в том вроде как то не так было

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

Q>C++ как раз предоставляет средства для управления сложности, как поделить экспоненциальную сложность на меньшие сложности. Думать о том как они (обьекты) взаимодействуют друг с другом, есть разные способы соединить и вширь и вглубь. А меньшими сложностями не забивать голову когда не надо, можно отдать реализовывать другим людям и т.п. Надо тебе две сложности с разными параметрами создал два обьекта, надо что-то поменять создал производный класс. Надо связать разнообразные сложности вместе и потом по ним походить — пожалуйста, создал общий класс для всех и контейнер из него, все сложности туда — ходишь по ним и делаешь чего надо. Надо создал сложность динамически, надо статически... На С такого не особо поделаешь. В смысле на С можно все сделать но как только начинаешь делать чтото большое, расширяемое, красивое так и выходит что изобретаешь фичи C++, правда в которых порой только ты разумеешь. Зачем изобретать то когда уже есть?

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

История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.

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

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

ЕМ>Под них можно писать не на "плюсах", а на определенном подмножестве языка.

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

ЕМ>Когда-то граница этого подмножества была достаточно хорошо видна, но со временем она очень сильно размылась. Работоспособную прошивку под мелкий МК на C++ в состоянии написать тот, кто изучал язык "снизу", в то время, как его преподавание уже давно и привычно идет "сверху". В результате сама идея использования языка в отрыве от STL и шаблонной магии

На тех же атмегах шаблонную магию вообще можно использовать без проблем. Некоторое подможество STL — тоже.

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


Pzz>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.
Похоже Linux изначально сделан на основе unixa, который сделал Ричи — изобретатель C, в то время когда C++ не было и проекте. Кроме того, то что сам пингвин не любит C++ — общеизвестный факт и конечно же он никогда бы не позволил переписывать свой Linux на C++ или чтото там еще. А если бы ядро Linuxа было сделано на C++ то возможно в его разработке могли бы принимать активное участие не обязательно суперпрограммисты типа самого его и красноглазиков а обычные люди. Не факт что это нужно конечно, но было бы неплохо если бы можно было быстренько просечь как там сделан тот или иной кусок просто посмотрев на диаграммы классов их связи а не курить бамбмук годами. Естественно считается что ОС должна быть написана кровью на С или ассемблере потому что типа надо очень быстро а C++ это очень медленно. Это в общем случае заблуждение, я принимал участие в разработке вполне успешной и широко известной (в узких кругах) коммерческой ОС, в которой внезапно внутри некие части ядра на C++, и все там было и быстро и расширяемо, и легко для понимания. Если же не рассматривать ОСи ввиду их особенной специфики, то C++ по крайней мере не менее распространен в сложных проектах чем C. А там где C остался то часто как в Линуксе — потому что он там изначально был, не переписывать же.

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

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

S>>Какая польза от спича в заглавном сообщении этой темы именно на форуме я не понимаю.
S>>Такой спич где-то в личном блоге, в каком-нибудь LinkedIn или на каком-нибудь Habr-е или Medium -- более чем OK.

M>Если я правильно понимаю, то даже если бы статья была размещена в блогах (blogs.rsdn.org), то обсуждение (комменты) всё равно было бы в тематическом форуме.

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

Тогда как топик на форуме (без предшествующей статьи) означает, что автору нужно мнение форумчан.

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

Даже если 150 человек ему напишут "Да, чувак, ты прав на 146%! Мы с тобой!" то что это изменит и на что повлияет? Музыченко напишет свой учебник по программированию? Разработает свою замену C++? Начнет вести курсы по программированию, где будет учить людей самому главному, а не вот этому всему?

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

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

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

Этот пост (он не такой и большой, точно не статья) о С++ в теме про С++, что уже неплохо. Возможно, что в СВ или Философии было бы удачнее. С другой стороны, зачем придираться? Тот же velkin иногда такое напишет, что с телефона в принципе не прочитать. Так что нельзя сказать, что пост Евгения как-то выбивается в худшую стоорну на фоне остальных сообщений.

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

N>Этот пост (он не такой и большой, точно не статья) о С++ в теме про С++

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

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

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

Даже совсем свежий тупизм от Shmj здесь

Автор: Shmj
Дата: 10.07 08:10

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

Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Получилось сумбурно. По-хорошему, такие вопросы надо рассматривать, как минимум, в большой статье, но нет ни времени, ни желания ее сочинять — все равно мало кто поймет.

на С/С++ практически ничего не писал, но в последнее время начал изучать, до этого .NET/Java/Typescript, на заре был ассемблер и Си для контроллеров

С/С++ языки, которые заставляют думать об исполняющем механизме, иногда до деталей (регистры, память, ссылки, указатели) и прочее
Вообще Си, именно Си очень хорошо приводит в порядок мозг, там всегда надо думать, нельзя просто так взять и написать код.

Серьезные вещи можно написать и на Java/NET но придется так или иначе столкнуться с ручным управлением памятью и семантика будет уже С/С++

Сейчас на языках с автоматической памятью подавляющее большинство пишет банальное крудошлепство, или формошлепство 2.0: тут выставили рест контроллер, перемазали спрингом, вот пара ДТОшек, тут мы их перекладываем, тут базенка.
Надо сделать еще фичи, нанимаем еще разрабов и те генерят еще больше кода. Редко кто пишет какие-то многопоточные фреймворки или библиотеки, думает об абстракциях и вылизывает модель — это никому не нужно.

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

несовершенство программной модели часто можно скомпенсировать наймом бОльшего количества разрабов.

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

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

Pzz>Я б не стал сейчас начинать новый проект ни на Си, ни на C++. Ну, по крайней мере, при наличии у меня выбора.

Но обычно его нет. Не в смысле "начальник мудак", а в смысле "свобода это осознанная необходимость". Был бы выбор — "и кто бы тогда в СССР остался" ©

P.S. Облегчить страдания помогает вынос всего, что только можно, в DSL'и.

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

Q>Похоже Linux изначально сделан на основе unixa, который сделал Ричи — изобретатель C, в то время когда C++ не было и проекте. Кроме того, то что сам пингвин не любит C++ — общеизвестный факт и конечно же он никогда бы не позволил переписывать свой Linux на C++ или чтото там еще. А если бы ядро Linuxа было сделано на C++ то возможно в его разработке могли бы принимать активное участие не обязательно суперпрограммисты типа самого его и красноглазиков а обычные люди. Не факт что это нужно конечно, но было бы неплохо если бы можно было быстренько просечь как там сделан тот или иной кусок просто посмотрев на диаграммы классов их связи а не курить бамбмук годами.

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

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

Q>Естественно считается что ОС должна быть написана кровью на С или ассемблере потому что типа надо очень быстро а C++ это очень медленно.

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

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

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

Непонятно, с чего бы.

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

Pzz>C++ пытается превратить смысловую сложность в синтаксическую сложность, но я не уверен, что смысловая сложность от этого куда-то девается.

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


Pzz>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.

Там главпингвин просто упоротый по сишечке. Писали бы на плюсах — и багов меньше было бы, и сложности меньше.

Некоторые (в частности, в GTK) в итоге начинают изобретать плюсы на сишечке — всякие ГОбджекты, метапрограммирование на макросах, и тд и тп. И в самом ядре линукса используют хотя бы те же таблицы виртуальных методов. Только по сишечному — максимально уродливо и небезопасно

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

Pzz>>C++ пытается превратить смысловую сложность в синтаксическую сложность, но я не уверен, что смысловая сложность от этого куда-то девается.

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

Увеличивает, причем кратно.

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

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

Pzz>>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.

П>Там главпингвин просто упоротый по сишечке. Писали бы на плюсах — и багов меньше было бы, и сложности меньше.

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

Ничего бы сюда C++ не добавил.

П>Некоторые (в частности, в GTK) в итоге начинают изобретать плюсы на сишечке — всякие ГОбджекты, метапрограммирование на макросах, и тд и тп. И в самом ядре линукса используют хотя бы те же таблицы виртуальных методов. Только по сишечному — максимально уродливо и небезопасно

GTK — это жудь. Никто не любит GTK, кроме авторов GTK.

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

Pzz>>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.
Q>Похоже Linux изначально сделан на основе unixa, который сделал Ричи — изобретатель C, в то время когда C++ не было и проекте.

Линус начал лабать свой Линукс в 91ом году.
В 1991 году вышла версия Borland C++ 3.0 с поддержкой сборки Windows-приложений. Спустя год вышло обновление 3.1, в котором был реализован оконный IDE и шаблоны приложений OWL 1.0 и Turbo Vision 1.0.


Q>Кроме того, то что сам пингвин не любит C++ — общеизвестный факт

Просто не осилил


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

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

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

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

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

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


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

Pzz>Увеличивает, причем кратно.

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

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


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

Я сменил не один плюсовый проект, никаких проблем не замечал


Pzz>>>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.

П>>Там главпингвин просто упоротый по сишечке. Писали бы на плюсах — и багов меньше было бы, и сложности меньше.

Pzz>Ядро очень хорошо структурировано по самой природе вещей. Драйвера-файловые системы-стеки сетевых протоколов и т.д. Разбивка на "классы" естественная, давно и хорошо продуманная и обкатанная, еще и до линуха всякого, и интерфейсы "классов" тоже всем известны и понятны.

Pzz>Ничего бы сюда C++ не добавил.

Добавил бы. Убрал бы всё ручное управление памятью и ресурсами. А это очень много.


П>>Некоторые (в частности, в GTK) в итоге начинают изобретать плюсы на сишечке — всякие ГОбджекты, метапрограммирование на макросах, и тд и тп. И в самом ядре линукса используют хотя бы те же таблицы виртуальных методов. Только по сишечному — максимально уродливо и небезопасно

Pzz>GTK — это жудь. Никто не любит GTK, кроме авторов GTK.

Просто пример сишечного проекта. Все сишечные проекты скатываются в подобное

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

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

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


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

Здравствуйте, 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 в квадрате.

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

ЕМ>

Большинство нынешних программистов не мыслит использования Си++ в отрыве от стандартной библиотеки шаблонов (STL)

Мне довелось контрибутить в проект без STL, со своими собственными велосипедами, без exceptions.
Я теперь илитка?

ЕМ>[q]исходно Си++ представлял собой интереснейшее явление в мире программирования — единственный в своём роде язык произвольного уровня, то есть такой, который позволял заниматься как низкоуровневым (почти ассемблерным), так и сколь угодно высокоуровневым программированием, причём все нужные здесь и сейчас абстракции высокого уровня можно было тут же и создать, не полагаясь на «доброго дядю».

Это словоблудие. Первая часть утверждения верна, потому что мы все понимаем, что C++ создавался буквально как "C с классами", и совместимость с C в нём by design.
Вторая часть про "какие угодно абстракции высокого уровня" — это вообще что такое? Можно мне, например, рефлексию типов данных здесь и сейчас, без "добрых дядей"? Нет? До свидания.

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

ЕМ>>Под них можно писать не на "плюсах", а на определенном подмножестве языка.

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

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

L>На тех же атмегах шаблонную магию вообще можно использовать без проблем.

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

L>Некоторое подможество STL — тоже.

Что там есть реально удобного, не завязанного на исключения?

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

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

Pzz>Вот с этим не соглашусь. Экспоненциально она растет, когда сложность переполняет голову автора, и он теряет контроль над собственной программой.

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

Ну и сами преобразования типов/указателей в C слишком либеральные. Когда я в 90-х переписывал свои ранние программы с C на C++ (еще до C++98), я везде менял C-style cast на function-style cast. Когда в языке появились операции XXX_cast — стал менять на них, и с тех пор несколько раз было, что компилятор, молча переваривавший какой-нибудь мудреный function-style cast, начинал ругаться даже на reinterpret_cast, и при внимательном рассмотрении я обнаруживал в нем логическую неправильность, которая могла создать проблемы, например, при другой разрядности платформы.

Pzz>Что в сишечке все же раздражает, это отсутствие более-менее стандартной и общепринятой библиотечной поддержки уровня абстракции чуть выше, чем printf(). Ну раздражает в каждом проекте опять делать реализацию динамических строк и протокола HTTP, ну честное слово. Это не сложно, это муторно.

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

Pzz>А не попытка ли это сделать программиста взаимозаменяемым

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

Pzz>Я б не стал сейчас начинать новый проект ни на Си, ни на C++. Ну, по крайней мере, при наличии у меня выбора.

Если б я был чисто прикладным программистом — возможно, я б вообще не связался ни с C, ни с C++. Но, пока я делаю драйверы ядра или код под голое железо, где необходимо четко представлять себе объем занятых и свободных ресурсов, психологически трудно параллельно делать тот же высокоуровневый гуй на каком-нибудь C# или Java. Грубо говоря, когда в модуле драйвера избыточность в районе 10%, в отдельных местах — до 20%, а в сопутствующем управляющем приложении эта избыточность измеряется тысячами процентов, очень трудно сохранять душевное равновесие.

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

Pzz>Вот в автомобилестроении, по большому счету, за последние 100 лет не произошло ничего нового. Автомобили можно смело ставить на конвеер и выпускать на заводе. Что Генри Форд, собственно, и сделал.

В автомобилях принципиально не изменились только основное устройство ДВС, трансмиссии и подвески, но управление всем этим радикально изменилось где-то в районе 70-80-х, с переходом на электронный впрыск. Если до тех пор приходилось шаманить с запуском холодного двигателя, регулярно чистить и подстраивать карбюратор, чистить/менять свечи и т.п., то после этого ситуация "двигатель не запускается" или "двигатель заглох" перестала означать "автомобиль капризничает" или "в автомобиле что-то слегка не в порядке", и стала означать "автомобиль категорически неисправен".

Pzz>А с програмизьмом поторопились.

В программизме фактически то же самое: принципы работы и архитектура железа принципиально не изменились, но многие способы управления им поменялись радикально. Но, если продолжать аналогию с автомобилями, то после внедрения электронного впрыска, АКПП, ABS/ESP, ремней безопасности, круиз-контроля, парковочных радаров и прочего, вплотную стали заниматься только формой/раскраской кузова, отделкой салона, мультимедийной системой и подобным.

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

Pzz>C++ пытается превратить смысловую сложность в синтаксическую сложность

Так это не "C++" пытается, а как раз те люди, которые изо всех сил (и непонятно зачем) стремятся сохранить в языке минимальный набор ключевых слов и синтаксических элементов, навешивая на символы и их комбинации все новые и новые смыслы.

В то время, когда я впервые увидел программу на C где-то в середине 80-х, из ЯВУ я использовал только Pascal, а большей частью писал на ассемблерах. И в паскале меня, как и многих, очень раздражала многословность в виде BEGIN/END, хотя по факту на любом ассемблере получается куда бОльшая многословность. Все эти фигурные скобочки и инкременты/декремент в C тогда буквально очаровали. Но "синтаксическая плотность", которой уже лет тридцать стараются придерживаться в C++, давно не лезет ни в какие ворота.

Pzz>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.

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

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

Синтаксическая сложность, наоборот, усложняет понимание. Это как в математике: можно описывать задачу в понятиях "рассмотрим функцию со следующими свойствами...", а можно — "рассмотрим f (x, y, p, t) такую, что <трехэтажный интеграл>". Иной раз компактная формула с достаточно типичными и очевидными элементами выглядит проще, чем словесное описание, но понять какую-нибудь двух-трехуровневую шаблонную конструкцию навскидку можно, лишь годами оперируя такими конструкциями почти непрерывно. Это похоже на известную проблему разворачивания определения указателя на функцию, возвращающую указатель на массив и т.п., но для них есть хотя бы typedef/using, а для шаблонов ничего подобного нет.

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

Q>если бы ядро Linuxа было сделано на C++ то возможно в его разработке могли бы принимать активное участие не обязательно суперпрограммисты типа самого его и красноглазиков а обычные люди.

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

Q>считается что ОС должна быть написана кровью на С или ассемблере потому что типа надо очень быстро а C++ это очень медленно. Это в общем случае заблуждение

О том и речь. Но большинство таки понимает это заблуждение, как "на C++ то же самое будет лишь немногим объемнее/медленнее", хотя, при должной внимательности, эквивалентные по смыслу конструкции C++ дают тот же самый код, что и в C. Но, если нужно удерживать объем/скорость кода в достаточно жестких рамках, в C++ нужна гораздо большая внимательность, поскольку возможностей неочевидного увеличения объема или снижения скорости гораздо больше.

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

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

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

C>С++ стал заложником корпораций с их неуёмных желанием объять и уничтожить

Ну вот тот же MS добавил в свой VC++ расширения в виде некоторого количества предикатов (__has_assign, __is_class, __is_convertible_to и т.п.), квалификатор __interface для определения интерфейсного (чисто абстрактного) класса, __if_exists/__if_not_exists для условной компиляции по наличию/отсутствию определения, __forceinline для принудительной вставки функции, и так далее. Ничего из этого в стандартный язык не пошло. Свойства типов — по-прежнему только магия, интерфейсный класс извольте описывать ручками с "= 0" при каждой функции, для принудительного inline каждый копилятор тащит свои атрибуты, нормальной условной компиляции так и нет — выкручивайтесь магией.

C>Я могу почти весь дом построить с помощью одного молотка

Вы хотели сказать "барак"?

C>Я люблю и могу смешивать в проектах разные языки и программы. Мне нравится кодо-генерация, мне нравится интероперабельность.

Я тоже могу, но не люблю. Особенно когда библиотека на C++, бОльшая часть которой собирается как под прикладной пользовательский уровень, так и под ядро. При желании ее можно чуть переделать, и собирать под МК.

C>Ни для одной другой задачи я не буду использовать Ruby, потому что как язык сам по себе — так себе, но Rails закрывает 99.9% того, что мне может понадобиться в типичном CRUD. А если мне нужно простенькое приложения с парой контроллеров, я возьму Flax, потому что я не хочу держать весь путь, который проходит запрос от браузера до контроллера, со всеми рельсовыми middleware. Я пишу на Си, если мне нужно дёрнуть пару системных библиотек, но если нужно работать со строками или массивами, я пишу на С++, потому что безопасность важнее. Если я обрабатываю данные, то, конечно же, я смотрю в сторону R или Python.

А после всего этого Вы пишете в системных требованиях что-нибудь вроде "необходима Windows 10 версии XXX или старше с .NET YYY или старше". Или дистрибутив Вашего проекта в процессе установки сообщает "требуется JRE версии XXX", скачать-установить? Юзер соглашается, и тут, внезапно, или у установщика нет прав доступа к сети, или возбуждается антивирус, или еще что. А после установки десятка таких проектов пользовательская система оказывается набита гигабайтами не пойми чего, оно завязано друг на друга, и аккуратно/чисто удалить отдельные части оказывается проблематично, если вообще возможно.

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

Шекспир нервно переворачивается в гробу.

C>Если со стандартом самого языка всё выглядит более-менее, то попытка добавить в стандарт работу с ФС или графикой ничего кроме смеха не вызывает.

И не надо. А если уж это делать, то непременно в виде "сопутствующей библиотеки", которая может быть реализована, а может и нет. Любая работа с ФС или графикой всегда будет написана на самом языке, поэтому любой желающий может написать ее сам. А вот сделать то, что сам язык не позволяет, или невозможно, или очень геморройно. Поэтому прежде всего нужно развивать возможности самого языка, а удобные дополнения/надстройки всегда можно разрабатывать в виде библиотек.

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

__>Можно мне, например, рефлексию типов данных здесь и сейчас, без "добрых дядей"?

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

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

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

Евгений, вам пора патентовать слоган "C++, который мы потеряли".

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

ЕМ>Никто в здравом уме и не ожидает, что на МК с памятью в десяток килобайт будут многопоточность и файловая система. Но вот исключения в C++ действительно могли бы реализовать гораздо разумнее, хотя передавать параметром исключения не весь произвольный объект, а только указатель на него.

Про исключения теоретически согласен, но опять же, на подобных MK реально исключительная ситуация должна приводить к перезагрузке или failsafe. Короче, невелика потеря.

L>>На тех же атмегах шаблонную магию вообще можно использовать без проблем.

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

Так средство, которое позволяет условную компиляцию с нулевым оверхедом в рантайме или все же извращение?

L>>Некоторое подможество STL — тоже.
ЕМ>Что там есть реально удобного, не завязанного на исключения?

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

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

L>Про исключения теоретически согласен, но опять же, на подобных MK реально исключительная ситуация должна приводить к перезагрузке или failsafe.

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

L>Так средство, которое позволяет условную компиляцию с нулевым оверхедом в рантайме или все же извращение?

С помощью магии — извращение. Особенно когда встроенные средства условной компиляции достаточно просты в реализации.

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

ЕМ>Ну вот тот же MS добавил в свой VC++ расширения в виде некоторого количества предикатов (__has_assign, __is_class, __is_convertible_to и т.п.), квалификатор __interface для определения интерфейсного (чисто абстрактного) класса, __if_exists/__if_not_exists для условной компиляции по наличию/отсутствию определения, __forceinline для принудительной вставки функции, и так далее. Ничего из этого в стандартный язык не пошло. Свойства типов — по-прежнему только магия, интерфейсный класс извольте описывать ручками с "= 0" при каждой функции, для принудительного inline каждый копилятор тащит свои атрибуты, нормальной условной компиляции так и нет — выкручивайтесь магией.

А #pragma once стала стандартом де-факто. Я не об этом говорил, а о том, что комитет это не сообщество идейных людей, а представители FAANG и компаний поменьше. В фаанге бардак в кодовой базе, вот и стандарт превращается в бардак. Что-то похожее происходит с линуксом, но там сообщество пока ещё слишком разношёрстное.

ЕМ>Вы хотели сказать "барак"?

Да почему, обычный дом. Просто это будет сложно и дорого. И кран будет переодически подтекать, а полки — падать. Если вы поняли, о чём я

ЕМ>Я тоже могу, но не люблю. Особенно когда библиотека на C++, бОльшая часть которой собирается как под прикладной пользовательский уровень, так и под ядро. При желании ее можно чуть переделать, и собирать под МК.

Это миф. Или программа на МК будет неоптимальной, или программировать для сервера будет сложно и неприятно.

ЕМ>А после всего этого Вы пишете в системных требованиях что-нибудь вроде "необходима Windows 10 версии XXX или старше с .NET YYY или старше". Или дистрибутив Вашего проекта в процессе установки сообщает "требуется JRE версии XXX", скачать-установить? Юзер соглашается, и тут, внезапно, или у установщика нет прав доступа к сети, или возбуждается антивирус, или еще что. А после установки десятка таких проектов пользовательская система оказывается набита гигабайтами не пойми чего, оно завязано друг на друга, и аккуратно/чисто удалить отдельные части оказывается проблематично, если вообще возможно.

Каюсь, для винды не писал лет 20 уже. На серверах есть пакетные менеджеры, контейнеры. Вероятно, на винде я бы выбрал .NET для фронта и C++ для ядра. Или Java + C++.

ЕМ>Шекспир нервно переворачивается в гробу.

Современный английский и Шекспира объединяет только слово "английский", всё остальное у них разное.

ЕМ>И не надо. А если уж это делать, то непременно в виде "сопутствующей библиотеки", которая может быть реализована, а может и нет. Любая работа с ФС или графикой всегда будет написана на самом языке, поэтому любой желающий может написать ее сам. А вот сделать то, что сам язык не позволяет, или невозможно, или очень геморройно. Поэтому прежде всего нужно развивать возможности самого языка, а удобные дополнения/надстройки всегда можно разрабатывать в виде библиотек.

Так и я о том же. Я хотел подчеркнуть, что разработка текущих страндартов это специальная олимпиада, где участники уже сами забыли, в чём состоит суть мероприятия. Не 100%, но 80% точно. Вот std::span мне понравился, я даже когда-то начал писать хобби-проект на базе LLVM, где такая штука была бы встроенной в язык. Вместе с операторами, которые позволяют использовать идиому head/tail, как в функциональщине. И ещё RAII там, но простой, без всяких нелепостей, которые мешают писать программу. Время тогда не хватило закончить.

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

Евгений, мне удалось сформулировать несколько причин, из-за которых невозможно удержаться и не постебать ваши сентенции по поводу "С++, который мы потеряли" (точнее, потеряли то вы, Евгений). Итак:

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

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

Хотя с этим-то как раз понятно. Чтобы приводить такие примеры нужно быть хотя бы Шоном Бакстером, который в одиночку запилил Circle и наглядно демонстрирует как те же самые проблемы можно решать более простым и понятным способом.

В-третьих, самое главное: ну хорошо, допустим, вы правы, C++ пошел не туда, используется не так, адепты Александреску извратили первозданную чистоту и красоту того самого праведного С++ и все такое. Допустим. Дальше-то что?

Что вы предлагаете?

Из ваших сентенций не понятно что должны делать современные C++ программисты.

Грубо говоря вот у нас есть существующий инструмент. Кого он не устраивает имеет возможность уйти на любой другой язык (хоть на Python, хоть на Java или C#, хоть на Rust или Ada). Что, как я понимаю, большинство недовольных уже давным-давно и сделали. Остались те, кому C++ нужен. И у кого есть именно тот C++, который есть здесь и сейчас, а не какой-то мифический "праведный C++" из вашей головы.

Вот нам-то, кто живет с современным C++, что делать?

Рыдать вместе с вами о том, что магистраль развития C++ 30 лет назад свернула не туда?
Отказываться от части возможностей C++ (каких?) и писать только на подмножестве C++ (каком?)?
Писать пропозалы по изменению языка в какую-то другую сторону?

-----

Короче, вы беретесь проповедовать, но не отвечаете на два главных вопроса русской интеллигенции: "Кто виноват?" и "Что делать?"
И если ответ на первый вопрос лично мне не интересен, то вот отсутствие ответа на второй вопрос и ведет к тому, чтобы в очередной раз спросить у вас: "А зачем вы лужи газифицируете?"

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

S>* в C нет жесткого контроля за преобразованиями типов;
S>* в C нет встроенных средств поддержки динамического полиморфизма;
In pointer to void we trust!

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

ЕМ>преподаватель
ЕМ>дядька понимает суть программирования, как профессии
Взаимоисключающие понятия и это нормально.

По сути поста: кажется, что вам не нравится, что ваша ниша и ваш способ использовать С++ не самый востребованный на рынке. Но это нормально.

Я вот пишу на С++, и ежедневные проблемы, которые мне приходиться решать, с вашими не пересекаются вообще никак. (И программа занимает 100 Мб после установки!

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

S>>* в C нет жесткого контроля за преобразованиями типов;
S>>* в C нет встроенных средств поддержки динамического полиморфизма;
S>In pointer to void we trust!

It's robust, reliable, understandable, and maintainable, just trust me.

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

S>Что вы предлагаете?
Я не знаю, что предложит Евгений Музыченко, но многими востребовано, чтобы, например, решения подобные этому

Автор: _agg
Дата: 15.07 12:37

не содержали UB.

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

S>>Что вы предлагаете?
BFE>Я не знаю, что предложит Евгений Музыченко, но многими востребовано, чтобы, например, решения подобные этому

Автор: _agg
Дата: 15.07 12:37

не содержали UB.

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

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

ЕМ>Здравствуйте, landerhigh, Вы писали:

L>>Про исключения теоретически согласен, но опять же, на подобных MK реально исключительная ситуация должна приводить к перезагрузке или failsafe.

ЕМ>Исключения, в силу своей чрезмерно абстрактной/универсальной реализации, на любой платформе создают изрядную избыточность, и по объему, и по выполнению. Из-за этого их чревато применять там, где исключение может возникать достаточно часто (чаще где-то десятков раз в секунду). В результате на одних исключениях всей обработки ошибок не построишь — нужно сочетать обычный возврат ошибок для более-менее регулярных ситуаций с исключениями для серьезных и относительно редких. В итоге проблема толком не решается, но избыточность присутствует, плюс сложности с объединением модулей, использующих и не использующих исключения. Палка о двух концах.

Это уже все было перетерто миллионы раз.
Применительно задачам, которые решаются "классическими МК" (а не замаскированными под них гигагерцовыми процессорами с гигабайтом оперативки), исключение — это что-то из ряда вон выходящее вроде "Device is on fire". Это же по сути КА, и должен реализовываться как КА.

L>>Так средство, которое позволяет условную компиляцию с нулевым оверхедом в рантайме или все же извращение?
ЕМ>С помощью магии — извращение. Особенно когда встроенные средства условной компиляции достаточно просты в реализации.

	Скрытый текст
	Картинку нашел, убрал м*т с нее.

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

BFE>>Я не знаю, что предложит Евгений Музыченко, но многими востребовано, чтобы, например, решения подобные этому

Автор: _agg
Дата: 15.07 12:37

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

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

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

BFE>>>Я не знаю, что предложит Евгений Музыченко, но многими востребовано, чтобы, например, решения подобные этому

Автор: _agg
Дата: 15.07 12:37

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

BFE>Зато намерения автора прозрачны: иметь прямой и простой доступ к байтовому представлению базовых типов в памяти.

Простите, но не в изначальной формулировке:

к примеру:

auto val = GetValue(value);

и соответственно если value.type = Type::int_ val будет типа int и тд. ?

В C++ тип val должен быть определен в compile-time, даже если он помечен в коде как auto. Т.е. если в value лежит int, то и val должен быть int, но в compile-time мы этого не знаем.

Какие-то подозрения могли бы быть, если бы код в примере выглядел как-то так:

auto val = GetValue<int>(value);

Но таких намеков нет.

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

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

А где самый напрашивающийся вариант через std::copy_if?

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

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

П>А где самый напрашивающийся вариант через std::copy_if?

Наверное там же, где и ваша внимательность, но это не точно.

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


ЕМ>Ну вот тот же MS добавил в свой VC++ расширения в виде некоторого количества предикатов (__has_assign, __is_class, __is_convertible_to и т.п.), квалификатор __interface для определения интерфейсного (чисто абстрактного) класса, __if_exists/__if_not_exists для условной компиляции по наличию/отсутствию определения, __forceinline для принудительной вставки функции, и так далее. Ничего из этого в стандартный язык не пошло. Свойства типов — по-прежнему только магия, интерфейсный класс извольте описывать ручками с "= 0" при каждой функции, для принудительного inline каждый копилятор тащит свои атрибуты, нормальной условной компиляции так и нет — выкручивайтесь магией.

__has_include

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

BFE>>>>Я не знаю, что предложит Евгений Музыченко, но многими востребовано, чтобы, например, решения подобные этому

Автор: _agg
Дата: 15.07 12:37

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

S>

S>к примеру:
S>

S>auto val = GetValue(value);
S>

S>и соответственно если value.type = Type::int_ val будет типа int и тд. ?

S>В C++ тип val должен быть определен в compile-time, даже если он помечен в коде как auto. Т.е. если в value лежит int, то и val должен быть int, но в compile-time мы этого не знаем.
Да, но есть обходные пути: val может быть промежуточного типа с операторами преобразования типа в тип цели...
Но я вообще не об этом, а о доступе к данным одного типа, как к данным другого типа. По стандарту это настолько мутная история, что я так и не понял, когда и что во что можно преобразовывать, а что нельзя.

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

S>>Простите, но не в изначальной формулировке:
BFE>Я, таки, разделяю вопрос автора и его намерения. А намеревается он именно, что сериализовать бинарные данные...

Скорее уж десериализовать.

Но тут все точно как в жизненной мудрости, "без ТЗ и результат ХЗ". Форумчане не должны угадывать желания автора вопроса, о чем спросил, на то и ответили.

BFE>Да,

Ну вот вопрос и закрыт.

BFE>но есть обходные пути: val может быть промежуточного типа с операторами преобразования типа в тип цели...

Это не обходные пути, это решение другой задачи, а именно: как сделать тип, который может внутри себя держать значения нескольких других типов (т.е. очередная итерация вокруг union/variant). Но задача принципиально другая, т.к. в ран-тайме у вас все равно val будет не int, не double, а что-то, что может их внутри себя инкапсулировать и как-то давать доступ.

BFE>Но я вообще не об этом, а о доступе к данным одного типа, как к данным другого типа. По стандарту это настолько мутная история, что я так и не понял, когда и что во что можно преобразовывать, а что нельзя.

Так ведь с каждым стандартом с этим все проще и проще становится.
Сперва добавили alignas и alignof. Так что можно делать массивы для хранения байтовых представлений с правильным выравниванием.
Теперь вот добрались до std::start_lifetime_as, что как раз таки избавляет от UB связанного с тем, что компилятор ни сном ни духом про начало жизни объекта некоторого типа T внутри произвольного байтового буфера.

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

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

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

Есть известный пример как знание организации кода "на железе" привело к пессимизации выполнения программ на С++. А именно история стандартизации std::vector, которая привела к замедлению работы с этим контейнером. Изначально в стандарте не было требования о том, что данные вектора должны лежать непрерывным куском в памяти. Теоретически это существенно повышает скорость работы, так как добавление новых элементов не требует копирования/переноса всех элементов массива. Однако именно понимание "кухни" вычислительной системы и того, как в итоге будет организовано "на железе" выполнение программы, привело к стандартизации vector'а как непрерывного куска в памяти, а быструю реализацию вектора составленного из других векторов, так никто и не имплементировал, насколько я знаю. Теоретически мы могли бы иметь std::vector обгоняющий std::deque на всех операциях, но — нет.

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

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

BFE>Есть известный пример как знание организации кода "на железе" привело к пессимизации выполнения программ на С++. А именно история стандартизации std::vector, которая привела к замедлению работы с этим контейнером. Изначально в стандарте не было требования о том, что данные вектора должны лежать непрерывным куском в памяти. Теоретически это существенно повышает скорость работы, так как добавление новых элементов не требует копирования/переноса всех элементов массива. Однако именно понимание "кухни" вычислительной системы и того, как в итоге будет организовано "на железе" выполнение программы, привело к стандартизации vector'а как непрерывного куска в памяти, а быструю реализацию вектора составленного из других векторов, так никто и не имплементировал, насколько я знаю. Теоретически мы могли бы иметь std::vector обгоняющий std::deque на всех операциях, но — нет.

А можно ссылочку на первоисточник? Звучит уж как-то невероятно.

ЕМНИП, это касательно std::string C++98 допускал трактовки, позволяющие и COW-реализации, и реализации на базе ROPE.
И только в C++11 стандарт был переформулирован так, чтобы std::string::data возвращал указатель на непрерывный блок памяти.

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

ЕМ>Получилось сумбурно. По-хорошему, такие вопросы надо рассматривать, как минимум, в большой статье, но нет ни времени, ни желания ее сочинять — все равно мало кто поймет.

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

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

Другого выхода как идти в сторону "кубиков" и "кирпичиков" я просто не вижу, объем слишком велик для понимания, и он растет
Для C++ просто не видно другого выхода, кроме как плыть в этом потоке.

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

S>А можно ссылочку на первоисточник? Звучит уж как-то невероятно.
На первоисточник чего? На стандарт C++98?
Ну откройте, посмотрите. Там даже std::vector::data() отсутствует.

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

S>>А можно ссылочку на первоисточник? Звучит уж как-то невероятно.
BFE>На первоисточник чего?

Обсуждений по ужесточению требований к std::vector.

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

S>>>А можно ссылочку на первоисточник? Звучит уж как-то невероятно.
BFE>>На первоисточник чего?
S>Обсуждений по ужесточению требований к std::vector.

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

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

Автор: maks1180
Дата: 29.05 22:23

.

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

S>>>>А можно ссылочку на первоисточник? Звучит уж как-то невероятно.
BFE>>>На первоисточник чего?
S>>Обсуждений по ужесточению требований к std::vector.

BFE>Да я не знаю, где взять такой источник.

Жаль.

BFE>Да и зачем он вам?

Да просто интересно. Насколько я помню, сам Страуструп после появления std::vector говорил, что если вам нужен динамический массив, то вместо `malloc` и `new[]` следует использовать именно std::vector, мол получаете тот же самый непрерывный массив значений, а накладных расходов всего-то плюс два std::size_t.

BFE>Аргументация того, что я читал, если мне не изменяет память, сводилась к тому, что часто данные из вектора в уже написанных программах передаются в функции C и чтобы не ломать уже существующий код, просто зафиксировали в стандарте существующую практику. Ну, а что было делать? На введённое требование, кстати, никто не жаловался, ну или мне такие жалобы не встречались.

А вот я такого по отношению к std::vector не помню.

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


ЕМ>[q]Автору этих строк представляется очевидным, что язык Си (чистый Си) смог стать тем, чем он стал, и занять его нынешнюю нишу благодаря двум своим очевидным свойствам: во-первых, жесткой и очевидной границе между самим языком и его библиотекой, сколь бы "стандартной" она ни была, и, во-вторых, достижимости "zero runtime", т.е. возможности использования созданных компилятором объектных модулей без поддержки со стороны поставляемых с компилятором библиотек. В отсутствие любого из этих свойств язык программирования оказывается неприменим для программирования на "голом железе" (т.е. для ядер операционных систем и для прошивок микроконтроллеров) и, как следствие, не может претендовать на универсальность. Тем удивительнее, сколь упорно создатели "стандартов" пытаются изничтожить оба этих свойства, причем как в Си++, так и в чистом Си".

А как же libc? Или эту библиотеку можно сделать опциональной?

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

S>А как же libc? Или эту библиотеку можно сделать опциональной?

Конечно. Любой адекватный компилятор создает ссылки к libc только при реальной необходимости.

Например, по умолчанию точка входа в исполняемый модуль берется из libc, и создает стандартную среду для main (разбирает параметры командной строки, добывает набор переменных среды, инициализирует CRT, вызывает конструкторы статических объектов и т.п.). Если скомпилировать произвольную функцию без этих зависимостей и указать ее линкеру в качестве точки входа, из libc не добавляется ничего, и получается минимально возможный исполняемый модуль.

Для каких-то функций libc/CRT можно создать свои "пустышки". Например, в некоторых реализациях, особенно в отладочных сборках, многие функции libc, обнаружив недопустимые параметры на входе, вызывают диагностические средства из той же libc. Выяснив, что именно вызывается, можно вместо этих диагностических функций определить свои, "экранируя" стандартные.