Здравствуйте, avovana, Вы писали:
A>Подскажите, пожалуйста: A>1) В какой доменной области работаете Вы с С++? Почему он там применяется? Какие задачи решаете? A>2) Будет ли далее там использоваться С++?
Никуда не денется. Серьёзная угроза C++ есть только со стороны Java/C# и т.п. языков, но там свои проблемы.
А ещё Nemerle, как же можно без упоминания Nemerle на КЫВТ. Будущее за Nemerle, очевидно.
Rust и рядом не лежал по многим пунктам.
A>3) Какое будушее у языка Вы видите, в целом?
Полностью провалится в метапространство через дыру в абстракциях.
A>4) Захватит ли всё rust?
Rust -- это C на стероидах. Там нет и малой части того, что есть в C++.
Сравнивать даже глупо. И уж с декларативными языками, со скриптовыми, с
языками с динамической типизацией и сборщиком мусора -- ни с чем Rust
конкурировать не сможет. Единственная характеристика Rust -- "токсичное сообщество"
фанатиков. У них была одна стоящая идея borrow checker'а, но это не краеугольный
камень и оно даже в D-lang с тех пор появилось.
A>5) Какие фишки обеспечивают С++ конкурентоспособность сейчас в вашем домене и будут обеспечивать в будущем?
Бесполезно сравнивать пряники и сапоги.
A>6) Насколько в реальности сложен С++
Настолько, что в пункте 3 полная неопределённость. Очевидно, что давно пора выкрасить и выбросить,
но legacy не даёт. Нужен совершенно другой язык, изначально спроектированный с учётом возможности
всех "неожиданно обнаруженных" свойств C++ (который почти полностью состоит из таковых...)
Здравствуйте, avovana, Вы писали:
A>Подскажите, пожалуйста: A>1) В какой доменной области работаете Вы с С++?
Сразу дисклаймер: не специалист в этих областях, просто участвовал как человек, которые пишет более-менее понятный и как-то работающий код, а если нужно, то может и привести в норму откровенный говнокод.
Из последнего:
* нагруженный HTTP-прокси (сервер, только Linux);
* видеонаблюдение -- сбор, анализ и сохранение видеопотоков (десктоп, кросс-платформа -- изначально Windows/Linux, в перспективе были macOS/iOS/Android, но уже не в проекте, так что не знаю дошли руки или нет);
* многомерные аналитические кубы (сервер, основная платформа Windows, но с перспективой поддержать и Linux).
A>Почему он там применяется?
Скорость, ресурсоемкость. Возможность работать и на высоком уровне абстракции, и опускаться вниз до уровня взаимодействия с ОС.
Простота интреграции с системой.
Простота интеграции с уже существующими библиотеками на Си и C++. Большое количество этих самых библиотек.
Кстати, в двух последних проектах использовался vcpkg для управления зависимости, так что боли от управления зависимостями не было.
A>Какие задачи решаете?
Лично я самые тривиальные: сделать чтобы работало. И чтобы было достаточно задокументировано, чтобы это могли поддерживать в последствии.
A>2) Будет ли далее там использоваться С++?
Зависит от коммерческого успеха этих проектов. Если будут приносить прибыль, то да.
A>3) Какое будушее у языка Вы видите, в целом?
Ниша применения будет в процентном отношении снижаться. Но, за счет того, что софта становится все больше и больше, то в абсолютных числах объем кода на C++ может расти и дальше.
Теснить C++ продолжат и безопасные языки с GC с одной стороны, и Rust (и другие потенциальные конкуренты, которые нативные и без GC) с другой.
A>4) Захватит ли всё rust?
Всё -- нет. Опыт показывает, что не случается какого-то одного языка, который вытеснит все остальные.
Но заставит C++ подвинутся еще больше. Хотя, имхо, Rust не будет тем языком, который сможет вытеснить C++ полностью.
A>5) Какие фишки обеспечивают С++ конкурентоспособность сейчас в вашем домене и будут обеспечивать в будущем?
Огромное наследие, с которым C++ без проблем интегрируется.
Более-менее нормальный ООП (для языка со статической типизацией). Да, я в курсе, что сейчас не модно и не молодежно хвалить ООП, но вас же интересует субъективное мнение
Шаблоны. Шаблоны. И еще раз шаблоны.
A>6) Насколько в реальности сложен С++
Попробуйте подготовить серию лекций по C++, прочувстуете сами.
Попробуйте написать код без UB, для закрепления ощущения
Кроме сложности самого языка есть еще и сложность его применения. Одни и те же вещи можно делать сильно по разному, нужно делать выбор между разными способами, делать выбор сложно
Уровень подготовки C++ников очень разный. Кому-то исходники Boost.Hana -- это открытая книга. Для кого-то даже реализация шаблонного std::min уже слишкамсложна (с).
Плюс полярность мнений: каждый же лучше знает, как оно должно быть правильно (это справедливо для всех ЯП, но в C++ как-то слишком уж гипертрофированно).
Стандарты, которые сейчас стали клепать раз в три года ничуть не парясь о том, когда же эти стандарты будут более-менее нормально поддержаны хотя бы "большой тройкой" компиляторов.
В общем, в реальности C++ сложен. Если есть возможность C++ не использовать, то лучше таки не использовать.
Здравствуйте, avovana, Вы писали:
A>4) Захватит ли всё rust?
Все хоть сколько-то популярные операционки написаны на Си. Не важно Windows, Linix, BSD и так далее. И все крупные компании используют их модификации.
Если кто-то скажет захватит ли Rust или другой язык нишу операционок, то я скажу, что этот человек новичок и не понимает как всё устроено.
На Си так же пишут драйвера, веб-сервера, базы данных и многое другое. И заметь это не какой-то мусор, а самые топовые проекты, которые у всех на слуху.
Так вот Си и C++ это не одно и тоже. И программисты часто специализируются или на одном или на другом. Только это не мешает создавать совместимость с точки зрения компиляции.
Да, совместимость не полная, но мигрировать программу от Си к С++ гораздо проще, чем в обратную сторону. Тогда как миграция умений программиста проще пройдёт от C++ к Си.
И в принципе есть хорошая совместимость использования Си из C++. А вот для других языков нужны обёртки.
Никто ведь не возражает, пиши на чём хочешь. Просто однажды настанет понимание, что Си и C++ попросту нет вменяемых альтернатив, если конечно не собрался писать всё с нуля.
Есть ещё принцип достаточности, когда достаточно чего-то другого. Возможно менее производительного, более затратного по памяти, не кроссплатформенного и так далее. Но людям этого достаточно.
И более того люди пишушие на Си или C++ никуда не денутся. Их будет даже больше, чем пользователей экзотики. А чем их больше, тем проще их находить и нанимать, а следовательно поддерживать проект.
Я бы вообще сказал, что у других языков нет будущего. Через сколько-то лет сменится сто пятьсотый фреймворк и попробуй потом найди специалиста на этом языке. А старый специалист уже своё отработал.
Как интернет у людей появился всё и срутся на эту тему. Раньше только Си и C++ убивали другие языки и платформы. Сколько десятилетий уже убивают убить не могут.
Просто голову надо немного включить. Предоположим есть захватчики пишушие на Rust или ещё чём-то. Так захватывайте вот прямо всё, кто мешает.
Вперёд и с песней переписывать миллиарды строчек кода, а потом пытаться пропихнуть своё поделие в мир.
А ещё другие языки любят рекламировать, что они якобы созданы для дебилов. Обезьяна на них садится и сразу получает работающую программу.
На деле же получается всратое поделие, глючное и тормознутое. И что хуже всего часто оно таким становится по мере накопления данных.
Потому что видимо никто программу не тестировал или просто забили на плохие результаты тестов. И пользователи слишком поздно осознают, когда часть данных уже набрана.
В общем господа убиваки и дамы убивашки, пишите на Rust, Go, Python, C# и прочих убийцах. Очевидно же, что если лично вы это сделаете, то Си и C++ сразу убьются.
Люди же посмотрев на вашу поделку сразу бросят свои топовые проекты. Скажут как же так, нас обманули. Смотри какую клёвую свистоперделку сделал Вася Пупкин на Rust.
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>Если сишник неспособен при нужде написать программу в ООП-стиле, а плюсовик даже hello world пишет через hw.run (), это уже клиника.
Изобретатель Си++ Страуструп никогда не работал в промышленности, а сидел в комнате за своим столом и общался лишь с другими преподавателями да бухгалтерами университета, куда он смог пристроиться на работу. Счетоводы объяснили Страуструпу, что если в платёжном поручении какие-то данные не соответствуют образцу, то денежный перевод необходимо сразу отклонять, а не пытаться исполнять с неправильными данными. Задачи, когда необходимо выполнить задачу любой ценой, вождю Си++ были неведомы.
А теперь представим, что поехал ты на своём автомобиле размяться в спортзал. Завёлся, тронулся и едешь потихонечку по дороге. И вдруг на перекрёстке ни с того, ни с сего отказывает датчик кислорода в твоём автомобиле, а следом за ним датчики давления в шинах и датчик коленчатого вала. Что ты предпочтёшь получить: надпись на панели приборов об отказавших датчиках и заглохший двигатель или отключившуюся панель приборов, но движущийся автомобиль, на котором ты сможешь выехать с перекрёстка?
Здравствуйте, avovana, Вы писали:
A>Добрый день, уважаемый форумчане!
A>Меня пригласил на подкаст мой товарищ поговорить про С++. Сам он когда-то разрабатывал на rust) A>Хочу приобрести больше контекста по применимости С++ сегодня.
На подкаст как эксперта позвали тебя, а отвечать за тебя должны мы. Что-то ты, мягко говоря, не прав, мне кажется .
Здравствуйте, Pitirimov, Вы писали:
P>программисты на Си пишут всё сами, а "плюсисты" изначально настроены на переиспользование кода, уже написанного другими людьми.
Если они *никсоиды, то у них, наоборот, очень развита практика использования готовых средств. Опять же, многие "плюсисты" предпочитают делать все сами (я в том числе), поскольку прикручивание и сопровождение стороннего кода часто больше мешает, чем помогает.
P>Процедурное мышление против ООП-мышления.
Если сишник неспособен при нужде написать программу в ООП-стиле, а плюсовик даже hello world пишет через hw.run (), это уже клиника.
Опять же, оконная подсистема в винде — явное ООП, а написана (по крайней мере, была) целиком на C, и долгое время использовалась из него же.
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>Я бы предпочел получить более конкретное объяснение связи вышеописанного с обсуждаемой тематикой. Пока не вижу ни малейшей связи — чистое фантазирование.
Я сравнил использование кодов возврата из функций чистого Си в сравнении с исключениями Си++. Ты же сам написал что именно программистов на Си не устраивает в Си++, я тебе и разъяснил почему люди так считают.
Тут "плюсисты" обычно высказываются о том, что никто не заставляет использовать исключения, где они не нужны. Это похоже на то, что выдать рабочим по тарелке супа за обедом, поставить тарелку винограда на стол и наказать, чтобы никто не ел виноград. Наверное, это удовольствие бить по рукам людей, тянущихся за виноградом, следя за ними из-за занавески? Природу животного мира в людях никто пока что никто не смог искоренить и красть еду исподтишка — всего лишь один из способов выживания особи в дикой природе. Отец Сергий отрезал себе палец, когда к нему в землянку зашла женщина среди ночи и метели. А теперь представь, что эта же самая женщина зашла бы к пьяным рабочим-вахтовикам в их вагончик — бабу не просто грубо облапали бы, а чего и похуже бы сделали с вероятностью 99 процентов.
Единственный выход — ограничить внесение лажи в проект через написание ПО на чистом Си вместо Си++, чтобы с плёткой не стоять у людей над душой.
Здравствуйте, cppguard, Вы писали:
C>Абсолютно все правила С++ возможно запомнить, если человек работает исключительно над С++.
Не только работает, но и регулярно пользуется всем набором правил и возможностей, а это уже маловероятно. На мой взгляд, достаточно полно знают положения стандарта или фанаты, которым в кайф использовать любые возможности лишь потому, что они есть (не фича для задачи, а задача для фичи), или преподаватели, или те, кто регулярно проводит собеседования с кандидатами на работу.
У тех, кто "просто работает", обычно получается, как в известном анекдоте про Эйнштейна и Эдисона.
C>Держать в голове какую-то предметную область вроде робототехники, ИИ, встраиваемых систем и при этом помнить, когда там что куда приводится и когда инвалидируется, где UB, а где не UB — нереально. Даже если запомнить это всё для языка, то памяти на стандартную библиотеку точно не хватит. Я уже молчу, что где-то используют С++14, а где-то С++23.
В этом могли бы очень сильно помочь предупреждения компилятора, но такое впечатление, будто каждое новое предупреждение обходится создателям компилятора очень дорого, отчего они обычно появляются через много лет после того, как впервые стало понятно, что конструкция потенциально опасна.
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>За это время не встретил ни одного сишного программиста, чья приверженность C определялась бы чисто техническими условиями, и ничем иным. Все они без исключения либо уверены, будто на чистом C якобы "компактнее", "эффективнее", "надежнее", "предсказуемее", "управляемее" и т.п., либо они тупо ненавидят C++ за исключения, шаблонную магию, STL и прочее, даже не подозревая, что всё это не является обязательным.
Дело же не в языках, а в разнице мышления: программисты на Си пишут всё сами, а "плюсисты" изначально настроены на переиспользование кода, уже написанного другими людьми. Процедурное мышление против ООП-мышления. Объяснять и доказывать друг другу что-либо тут бесполезно, как англичанин никогда не поймёт мышления русича и наоборот ибо оба воспитаны по-разному.
Меня пригласил на подкаст мой товарищ поговорить про С++. Сам он когда-то разрабатывал на rust)
Хочу приобрести больше контекста по применимости С++ сегодня.
Подскажите, пожалуйста:
1) В какой доменной области работаете Вы с С++? Почему он там применяется? Какие задачи решаете?
2) Будет ли далее там использоваться С++?
3) Какое будушее у языка Вы видите, в целом?
4) Захватит ли всё rust?
5) Какие фишки обеспечивают С++ конкурентоспособность сейчас в вашем домене и будут обеспечивать в будущем?
6) Насколько в реальности сложен С++
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, avovana, Вы писали:
A>>Добрый день, уважаемый форумчане!
A>>Меня пригласил на подкаст мой товарищ поговорить про С++. Сам он когда-то разрабатывал на rust) A>>Хочу приобрести больше контекста по применимости С++ сегодня. K>На подкаст как эксперта позвали тебя, а отвечать за тебя должны мы. Что-то ты, мягко говоря, не прав, мне кажется .
Своим мнением могу поделиться хоть сейчас )) Обогатиться мнениями членов сообщества — для меня ценно)
Если бы ты увидел текущие диаметрально противоположные ответы в гугл форме, лучше бы понял мой посыл)
Оставляй свой
Здравствуйте, avovana, Вы писали:
A>1) В какой доменной области работаете Вы с С++?
Разработка драйверов ядра для Windows (с тем же успехом можно и для любой другой ОС), прошивок для микроконтроллеров, прикладного софта (в том числе звукового, в реальном времени).
A>Почему он там применяется?
Там, где важно одновременно минимизировать затраты ресурсов, обеспечить время реакции, и/или хорошо сопрячь софт с железом, и при этом не заморачиваться на голом C, альтернативы попросту нет. В этом смысле C++ — уникальный язык. Как сказал один любитель "классического C++", это "язык произвольного уровня". В нем одинаково удобно работать и с регистрами устройств, и с какими-нибудь распределенными базами данных. Но подавляющее большинство современных программистов на C++ этого не понимает — они воспринимают C++, просто как один из ЯВУ, их нередко раздражают его низкоуровневые привязки.
A>3) Какое будушее у языка Вы видите, в целом?
Судя по всему, из него окончательно сделают "просто один из ЯВУ", и его уникальность будет полностью потеряна. Если не придумают языка на замену, то для низкоуровневого и высокоуровневого софта придется всегда использовать разные языки.
A>5) Какие фишки обеспечивают С++ конкурентоспособность сейчас в вашем домене
То, что на нем можно писать практически все то же, что раньше писали на ассемблере (исключения есть, но их очень мало), и на нем же можно писать навороченные абстракции. Правда, многие возможности для этих абстракций реализованы донельзя убого, но, если сдерживать рвотные рефлексы, даже с их помощью можно получать достаточно эффективный машинный код, недостижимый для большинства других языков.
A>6) Насколько в реальности сложен С++
"Базовый" язык (на уровне общих идей и приемов) достаточно прост, многое можно делать интуитивно, не углубляясь в тонкости. Но полный стандарт языка реально огромен, работать с ним достаточно сложно, и многие нюансы гораздо проще нагуглить или выспросить в сообществах, чем продраться через многоэтажные зависимости формулировок в стандарте.
Аналогично, популярная стандартная библиотека (STL) в использовании тоже не слишком сложна, если не пытаться изучать ее устройство (а без этого порой не обойтись). Изучать ее достаточно сложно, поскольку она в изрядной мере построена на хаках и побочных эффектах. А если мозги к такому устройству софта не предрасположены, то изучать это еще и не слишком приятно.
Здравствуйте, velkin, Вы писали:
V>На Си так же пишут драйвера, веб-сервера, базы данных и многое другое. V>Так вот Си и C++ это не одно и тоже. И программисты часто специализируются или на одном или на другом.
Я вот никогда не понимал, отчего последние лет тридцать программисты пишут на C, когда всё то же самое писать на C++ (при наличии реализации под платформу, само собой). За это время не встретил ни одного сишного программиста, чья приверженность C определялась бы чисто техническими условиями, и ничем иным. Все они без исключения либо уверены, будто на чистом C якобы "компактнее", "эффективнее", "надежнее", "предсказуемее", "управляемее" и т.п., либо они тупо ненавидят C++ за исключения, шаблонную магию, STL и прочее, даже не подозревая, что всё это не является обязательным.
Но, если открыть навскидку десяток-другой книг по C++, написанных за последние тридцать лет, в них самые первые примеры почти всегда будут с iostreams, контейнерами, исключениями, шаблонной магией и прочими вещами, которые у типичного сишника прочно ассоциируются с классическими ЯВУ, неприменимыми в тех областях, где он успешно применяет C. Разумеется, он сразу же делает вывод "это не для меня", закрывает книгу, и продолжает использовать голый C, регулярно наступая с ним на все те грабли, для изжития которых C++ и создавался.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Там, где важно одновременно минимизировать затраты ресурсов, обеспечить время реакции, и/или хорошо сопрячь софт с железом, и при этом не заморачиваться на голом C, альтернативы попросту нет. В этом смысле C++ — уникальный язык. Как сказал один любитель "классического C++", это "язык произвольного уровня". В нем одинаково удобно работать и с регистрами устройств, и с какими-нибудь распределенными базами данных. Но подавляющее большинство современных программистов на C++ этого не понимает — они воспринимают C++, просто как один из ЯВУ, их нередко раздражают его низкоуровневые привязки.
Откуда дровишки про большинство современных программистов на C++?
A>>3) Какое будушее у языка Вы видите, в целом?
ЕМ>Судя по всему, из него окончательно сделают "просто один из ЯВУ", и его уникальность будет полностью потеряна. Если не придумают языка на замену, то для низкоуровневого и высокоуровневого софта придется всегда использовать разные языки.
Ну вот если не тащить "совместимость с C", чему ты удивляешься в соседней ветке, то так и будет
Здравствуйте, avovana, Вы писали:
A> Сам он когда-то разрабатывал на rust)
Написано так, словно Rust уже стал мейнстримом, причём, очень давно
A>1) В какой доменной области работаете Вы с С++? Почему он там применяется? Какие задачи решаете?
Встраиваемые системы, удобно писать код, который в compile-time много всего проверяет.
A>2) Будет ли далее там использоваться С++?
Для встраиваемых систем альтернатив пока нет.
A>3) Какое будушее у языка Вы видите, в целом?
Комитет будет его портить всё больше и больше. В какой-то момент FAANG и сочувствующие создадут новый язык на базе LLVM, а С++ забросят.
A>4) Захватит ли всё rust?
Нет. История показывает, что синтаксис решает. Perl хороший язык, но с плохим синтаксисом. Это же касается и Erlang. Где они сейчас?
A>5) Какие фишки обеспечивают С++ конкурентоспособность сейчас в вашем домене и будут обеспечивать в будущем?
Шаблоны, проверки на этапе компиялции, переносимость. Возможность писать bare-metal код.
A>6) Насколько в реальности сложен С++
Абсолютно все правила С++ возможно запомнить, если человек работает исключительно над С++. В больших компаниях есть такие команды "Core C++", которые следят, что С++ использовался правильно. Держать в голове какую-то предметную область вроде робототехники, ИИ, встраиваемых систем и при этом помнить, когда там что куда приводится и когда инвалидируется, где UB, а где не UB — нереально. Даже если запомнить это всё для языка, то памяти на стандартную библиотеку точно не хватит. Я уже молчу, что где-то используют С++14, а где-то С++23.
Здравствуйте, пффф, Вы писали:
П>Откуда дровишки про большинство современных программистов на C++?
Из чтения литературы, статей, обсуждений в сообществах (в том числе здесь).
П>Ну вот если не тащить "совместимость с C", чему ты удивляешься в соседней ветке, то так и будет
Вы точно не путаете совместимость со внешними C-модулями по ABI, и "совместимость" на уровне куска голосишного кода, вкоряченного в плюсовый?
Если нет, то почему бы не повозмущаться, например, работой защиты памяти в той же винде при выполнении досовской программы? Она ж досовская — значит, должна иметь доступ ко всей памяти и ко всему железу, какие основания имеет какая-то там винда ограничивать кошерную досовскую программу?
Здравствуйте, Евгений Музыченко, Вы писали:
П>>Ну вот если не тащить "совместимость с C", чему ты удивляешься в соседней ветке, то так и будет
ЕМ>Вы точно не путаете совместимость со внешними C-модулями по ABI, и "совместимость" на уровне куска голосишного кода, вкоряченного в плюсовый?
Не путаю
ЕМ>Если нет, то почему бы не повозмущаться, например, работой защиты памяти в той же винде при выполнении досовской программы? Она ж досовская — значит, должна иметь доступ ко всей памяти и ко всему железу, какие основания имеет какая-то там винда ограничивать кошерную досовскую программу?
Винда давно уже досовские программы не поддерживает, к чему этот спич?
Здравствуйте, Евгений Музыченко, Вы писали:
П>>Винда давно уже досовские программы не поддерживает, к чему этот спич?
ЕМ>То есть, пока поддерживала (больше двадцати лет, на минуточку), спич был уместен?
Да, можно было бы поговорить об этом. Но вообще не очень понятно, при чем тут ДОС
Здравствуйте, пффф, Вы писали:
П>не очень понятно, при чем тут ДОС
Дык, вот при этом же. В досе можно было в любой момент влезть в любой адрес памяти или любой регистр ВУ, и необходимость обращения через драйвер в винде или унихе многими воспринималась, как личное оскорбление — "это моя машина! это моя программа!". Соответственно, возможность втихую, без хорошо заметного выделения в тексте, без риска получить предупреждение, преобразовать, скажем, long к short, многими сишниками воспринимается, как одно из высших благ языка. Подчеркиваю: не сама возможность это сделать, а именно возможность сделать это походя, привычно, на автомате, и делать такие преобразования сплошь и рядом, уповая на свою память и наблюдательность.
Здравствуйте, Евгений Музыченко, Вы писали:
П>>не очень понятно, при чем тут ДОС
ЕМ>Дык, вот при этом же. В досе можно было в любой момент влезть в любой адрес памяти или любой регистр ВУ, и необходимость обращения через драйвер в винде или унихе многими воспринималась, как личное оскорбление — "это моя машина! это моя программа!". Соответственно, возможность втихую, без хорошо заметного выделения в тексте, без риска получить предупреждение, преобразовать, скажем, long к short, многими сишниками воспринимается, как одно из высших благ языка. Подчеркиваю: не сама возможность это сделать, а именно возможность сделать это походя, привычно, на автомате, и делать такие преобразования сплошь и рядом, уповая на свою память и наблюдательность.
Всё равно, не понял, при чем тут ДОС и сишники. В плюсах любой компилятор тебе варнинг выдаст
П>>В плюсах любой компилятор тебе варнинг выдаст
ЕМ>Только на повышенных уровнях предупреждений. На стандартных — не выдаст, ибо это и есть священная корова.
MSVC на 3м уровне выдаст, это уровень по умолчанию
Здравствуйте, Евгений Музыченко, Вы писали:
П>>MSVC на 3м уровне выдаст, это уровень по умолчанию
ЕМ>Я на них и проверял (15.00 и 19.29) — не выдают. Ни в сишном режиме, ни в плюсовом.
Ну и ладно. Не вижу проблемы. Всё равно ставлю всегда четвёртый уровень
Здравствуйте, Евгений Музыченко, Вы писали:
П>>ставлю всегда четвёртый уровень
ЕМ>Теперь попробуйте /Wall.
ЕМ>Если что, у меня все проекты уже лет двадцать компилятся только с /Wall.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>у меня все проекты уже лет двадцать компилятся только с /Wall.
П>>У меня тоже. И?
ЕМ>Тогда непонятно, зачем Вы мне возражаете. По привычке, из вредности, или?
Я возражаю вашим идеям переделать правила C++ с добавлением возможности менять их на ходу
Здравствуйте, пффф, Вы писали:
П>Я возражаю вашим идеям переделать правила C++ с добавлением возможности менять их на ходу
Тогда Вы должны возражать и против имеющейся возможности изменить класс в C++, когда добавляется, изменяется или удаляется какой-нибудь конструктор или операция. Ну в самом деле: определили класс с набором конструкторов и операций, пользователи к нему привыкли, а мы взяли и поменяли — скажем, в целях лучше читаемости, безопасности или эффективности.
Здравствуйте, Евгений Музыченко, Вы писали:
П>>Я возражаю вашим идеям переделать правила C++ с добавлением возможности менять их на ходу
ЕМ>Тогда Вы должны возражать и против имеющейся возможности изменить класс в C++, когда добавляется, изменяется или удаляется какой-нибудь конструктор или операция. Ну в самом деле: определили класс с набором конструкторов и операций, пользователи к нему привыкли, а мы взяли и поменяли — скажем, в целях лучше читаемости, безопасности или эффективности.
Если вы так сделали, и поломали кучу пользовательского кода — вы очень, очень плохой человек.
ЕМ>В чем тут фундаментальная разница?
В том, что в вашем примере пидоры — это авторы отдельной библиотеки, а вы хотите, чтобы весь комитет C++ стал пидорами и испортил жизнь всему миру
Здравствуйте, пффф, Вы писали:
П>Если вы так сделали, и поломали кучу пользовательского кода — вы очень, очень плохой человек.
Даже если я пользователей регулярно предупреждал в течение многих месяцев или лет, что решение было неудачным и требует исправления, рассказывал, как заранее подготовиться к исправлению и т.п.? А пользователи, которые вместо того, чтобы проявлять разумную осмотрительность, все это время занимались рисованием новых анимированных значков, написанием рекламных статей, грязными трюками SEO и подобным — очень, очень хорошие люди?
П>В том, что в вашем примере пидоры — это авторы отдельной библиотеки, а вы хотите, чтобы весь комитет C++ стал пидорами и испортил жизнь всему миру
Так он уже это сделал, запихав STL, реализованную через жопу, в стандарт языка. Куда уж дальше-то?
Здравствуйте, Евгений Музыченко, Вы писали:
П>>Если вы так сделали, и поломали кучу пользовательского кода — вы очень, очень плохой человек.
ЕМ>Даже если я пользователей регулярно предупреждал в течение многих месяцев или лет, что решение было неудачным и требует исправления, рассказывал, как заранее подготовиться к исправлению и т.п.? А пользователи, которые вместо того, чтобы проявлять разумную осмотрительность, все это время занимались рисованием новых анимированных значков, написанием рекламных статей, грязными трюками SEO и подобным — очень, очень хорошие люди?
А перед этим 30 лет твоя библиотека была хороша, а тут ты решил, что она кривая? Да, тогда ты пидор
И не очень понимаю. Предупреждал, и что? Все должны броситься переписывать код, который писался десятилетиями, и уже мало кто знает, как оно работает, потому что отсы основатели давно уволились?
П>>В том, что в вашем примере пидоры — это авторы отдельной библиотеки, а вы хотите, чтобы весь комитет C++ стал пидорами и испортил жизнь всему миру
ЕМ>Так он уже это сделал, запихав STL, реализованную через жопу, в стандарт языка. Куда уж дальше-то?
STL вполне годная библиотека общего назначения. Тебе что-то не нравится в ней? Заведи отдельную тему для обсуждения недостатков STL. Тут вроде недостатки самого языка обсуждаем, а не его библиотеку
Здравствуйте, Pitirimov, Вы писали:
P>Изобретатель Си++ Страуструп никогда не работал в промышленности, а сидел в комнате за своим столом и общался лишь с другими преподавателями да бухгалтерами университета, куда он смог пристроиться на работу.
Не знаю, где Вы вычитали эту туповатую сказочку, но не ходите туда больше читать, плохому научитесь.
На мой взгляд, Страуструп — один из немногих людей, которые до сих пор относятся к C++ взвешенно. Даже в последних своих работах он не настаивает на использовании исключений, контейнеров, сложных шаблонов и прочего, что большинство остальных авторов давно и прочно именует "признаками настоящего современного C++", а лишь рекомендует наиболее типовые решения, и обычно поясняет, какие из них достаточно эффективны, а какие — лишь достаточно надежны.
P>Задачи, когда необходимо выполнить задачу любой ценой, вождю Си++ были неведомы.
И как же при этом любая мало-мальски промышленная реализация C++, полностью отвечая стандарту, позволяет выполнить любую задачу не хуже, чем чисто сишная?
P>Что ты предпочтёшь получить: надпись на панели приборов об отказавших датчиках и заглохший двигатель или отключившуюся панель приборов, но движущийся автомобиль, на котором ты сможешь выехать с перекрёстка?
Я бы предпочел получить более конкретное объяснение связи вышеописанного с обсуждаемой тематикой. Пока не вижу ни малейшей связи — чистое фантазирование.
Здравствуйте, avovana, Вы писали:
A>Подскажите, пожалуйста: A>1) В какой доменной области работаете Вы с С++? Почему он там применяется? Какие задачи решаете?
Два года работал через аутстафф-галеры на телеком-проектах. Сейчас не там.
Внутренние компоненты специализированных связистских железок с линуксом внутри, x86, ARM/32, ARM/64.
Почему применяется — ХЗ. Для ~90% случаев был бы полезнее какой-нибудь Go. Реальный уровень языка (и людей) в таких проектах чудовищно низкий. В большинстве запрещены исключения. Ни в одном не используется напрямую высокая шаблонная магия, в лучшем случае зовут Boost.Asio и другие легко используемые компоненты буста.
Для борьбы с проблемами языка (и отладки всяких крэшей) типично полное выключение оптимизаций. Всё равно критические по времени вещи давно унесены в железо.
A>2) Будет ли далее там использоваться С++?
Будет, несмотря на то, что нафиг не нужен и даже вреден. Ибо менеджеры ширнармасс, наполовину состоящих из индусов, иначе не умеют, даже если умеют сами сотрудники.
A>3) Какое будушее у языка Вы видите, в целом?
Хреновое. Потому что вот такие вот направления тянут за собой на дно всех остальных.
A>4) Захватит ли всё rust?
Нет. На нём сложно писать. Я больше поверю, что когда-нибудь такие проекты сползут на Go, Zig, ещё несколько, или даже Java и C#.
A>5) Какие фишки обеспечивают С++ конкурентоспособность сейчас в вашем домене и будут обеспечивать в будущем?
Неисправимая тупизна слоя лиц принимающих решения о технологиях.
A>6) Насколько в реальности сложен С++
Очень сложен. Если не кодом, так тем, что что-то сломают в соседнем отделе, а потом ищи, кто тебе портит память.
Намеренно отвечаю тут (туда тоже продублирую по возможности), ибо захотелось оставить замечание.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Но, если открыть навскидку десяток-другой книг по C++, написанных за последние тридцать лет, в них самые первые примеры почти всегда будут с iostreams, контейнерами, исключениями, шаблонной магией и прочими вещами, которые у типичного сишника прочно ассоциируются с классическими ЯВУ, неприменимыми в тех областях, где он успешно применяет C. Разумеется, он сразу же делает вывод "это не для меня", закрывает книгу, и продолжает использовать голый C, регулярно наступая с ним на все те грабли, для изжития которых C++ и создавался.
Вот ты мне скажи — когда у тебя в ядре Windows драйвер на C++, у него есть cin и cout? Если нет, то почему?
Авторы всех до единой книг по C++, которые я видел, рассчитывают на hosted + userland. Наверно, тебе надо написать свою, чтобы поломать эту тенденцию.
Здравствуйте, netch80, Вы писали:
N>когда у тебя в ядре Windows драйвер на C++, у него есть cin и cout?
Есть. Они как-то определяются в WDK, а деталей не смотрел. Возможно, cout заведен на ядреный отладочный вывод, а cin всегда возвращает конец потока.
А new/delete у меня свои.
N>Если нет, то почему?
Если б их не было, я б ответил — "не определили". Это ж просто обычные плюсовые классы с наборами методов, их можно определить для чего угодно, хоть для самого мелкого МК, и работать через них с каким-нибудь RS232. Только надо ответить на вопрос "зачем?".
Вот плюсовые исключения в ядре не реализованы — только родные структурные, которые разматывают стек вызовов, но ничего не знают про деструкторы. В принципе, нет никаких технических проблем сделать поддержку плюсовых исключений и в ядре, но они ж так по-дурацки определены, что не могут работать без RTTI, который в ядро уж точно никто не потащит. Если б исключения в C++ были определены попроще — возможно, и сделали бы поддержку в ядре. Структурные исключения само ядро вполне себе использует.
И реализаций STL для виндового ядра, насколько я знаю, никто не делал, хотя разумное подмножество сделать нетрудно.
Проблема ведь даже не в реализации, а прежде всего в том, что отсутствием всех этих плюшек обеспечивается хоть какой-то порог вхождения. Стоит их реализовать, как сразу набегут стильные, модные, молодежные, и убьют все хорошее, что сохранилось.
N>Авторы всех до единой книг по C++, которые я видел, рассчитывают на hosted + userland.
Такая же фигня, пока не попалось "Введение в C++" Столярова. Но его книги неокрепшим умам читать опасно — может развиться линуксоидность головного мозга.
N>Наверно, тебе надо написать свою, чтобы поломать эту тенденцию.
Полноформатную книгу я вряд ли осилю, а вот что-нибудь вроде статьи об использовании C++ в ядре ОС и на голом железе, может, и рожу когда-нибудь.
Щас хохмы ради накидал простейший пример наследования с виртуальными функциями, собрал под ATTiny13 (самый мелкий МК от AVR) — прошивка получилась аж на двести байт.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот плюсовые исключения в ядре не реализованы — только родные структурные, которые разматывают стек вызовов, но ничего не знают про деструкторы. В принципе, нет никаких технических проблем сделать поддержку плюсовых исключений и в ядре, но они ж так по-дурацки определены, что не могут работать без RTTI, который в ядро уж точно никто не потащит. Если б исключения в C++ были определены попроще — возможно, и сделали бы поддержку в ядре. Структурные исключения само ядро вполне себе использует.
RTTI как раз тривиально включить, в чём проблема? Ещё один указатель в каждой VMT, и константная структурка.
А вот исключения которые аллоцируют объект на каждую генерацию — могут быть проблемой. Было предложение на исключение которое не объект, а просто указатель на тип (в стиле Ada) — пока не прошло.
N>>Авторы всех до единой книг по C++, которые я видел, рассчитывают на hosted + userland. ЕМ>Такая же фигня, пока не попалось "Введение в C++" Столярова. Но его книги неокрепшим умам читать опасно — может развиться линуксоидность головного мозга.
N>>Наверно, тебе надо написать свою, чтобы поломать эту тенденцию.
ЕМ>Полноформатную книгу я вряд ли осилю, а вот что-нибудь вроде статьи об использовании C++ в ядре ОС и на голом железе, может, и рожу когда-нибудь.
Здравствуйте, netch80, Вы писали:
N>RTTI как раз тривиально включить, в чём проблема?
В том, что все это на фиг не нужно для обработки исключений, как таковых.
N>Ещё один указатель в каждой VMT, и константная структурка.
Плюс дополнительный код в catch, который выясняет, какой тип был выброшен.
N>А вот исключения которые аллоцируют объект на каждую генерацию — могут быть проблемой.
Не только "аллоцируют", но и копируют его в обработчик catch.
N>Было предложение на исключение которое не объект, а просто указатель на тип
Да, это было бы удобно. Но вряд ли прокатит — кого из комитетчиков это парит? Ну гоняются там несчастные сотни байтиков по стеку, какое это может иметь значение на фоне мировой революции нынешнего представления о том, что софт, требующий под сотню метров памяти считается "весьма компактным"?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Да, это было бы удобно. Но вряд ли прокатит — кого из комитетчиков это парит? Ну гоняются там несчастные сотни байтиков по стеку, какое это может иметь значение на фоне мировой революции нынешнего представления о том, что софт, требующий под сотню метров памяти считается "весьма компактным"?
Хех. У меня в одном недавнем проекте был бинарник с объёмом кода 250MB ;\
Здравствуйте, Pitirimov, Вы писали:
P>Я сравнил использование кодов возврата из функций чистого Си в сравнении с исключениями Си++.
С какой целью Вы это делали? Ну, кроме как натянуть сову на глобус?
P>Ты же сам написал что именно программистов на Си не устраивает в Си++, я тебе и разъяснил почему люди так считают.
Теперь мне требуется разъяснение, почему именно программистов на C не устраивает в C++ сам факт наличия исключений, которое им, в случае перехода, не будет стоить ничего. Или сишники все, как один, такие донельзя убогие, как Вы описали ниже? Я вот уже лет тридцать делаю софт только на плюсах, и не использую не только исключений, но и STL. Святой, наверное.
P>Тут "плюсисты" обычно высказываются о том, что никто не заставляет использовать исключения, где они не нужны.
Да, именно так. Ну, по крайней мере, у тех, кто дружит с головой.
P>Это похоже на то, что выдать рабочим по тарелке супа за обедом, поставить тарелку винограда на стол и наказать, чтобы никто не ел виноград.
Нет, это похоже на то, что кто-то отчаянно хочет найти убедительные причины, но не может, и вынужден сочинять корявые фантазии, не утруждаясь при этом обеспечить хотя бы минимальную похожесть.
P>Природу животного мира в людях никто пока что никто не смог искоренить и красть еду исподтишка — всего лишь один из способов выживания особи в дикой природе. Отец Сергий отрезал себе палец, когда к нему в землянку зашла женщина среди ночи и метели. А теперь представь, что эта же самая женщина зашла бы к пьяным рабочим-вахтовикам в их вагончик — бабу не просто грубо облапали бы, а чего и похуже бы сделали с вероятностью 99 процентов.
Почему у меня это сразу ассоциируется с сишными операциями "неограниченного" приведения типов, "тихими" сужающими преобразованиями, практикой передачи через void *, полностью ручным управлением память. Странно, вроде бы никакой связи. Наверное, музыкой навеяло...
P>Единственный выход — ограничить внесение лажи в проект через написание ПО на чистом Си вместо Си++, чтобы с плёткой не стоять у людей над душой.
При таком подходе, самый правильный выход — сразу застрелиться насовсем, дабы не мучить себя искушениями бесовскими.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, netch80, Вы писали:
N>>У меня в одном недавнем проекте был бинарник с объёмом кода 250MB ;\
ЕМ>Было бы очень любопытно узнать распределение сущностей по объему — код, двоичные данные для кода, тексты, изображения, видео и т.п.
В основном огромное число толстых библиотек, из бо́льшей части которых используется минимум всякого, но подключали по принципу leftpadʼа.
.
