Comments 15
Это не очень хороший способ ожидания завершения операции поскольку он вносит почти секундную (статистически 0.5 секунды) задержу:
// Основной поток ждет завершения работы runApp
while (!shouldExit.load()) {
sleep(1); // Снижаем нагрузку на процессор
}Начиная с C++20, можно делать:
shouldExit.wait(false);Подробности в: https://en.cppreference.com/w/cpp/atomic/atomic/wait
Для более старого компилятора, можно использовать стандартное решение на основе std::condition_variable + std::mutex. Подробности и примеры в: https://en.cppreference.com/w/cpp/thread/condition_variable.html
Несмотря на развитие лингвистических моделей, я подумал, что моя версия супервизора может быть достаточно интересна для размещения в статье.
Как у Вас связано развитие лингвистических моделей и "своя версия" "супервизора"? Непонятно.
Вопрос в том, что в учебных заведениях, как правило, сначала изучается Си, а только потом С++ и зачастую стиль кода на С++ - Си с классами. Естественно, это влияет на репутацию языка как недостаточно надёжного.
Что? Откуда вообще взялись такие выводы? В каких-то учебных заведениях изучение происходит начиная с C++, в каких-то с Си, а в каких-то и то и другое изучается. Но это ни в коем случае не влияет на надёжность Си или C++. Вообще никак это не связано.
Что Си, что C++ - достаточно надёжные языки программирования. Разработчик может написать не надёжный код и на Java, и на Kotlin, C#, Go или JavaScript. И по памяти не надёжный (да-да, в таких языках встречаются и утечки памяти, но более высокоуровневые), и по работоспособности.
С наступлением эпохи лингвистических моделей код на С++ стал существенно надёжнее
Опять вопрос - чего? Автор статью с LLM моделью писал? Какие-то очень глупые выводы. Типа "пришла эпоха LLM, код на C++ стал существенно надёжнее" - полная чушь. Код надёжен или не надёжен в зависимости от опыта программиста, который этот код пишет. Всё, точка. В LLM загружены огромные базы кода, написанные людьми, которые и используются LLM как фундамент. Т.е. этот вывод буквально сам себе противоречит - как он стал надёжнее (причём язык программирования), если код, на котором обучалась LLM был написан людьми? Ну глупость же.
но сам код создаёт впечатление образцового
Вот именно: создаёт впечатление. Атомарной переменной явно присваивать значение true
shouldExit = true;вообще не стоит, вместо этого нужно вызывать метод store, т.к. он достаточно универсален и даёт большую гибкость:
shouldExit.store(true);И вместо ожидания в цикле:
// Основной поток ждет завершения работы runApp
while (!shouldExit.load()) {
sleep(1); // Снижаем нагрузку на процессор
}Стоило использовать condition_variable, поскольку нагрузка на процессор в данном случае всё равно будет.
отслеживаемая программа
Кхм... громко сказано, но тут ничего не отслеживается. Тут тупо представлен код для перезагрузки уже не работающей программы, вот и всё. С n-ым числом попыток. Причём даже валидации аргументов нет (вдруг, argv[2] будет не числом?).
Короче статью, как и код, написала LLM :) Вот уж заменила она автора, так заменила.
Почти со всем согласен, но С/C++ все же потенциально более опасны, чем "управляемые" языки. Но даже если написал всё правильно, никуда не девается фрагментация памяти, а писать так, чтобы её не было, это ещё одно умение, которым мало кто владеет даже из сишников (легче прикрутить тот же watchdog/супервизор, или вообще нет требования, чтобы сервис работал 24х7 много дней подряд без падений).
Что Си, что C++ - достаточно надёжные языки программирования.
Можно пример используемой программы на С, у которой в анамнезе нет ошибок работы с памятью?
Код надёжен или не надёжен в зависимости от опыта программиста, который этот код пишет.
Ага, причём нередко обратно пропорционально. Там где новичок или середнячок в С++ использует более надёжные конструкции языка из std - опытный кодер наворотит ручной порнографии с сырыми указателями и дырами/сегфолтами.
Можно пример используемой программы на С, у которой в анамнезе нет ошибок работы с памятью?
Без проблем:
#include <stdio.h>
int main() {
printf("Hello World!\n");
return 0;
}Если есть проблемы - покажите где они конкретно тут присутствуют. Используется эта программа как базовый пример на Си. Ну, а если серьёзно - посмотрите в ядро Linux. Часто ли там проблемы с памятью возникают? Если бы они очень часто возникали - Linux дистрибутивы были бы не нужны, из-за своей не стабильности и высокопроизводительные сервера на них не работали (один Nginx чего стоит).
Там где новичок или середнячок в С++ использует более надёжные конструкции языка из std - опытный кодер наворотит ручной порнографии с сырыми указателями и дырами/сегфолтами.
Ну, с "сырыми указателями" нужно просто уметь работать, ручная работа с указателями вообще не вредна, если эта работа учитывает все особенности таких указателей. Да и свои умные указатели можно написать, для обработки "сырых указателей". Вы ведь не думаете, что "надёжные методы" при работе с указателями прям вообще не используют сырые? (ещё как используют).
Ну, а если серьёзно - посмотрите в ядро Linux. Часто ли там проблемы с памятью возникают?
Серьёзно? Чуть менее чем все CVE там связаны с некорректной работой с памятью. Часто ли их находят? Ну, достаточно часто: https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
Если бы они очень часто возникали - Linux дистрибутивы были бы не нужны, из-за своей не стабильности и высокопроизводительные сервера на них не работали (один Nginx чего стоит).
Ошибочная логика. Linux так используем в этих сегментах просто потому что совокупно ничего лучше для этих сегментов нет. Даже при всей дырявости ядра.
Ну, с "сырыми указателями" нужно просто уметь работать
Опять 25. Вы мне покажите хоть одного человека, который "просто умеет" с ними работать. Если реальные сишники, даже самые опытные, в реальных проектах постоянно плодят дыры и сегфолты из-за ошибок работы с памятью.
Вы ведь не думаете, что "надёжные методы" при работе с указателями прям вообще не используют сырые? (ещё как используют).
В безопасной бритве тоже есть лезвие, как и в опасной, но порезаться безопасной риск куда меньше, понимаете к чему я клоню?
С Вашими аргументами частично можно согласиться, а частично - поспорить. В любом случае в долгих спорах смысла нет. Не нравится Си/C++ и то, как он работает? Не используйте его, в угоду более "безопасным" языкам программирования (c Вашей точки зрения).
Мне вот C++ очень нравится, я его использую, изучаю все тонкости и особенности работы с этим языком и внутренние его механизмы. Да, с ним много сложностей и потенциальных проблем, но если быть внимательным и постоянно улучшать программный код можно добиться потрясающих результатов. Как с точки зрения производительности, так и с точки зрения безопасности.
У него уже есть альтернативы в виде Rust, Go, Zig и т.п., которые также неплохи в производительности, можете их использовать (или советовать их использовать). В сущности всё равно, что каждый программист использует для того или иного приложения или продукта. Я использую C++, кто-то C#, кто-то Rust или JavaScript. Все языки важны :)
Чтобы полностью понимать язык программирования или любую другую технологию нужно иметь довольно объёмный опыт работы с ним (ней). Я пока не могу полностью судить о C++, т.к. достаточно на нём ещё не программировал. Пока что мой рекорд 20 тыс. строк работающего кода на C++ (с большим числом всякого рода особенностей). Как напишу миллион или пару миллионов - тогда буду уже оценивать этот язык по другому (возможно, а возможно и нет).
Логика в том, что есть 2 варианта при возникновении подобной задачи: пробовать написать самостоятельно(скорее всего не без помощи LLM) и скопировать готовое (частично готовое) решение. Предполагаю, что готовое решение более предпочтительно. Что касается повышения качества кода лингвистическими моделями. На это есть 2 причины:
1) лингвистические модели генерируют в среднем далеко не самые плохие фрагменты кода, так как обучаются на больших кодовых базах;
2) существенно повышается конкуренция в сфере создания ПО, что естественно повышает качество кода в среднем.
Предполагаю, что готовое решение более предпочтительно.
Почему? Обычно программисты на C++ сами пишут свои библиотеки, фреймворки для решения каких-то конкретно их задач. Так уж сложилось, да и удобство пакетных менеджеров до сих пор оставляет желать лучшего.
2) существенно повышается конкуренция в сфере создания ПО, что естественно повышает качество кода в среднем.
Опять же - нет, это не так. Повышение конкуренции ещё не означает, что код будет качественный. Даже в среднем. Сейчас бум багованных продуктов, которые в среднем написаны не очень хорошо, но работают (плохо, не оптимально, сжирая ресурсы).
1) Значительную часть применения С++ составляет геймдев. Там есть понятие "время кадра" - один самых важных параметров, который нужно оптимизировать. Поэтому писали свои оптимизированные структуры данных. Или же была статья как писали свой класс строки в PVS-Studio. Или какие-то другие подобные причины. То есть причина не в том, что "так сложилось" а более конкретная, чаще связанная с производительностью, реже - с удобством использования, стабильностью и размером библиотеки.
2) Да, я согласен что проникновение скриптовых языков, особенно пайтона, приводит более медленной работе программ. FreeCad в пример.
Простой и эффективный супервизор на С++ с универсальным Makefile