Компания Intel опубликовала первый значительный релиз инструментария ControlFlag 1.0, позволяющего выявлять ошибки и аномалии в исходных текстах, используя систему машинного обучения, натренированную на большом объёме существующего кода. В отличие от традиционных статических анализаторов, ControlFlag не применяет готовых правил, в которых трудно предусмотреть все возможные варианты, а отталкивается от статистики использования всевозможных языковых конструкций в большом числе существующих проектов. Код ControlFlag написан на языке С++ и открыт под лицензией MIT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56187
Все, Rust больше не нужен?
Программисты больше не нужны
Сам себе отвечу - все еще нужен. Но только после того, как в него будет встроена обученная система (путём построения статистической модели имеющегося массива кода открытых проектов, опубликованных в GitHub и подобных публичных репозиториях) с парочкой новых синтаксических конструкций вроде $$&: и $$&:$.И главное(!) не забыть что-нибудь сломать. Чтобы новым компилятором старый код больше не собирался.
Ты вроде описал только что Copilot.
> И главное(!) не забыть что-нибудь улучшить!поправил, не благодари.
P.S. разумеется, немодный неулучшенный исходник улучшенным компилятором собираться не будет. Это, в конце-концов, просто небезопастно.
На чём обучать-то? Завершённого кода на Rust нет.
Там можно обучать на незавершенном. А для тех кто научился проект всегда найдется например https://github.com/servo/servo давно бы пора уже дописать.
Доказать можете? Или это просто фантазии?
Вы описали бессмысленные и несуществующие в Rust синтаксические конструкции. Что же касается сборки старых проектов: у вас есть негативный опыт? Можете его описать подробне? Не встречал ни разу сколь либо значимых проблем с обратной совместимостью в Rust. Не за то критикуете.
ПМСМ и не нужен был, сразу со своего появления всё чем он тащил, так это рекламой, в остальном по мне код на расте ужасное нечитаемое Г, как будто раст развивают те же любители бесконтрольно пачками тащить в язык новомодные конструкции и плюшки, как в том же питоне и плюсах - как итог однородность кода падает и постоянные переключения в восприятии препятствуют накоплению устойчивого опыта в анализе кода, другими словами - лучше проще, но без крайностей.
>по мне код на расте ужасное нечитаемое ГИли твои когнитивные способности оставляют желать лучшего. Ну не всем в жизни с интеллектом повезло, бывает.
В Расте гораздо больше интересностей, чем почему-то рекламирумый один лишь safe.
Сям до него далеко.Но старый код на си никто не отменял, к сожалению.
Да всем честно говоря пофиг на твой раст.
Три дня! Три дня я гналась за вами, чтобы сказать, как вы мне безразличны!
Да нет. Написать однострочный комментарий это дело максимум одной минуты. Тем более, ответить "да мне всё равно" на чей-нибудь рассказ и гнаться за кем-то, чтобы первым завести разговор это разные вещи.Но вот за всех говорить не есть хорошо.
И это true
#define true false
Да, всем...
Тогда зачем было про него спрашивать изначально?
Загляни в лог модерирования, чтобы заценить насколько "всем пофиг".
проблема раст какраз в safe и unsafeбез unsafe вы не можете ничего.
А суть в чём? вы пытаетесь решить те проблемы которых в современном C++ не существует уже 100 лет в обед.
Всё уже решено без вас, но вы же что, документацию осилить не в состоянии!
smart pointers, range loop, etc, не не слышали?
> проблема раст
> Всё уже решено без вас, но вы же что, документацию осилить не в состоянии!
> smart pointers,А ты самокритичный. Только зачем пишешь о себе в третьем лице?
Речь идет о С. Каким боком тут С++?
Кстати, пишу на C со времен Microsoft С 6.0. Что-то ни в какой safety и прочей нубо-херне не нуждаюсь. Да, на C писать занудно, долго, напряжно и, возможно, даже опасно, если не быть паранойиком, но на С++ косяков можно наделать на порядок больше, да и сами они будут гораздо убойнее. При этом програма будет зело тормозной.
Не знаю за раст, но если там нет возможности управлять памятью, обращаясь для этого напрямую к операционке, то место его рядом с жаврой и решетками.
> Речь идет о С. Каким боком тут С++?Ты совершенно прав. Это именно так.
Я думаю C++ сюда приплели тем-же боком каким приплели rust. Т.е. это был ответ тому вон пленному слоугному который приплёл сюда свой раст.
Тем не менее C++ гораздо ближе к C чем раст. Так таки обоим + а расту -
> проблема раст какраз в safe и unsafeНет.
> без unsafe вы не можете ничего.
unsafe в избранных местах и 146% unsafe -- разные вещи.
> которых в современном C++ не существует уже 100 лет в обед
Ну конечно. И сегфолтов у него совсем нет, и миллиона UB нет, и вообще идеал.
Кстати, именно C++20 для меня стал поводом внимательнее посмотреть в сторону Раста.> документацию осилить не в состоянии
Ну конечно, это один лишь ты можешь.
Кстати, а какую именно документацию из горы неофициальных? У Раста есть качественная официальная, к примеру.> smart pointers
Затычка, костыль, еще и не до конца zero cost.
Случайный delete smart_pointer.get() растопит все иллюзии :)Складывается ощущение того, что ты о Расте либо слышал/читал в комментах, либо не пошел дальше уровня hello world.
Опять же, в сравнении с C или C++ сила Раста вовсе не в safe.
Лично мне возможность создания чего-то вроде https://serde.rs/ сильно дороже.
Или нормальная экосистема с нормальным пакетным менеджером (а не vcpkg) и нормальной системой сборки (а не CMake, qmake и еще миллион легиона). Или еще много чего, чего никогда не будет у C++ и тем более C.
А весь гарантируемый safe (который, кстати, гарантируется и в unsafe) -- скорее приятный бонус.А тебе оставлю такой бонус:
- Статья от человека из комитета: https://thephd.dev/your-c-compiler-and-standard-library-will...
- https://habr.com/ru/post/592233/Вряд ли прочитаешь конечно, я сегодня некропоспотер, но, может, кому полезно будет.
Раст это тот который C--?
Евгений Ваганович, это вы?
roosterы, всюду приплетающие rust, не нужны.
Да, в клубе ценителей г-на мамонта не нужны, тут ты прав.
А он разве нужен был?
Не спору ради, а просто уточнить: вы действительно думаете что вероятностная определялка локальных AST-паттернов (на основе обучения) заменяет safety-by-design от Rust?
Нет. И мне кажется, что мой троллинг должен быть вполне очевиден любому человеку с IQ больше 50.И еще: мне очень нравится идея safety-by-design от Rust, но очень не нравится сам Rust, который взял и навалил огромнейшую кучу гoвнa поверх жемчужины. При этом я искренне не могу понять тех, кто это гoвнeцo наворачивает с причмокиванием и хвалит.
Жду, когда ту же идею реализуют в чем то, что будет иметь изначально продуманный дизайн, который не придятся ломать каждых три месяца ввиду "ой, а вот это мы не продумали, давайте навалим парочку новых заплаток".
Можно больше подробностей про то, где в Расте что-то ломают каждые три месяца?
Ну и про кучу Г в исполнении Раста, тоже хотелось бы понять, что вы там никак не осилите. Обычно человек ругает то, с чем не в состоянии разобраться.
> Обычно человек ругает то, с чем не в состоянии разобраться."Я не жирная, меня все оговаривают потому что завидуют" (с)
Обычно не надо разбираться в последних нюансах вкуса сортов говна и деталях запаха оного чтобы утверждать "это говно".Или вы действительно считаете, что раст - это такой недостижимый рокет-саенс, самый сложный и умный язык тысячелетия, с которым не судьба разобраться практикующим уже более 20 лет программирование на различных языках, начиная с ассемблера и заканчивая хаскелем? Поэтому они и плюются, ведь им так больно, что не смогли осилить то, что осилили вы с вашим iq 75?
> тоже хотелось бы понять
Тысячу раз уже перетирали, с большими и пространными простынями. Не вижу смысла делать то же самое тысячапервый.
> Или вы действительно считаете, что раст - это такой недостижимый рокет-саенс, самый
> сложный и умный язык тысячелетия, с которым не судьба разобраться практикующим
> уже более 20 лет программирование на различных языках, начиная с ассемблера
> и заканчивая хаскелем? Поэтому они и плюются, ведь им так больно,
> что не смогли осилить то, что осилили вы с вашим iq
> 75?Ну вот ты - не осилил, на чем тебя пару раз и ловили. После чего ты предпочел писать поменьше конкретики, ограничивая обыкновенным словесным поносом "ни о чем".
А судя по плаванию в терминологии с той же "хвостовой рекурсией" - и хаскель ты тоже "осилил" примерно на том же уровне.
Ээээ, щито? На чем там меня ловили?
Вам, уважаемый, раст совсем мозги выел?---
Ахахахахах, растоманы действительно считают раст самым сложным языком, недоступным другим. Спасибо, я хорошо проржался. У меня появился еще один аргумент в троллинге растофанатиков.
> Вам, уважаемый, раст совсем мозги выел?О, в ход пошел самый "аргументативный аргумент". Впрочем, ничего нового.
>> Ну вот ты - не осилил,
> Ахахахахах, растоманы действительно считают раст самым сложным языком, недоступным другим.У тебя какая-то мания величия. Ты - это ты. Не "другие".
> Спасибо, я хорошо проржался. У меня появился еще один аргумент в троллинге растофанатиков.
О да, "троллинг тупостью" и приседанием в лужу - напугал, так напугал!
Как только люди не извращаются, только бы не переходить на изначально нормальный, современный язык Rust, свободный от недостатков г-на мамонта под названием Си. Ещё больше чекеров богу чекеров. Уже до машинного обучения дошло там, где нормальный компилятор проверяет подобные ошибки легко и непринуждённо. А луддиты ликуют - им очередной костыль подарили. Инвалиды, что с них взять. Интеллектуальные инвалиды.
> ... нормальный компилятор ...А-ха-ха-ха-ха-ха-ха.
Вообще интересно, что на это скажут PVSники и находит ли их анализатор эти ошибки ?
именем чебурнета нашаго, не задавай такие наивные вопросы. кому надо, тому доложено
присоединяюсь к вопросу. может быть достойных конкурент для них
PVS и раньше не был единственный производителем анализаторов кода.
Тут, как я понимаю, принциально другой подход к поиску - с отличием от набора эвристик для поиска. таких не было
Да они опубликуют очередной пост на хабре. Это не компания производитель софта это компания производитель постов на хабр.
Ну на эту тему они уже высказались на Хабре: https://habr.com/ru/company/pvs-studio/blog/484208/ и https://habr.com/ru/company/pvs-studio/blog/496536/И, что показательно, сами того не заметив, в качестве примера хорошего срабатывания DeepCode в первой статье привели неправильную рекомендацию (DeepCode не заметил неправильный Content-Type).
Можно подумать это не они тут seo себе накручивают в комментах...
Комментировал на тему ControlFlag здесь: https://habr.com/ru/company/pvs-studio/news/t/589247/comment...
Неужели эта поделка поможет решету стать менее дырявым? Лучше бы труЪ-сишников, у которых никогда ничего не падает, научились клонировать. Вот на опеньке сколько именных кандидатов - один 100 языков знает, другой всегда пишет без бэд-аксесов.
>Неужели эта поделка поможет решету стать менее дырявым?Нет, конечно. Но она поможет какое-то время верить луддитам в свою восстребованность без необходимости учить что-то более нормальное и адекватное (Rust). Мозг-то изначально интеллектом не блистал, только на Си их и хватило за всю жизнь. А к старости и усыхать начал. Обидно ведь за бортом рынка труда остаться.
Ох как только языком это раст’аманы могу. Это все что они могут - трепать языком. А теперь давай собирай свои растовые программы без libc. Если мозгов только хватает чтобы за тебя другие разработчики возились с памятью, указателями и процессором тебе бы лучше оставить профессию людям с IQ куда выше табуретки. Иди на надевай фуфайку и на завод работать, нечего делать тебе в офисе.
> А теперь давай собирай свои растовые программы без libcТы так пишешь, как будто ты - один из авторов libc. Хорош петросянить, займись уже чем-нибудь более полезным. ;)
> А теперь давай собирай свои растовые программы без libc.Какой занятно-махровый ламеризм
https://man7.org/linux/man-pages/man2/syscalls.2.html
> System calls are generally not invoked directly, but rather via
> wrapper functions in glibc (or perhaps some other library).Хотя да, сначала можно повозмущаться использованием программамаи на rust "системного апи", а если притащат свой рантайм - "опять у них синдром НИХ!" - вин-вин, че.
Т.е. если большинство делает какую-либо ошибку, которая приводит к дырым, эта вундервафля заставит и остальных так поступать? Это вы хитро придумали.
Она не отыскивает ошибки, а она определяет аномалии.
И если все делают одну и ту же ошибку, то какая же это аномалия? Это уже диалект.Поэтому надо быть готовым к ситуации, когда свободолюбивые западные программисты сочтут сообщения компилятора дискриминацией по ошибочному признаку и потребуют от производителей систем и/или железа исключить возникновение ряда распространённых ошибок (запись в NULL-поинтер, например).
Для работы в таких условиях искать надо не ошибки, а именно аномалии.
Хватит приплетать. Сходите к врачу, не перекладывайте с больной головы на здоровые.
>В качестве примера возможностей ControlFlag разработчиками был проведён анализ исходных текстов проектов OpenSSH и cURL:Гора родила мышь
Чтобы научить ИИ отыскивать ошибки, нужен бы большой массив кода с уже кем-то найденными ошибками, помеченными и описанными, но ещё не исправленными, разве не?
А оно ищет не ошибки, а аномалии. То есть всё, что выглядит необычно.
>>В cURL выявлена незамеченная статическими анализаторами ошибка при использовании элемента структуры "s->keepon", который имел числовой тип, но сравнивался с булевым значением TRUE.это где то я уже видел :)
> В cURL выявлена незамеченная статическими анализаторами ошибка при использовании элемента структуры "s->keepon", который имел числовой тип, но сравнивался с булевым значением TRUE.это чистой воды бюрократия.
потому что cURL написан на сях, в которых тип _Bool появился только в C99 (bool есть его define), поэтому в stdbool.h и в lib/curl_setup_once.h, значение true во всех определениях сводится к 1, а false -- к 0;
TRUE определён как define от true.поэтому ошибкой будет только ситуация, когда смысл в поле вкладывается не булевый.
в текущей версии (7.80) данное поле определено как enum, поэтому теперь такая ситуация исключена.
> ошибкой будет только ситуация, когда смысл в поле вкладывается не булевый.Почему бы алгоритму этот смысл не вычислить? Ему ж это ещё проще будет, чем человеку: достаточно проверить все использования переменной по всей программе, и посмотреть кладётся ли туда когда-нибудь целое, отличное от 0 и 1. Это, конечно, не очень сработает с _реальными_ C'шными программистами, потому что они могут написать "int bool_var = ptr", допустим, вместо "int bool_var = !!ptr" или "int bool_bar = (ptr != NULL)". Но с этим тоже можно справиться, если во-первых, смотреть не только на запись в переменную, но и на использование "if(bool_var)" или "if(bool_var==2)", а во-вторых, уйти от аристотелевой логики в сторону вероятностной, и истинность высказывния "bool_var -- булевская переменная" измерять не двумя значениями {истина, ложь}, а вещественным числом (0, 1), которое будет отражать likelyhood того, что это утверждение истинно в аристотелевском смысле. Собственно этим последним образом человек как правило и поступает. И заметив высокий likelihood несоответствия (предположительного) смысла переменной тому, как она используется, он подключает высшие уровни психики, чтобы рассуждать "логически", то есть анализировать код, пытаясь угадать, что имел в виду писавший, и какой смысл переменной лучше соответствует этому.
Рассуждать "логически" таким образом компьютеры лишь учатся (в смысле теоретически понятно как, но вот практически увязать первый этап, с последующими -- это пока никому вроде не удавалось), но с первым этапом они вполне справляются. Примерно с 90-х годов, после выхода "Probabilistic Reasoning in Intelligent Systems" в 1988. А с первой половины нулевых, когда deep-learning начал работать на практике, то и второй подход к реализации этого первого этапа образовался.
> в текущей версии (7.80) данное поле определено как enum, поэтому теперь такая ситуация исключена.
Нет, не исключена. В C enum может содержать _любое_ значение. C не даёт на этот счёт никаких гарантий. С точки зрения C enum -- это такой целочисленный тип, который можно молча преобразовать к другому целочисленному типу, посредством тупого копирования, может быть с обрезанием старших байтов, или с заполнением их нулями. Другое дело, что использование enum'а даёт свидетельство о намерениях программиста, что статический анализатор может использовать.
Исключена -- это когда компилятор тебе запрещает в enum записывать значения, про которые он не может доказать, что они попадают в список значений этого enum'а.
по стандарту ложное значение 0, истинное не 0.
> по стандарту ложное значение 0, истинное не 0.И что? Глянь:
struct MyStruct {
int my_flag: 1;
}int main() {
struct MyStruct var;
var.my_flag = 2;
if(var.my_flag) {
printf("yes\n");
} else {
printf("no\n");
}
return 0;
}Как ты думаешь, что оно напишет: "yes" или "no"? А теперь ещё один релевантный факт: адреса как правило выравнивают, и поэтому любой адрес, с огромной вероятностью будет иметь последним битом 0 (со вполне серьёзной вероятностью даже три последних бита будут нулями), и если ты из указателя сделаешь bool, то ты рискуешь нарваться на ровно ту же самую проблему. Даже если ты указатель положишь в полноценный int, то есть (практически нулевая, но всё же) вероятность получить 0 в результате на 64 битной системе.
Сишному стандарту нельзя доверять, он намеренно написан так, чтобы раскладывать на пути у нубов грабли (а если серьёзно, то в данном случае, истиной считается всё, кроме нуля по одной простой причине: Ритчи не знал, что ещё можно сделать, если тупой программист сунет в if не ноль -- не панику же выкидывать, так? А до обработки исключений они не доросли ещё тогда.). В C bool должна быть 0 для false, и 1 для true. Плюнь в лицо любому, кто скажет иначе. Все сколь-нибудь вменяемые проекты на C следят за тем, чтобы плевать в лицо тем, кто верит стандарту в отношении bool.
>> по стандарту ложное значение 0, истинное не 0.
> И что?Он забыл процитировать стандарт.
> В C bool должна быть 0 для false, и 1 для true.
Так и есть. Из N1570:
6.2.5 Types
2 An object declared as type _Bool is large enough to store the values 0 and 1.6.3.1.2 Boolean type
1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.
>Так и есть. Из N1570:строгое значение, и что по вашему должен делать компилятор когда bool сравнивается с 2-ой?
зачем анализатор должен об этом говорить если компилятор должен выдавать ошибку о несоответсвии типов? Делает он это?
>>Так и есть. Из N1570:
> строгое значение, и что по вашему должен делать компилятор когда bool сравнивается
> с 2-ой?По-моему, меня пытаются убедить, что я должен за кого-то прочитать integer promotion rules.
> зачем анализатор должен об этом говорить если компилятор должен выдавать ошибку о
> несоответсвии типов? Делает он это?Это он ведущему программисту Rosa Tresh должен, у которого типизация в Си строгая.
> По-моему, меня пытаются убедить, что я должен за кого-то прочитать integer promotion
> rules.ясно, все неявное становится явным
> Это он ведущему программисту Rosa Tresh должен, у которого типизация в Си
> строгая.ну раз не строгая, то зачем сравнение bool с 2-ой должно считаться ошибкой? даже компилятору чихать на это, а ваш анализатор втирает про ошибку.
Да мне пофик на анализатор, кто-то наврал про стандарт, это недоразумение я и исправил.
> Да мне пофик на анализатор, кто-то наврал про стандарт, это недоразумение я
> и исправил.почему это наврал?
он написал "по стандарту ложное значение 0, истинное не 0."
а вы привели цитату из стандарта
"When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1."
разве не одно и тоже написано?
>> Да мне пофик на анализатор, кто-то наврал про стандарт, это недоразумение я
>> и исправил.
> почему это наврал?Вероятно, потому что не читал стандарт.
> он написал "по стандарту ложное значение 0, истинное не 0."
> а вы привели цитату из стандарта
> "When any scalar value is converted to _Bool, the result is 0
> if the value compares equal to 0; otherwise, the result is
> 1."
> разве не одно и тоже написано?Очевидно, "не 0" и 1 это не одно и то же, как и "скалярное" и "булево".
> Очевидно, "не 0" и 1 это не одно и то же, как
> и "скалярное" и "булево".очевидно у вас с англ проблемы
> я не могу найти в стандарте "ложное значение 0, истинное не 0"
> и поэтому проецирую.Не волнуйтесь, ничего страшного. Я тоже не нашёл. Да и зачем? Бремя доказательства наличия в стандарте такого утверждения лежит на заявителе.
> Я тоже не нашёл.а if () {} что делает? любое не нулевое значение - истина.
>> Я тоже не нашёл.
> а if () {} что делает?Для поиска ответа надо всего лишь открыть стандарт и прочитать пункт The if statement.
> любое не нулевое значение - истина.
Многократное повторения мантр никоим образом не сказывается на содержимом стандарта. Я только что проверил, оно осталось без изменений.
>Многократное повторения мантрсмотрим в книгу видим фигу, ясно
> смотрим в книгу видим фигуА я всё думаю, что же Вы там такое видите, что процитировать стесняетесь.
6.3.1.2 Boolean type
1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.и собственно гугл перевод
6.3.1.2 Логический тип
1 Когда любое скалярное значение преобразуется в _Bool, результат равен 0, если значение сравнивается с 0; в противном случае результат равен 1.
> 6.3.1.2 Boolean type
> 1 When any scalar value is converted to _Bool, the result is
> 0 if the value compares equal to 0; otherwise, the result
> is 1.
> и собственно гугл перевод
> 6.3.1.2 Логический тип
> 1 Когда любое скалярное значение преобразуется в _Bool, результат равен 0, если
> значение сравнивается с 0; в противном случае результат равен 1.Напоминаю, что обещали найти "истинное не 0". -1 это не 0. 2 это не 0. Это сложно понять?
комент 3.90"по стандарту ложное значение 0, истинное не 0."
так и есть, по стандарту любое скалярное значение которое "не ноль" - истина, то есть неявно приводится к булевому значению 1.
вопрос, и где тут "наврал" аатор сего комента?
> комент 3.90
> "по стандарту ложное значение 0, истинное не 0."
> так и естьНо никто третий день не может привести цитату, тогда как _Bool определён как 0 или 1.
> по стандарту любое скалярное значение которое "не ноль" -
> истина, то есть неявно приводится к булевому значению 1.СКАЛЯРНОЕ. ПРИВОДИТСЯ.
> вопрос, и где тут "наврал" аатор сего комента?
В формулировке.
> Но никто третий день не может привести цитату, тогда как _Bool определён
> как 0 или 1.так речь не об этом была, и никто это не оспаривал, что булевый тип есть множество из двух элементов {0 - false, 1 - true}
> СКАЛЯРНОЕ. ПРИВОДИТСЯ.
так и есть приведение скалярного к булевому типу, и в случае со статьей речь шла о сравнении булевого типа со скалярным (int s->keepon), а в таком случае происходит неявное привидение типов. А что нам говорит стандарт при таком неявном приведении? Ровно то, что и сказал автор комента 3.90 - "по стандарту ложное значение 0, истинное не 0."
Он не говорил, что булевый тип состоит из элемента 0 - false и всяких скаляров в значении true.
> В формулировке.
это не формулировка определения булевого типа, это формулировка правила приведения любого скалярного типа к булевому. Вы сами привели две цитаты из стандарта.
6.2.5 Types
2 An object declared as type _Bool is large enough to store the values 0 and 1.тут определяются допустимые значения булевого типа.
6.3.1.2 Boolean type
1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.а тут описывается правило приведения любого скалярного значения к булевому.
>> Но никто третий день не может привести цитату, тогда как _Bool определён
>> как 0 или 1.
> так речь не об этом былаДословно: "по стандарту ложное значение 0, истинное не 0".
Нет цитаты с определением ложного и истинных значений? Я могу её привести, но зачем мне это надо? Ищите и доказывайте сами, пора наконец уже скачать стандарт и почитать, а не копировать 10й раз мои оттуда цитаты, разбавляя их демагогией.
> Нет цитаты с определением ложного и истинных значений? Я могу её привести, но зачем мне это надо?Утверждение "по стандарту ложное значение 0, истинное не 0" вы себе надомули как неверное определение булевого множества. А по сути автор говорит о правиле приведения скаляров к булевому множеству. И никто в здравом уме не будет спорить с определением булевого множества, которое состоит из двух элементов {0, 1}. То, что автор не расписал свое утверждение в 10 строк, от этого его утверждение "враньем" не стало, и собственно ему нужно было написать более в строгой форме, которая как раз и написана в стандарте. А вам нужно было просто логически уловить смысл данного утверждения, а не клеймить "враньем".
>> Нет цитаты с определением ложного и истинных значений? Я могу её привести, но зачем мне это надо?
> Утверждение "по стандарту ложное значение 0, истинное не 0"Остаётся недоказанным.
> А по сути автор говорит о
Вы автор? Или читаете его мысли?
Буквально: ложное значение 0, истинное не 0.
Стандарт действительно определяет значения (values) как истинное (true) так и ложное (false). Но некоторые знатоки стандарта не способны прочесть стандарт и найти там эти определения, потому оперируют теми цитатами, которые я им заботливо предоставил. Это становится интересно: человек не способен выполнить элементарный поиск по тексту, никогда не читал стандарт, но при этом с умным видом спорит.
> Остаётся недоказанным.определения не доказываются, а используются в доказательстве, логическом выводе.
> Вы автор? Или читаете его мысли?
вы прочли и осмыслили по своему, я прочел и осмыслил по своему, раз на то пошло, давайте спросим у автора, чья мысль близка (телепатов среди нас надеюсь нет)
> Стандарт действительно определяет значения (values) как истинное (true) так и ложное (false).
> Но некоторые знатоки стандарта не способны прочесть стандарт и найти там
> эти определения, потому оперируют теми цитатами, которые я им заботливо предоставил.не в стандарте это надо икать, а в трудах того же Буля. В моем марсианском языке 2 (false), 3 (true). И любое другое N будет приводиться к 3, если явно не есть 2.
> Это становится интересно: человек не способен выполнить элементарный поиск по тексту,
> никогда не читал стандарт, но при этом с умным видом спорит.не в стандарте языка С надо искать про булеву логику.
>>> Утверждение "по стандарту ложное значение 0, истинное не 0"
>> Остаётся недоказанным.
> определения не доказываются, а используются в доказательстве, логическом выводе.Вернул выкинутое при цитировании, что бы подмена была видна. Ищите в стандарте определение, что бы доказать утверждение, что стандарт таковое содержит.
>> Вы автор? Или читаете его мысли?
> вы прочли и осмыслили по своему, я прочел и осмыслил по своему,Я прочёл в стандарте буквальное определение, но процитировал сюда другие. И в ответ на них читаю отсебятину.
> раз на то пошло, давайте спросим у автора, чья мысль близка
> (телепатов среди нас надеюсь нет)Спросите.
>> Стандарт действительно определяет значения (values) как истинное (true) так и ложное (false).
>> Но некоторые знатоки стандарта не способны прочесть стандарт и найти там
>> эти определения, потому оперируют теми цитатами, которые я им заботливо предоставил.
> не в стандарте это надо икать"по стандарту..." - значит ищите в стандарте.
> Остаётся недоказанным.http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
Раздел 6.8.4.1 The if statement
if ( expression ) statement
if ( expression ) statement else statement6.8.4.1 The if statement
Constraints
1 The controlling expression of an if statement shall have scalar type.Semantics
2 In both forms, the first substatement is executed if the expression compares unequal to 0. In the else form, the second substatement is executed if the expression compares equal to 0. If the first substatement is reached via a label, the second substatement is not executed.
3 An else is associated with the lexically nearest preceding if that is allowed by the syntax.Сделаем акцент на "if the expression compares unequal to 0"
Если выражение скаляра НЕ РАВНО 0, то ИСТИНА, иначе - ЛОЖЬ, что равнозначно "ложное значение только 0, истинное не 0".
Ну вот, уже освоили поиск по названиям пунктов, которые я давал. Но это не про истину и ложь, а про скаляры и приведение типов. Продолжайте поиск.
>Дословно: "по стандарту ложное значение 0, истинное не 0".а если дословно, то тут можно придраться ко всему, и понимай как хочешь. Вы поняли это утверждение неверным определением чего-то, хотя в нем нет никакой "дословно" строгости (конкретики). Оно не начинается со слов "Это определение ....", там не указан "стандарт" чего, а вы в итоге отвечаете конкретными цитатами из конкретного стандарта, не зная точно о нем ли речь. Таких придирок можно написать еще кучу, только это пустая трата времени.
>>Дословно: "по стандарту ложное значение 0, истинное не 0".
> а если дословно, то тут можно придраться ко всему, и понимай как
> хочешь.Это если не читать стандарт, тогда можно. Стандарт в 100 раз более скрупулёзен чем даже Ordu.
> Вы поняли это утверждение неверным определением чего-то, хотя в
> нем нет никакой "дословно" строгости (конкретики).Я понял его так как оно могло бы быть описано в стандарте. При этом оно там там есть, но "истинное" определено иначе. Определения следуют из тех цитат, что я опубликовал ранее. Цитаты адресованы Ordu, поскольку выводы он и без стандарта сделал. Если кому-то надо буквальное определение -- то надо просто его попросить, а не устраивать споры и манипуляции.
> Это если не читать стандарт, тогда можно. Стандарт в 100 раз более
> скрупулёзен чем даже Ordu.какой стандарт? (пошли уже придирки) - вы же не телепат, с чего вы взяли что речь о стандарте С?
> Я понял его так как оно могло бы быть описано в стандарте.
Так могло быть, или все же описано?
> но "истинное" определено иначе.
В студию то самое определение.
>> Это если не читать стандарт, тогда можно. Стандарт в 100 раз более
>> скрупулёзен чем даже Ordu.
> какой стандарт? (пошли уже придирки) - вы же не телепат, с чего
> вы взяли что речь о стандарте С?Речь шла о языке Си, стандарт языка Си. Где якобы "по стандарту ложное значение 0, истинное не 0"
>> Я понял его так как оно могло бы быть описано в стандарте.
> Так могло быть, или все же описано?Естественно, стандарт определяет оба значения. Но не так, как ему приписывают некоторые.
>> но "истинное" определено иначе.
> В студию то самое определение.Пока я не вижу вежливой просьбы, Вы будете учиться искать в стандарте сами.
>Речь шла о языке Си, стандарт языка Си. Где якобы "по стандарту ложное значение 0, истинное не 0"ок, тогда выше есть выдержка определения условного оператора, там написано ровно то, что описал автор выше.
Или вы ожидаете, что там будет "истина" это тогда и только тогда, когда 1? И оппеделение понятия "истина" и "истинно" - два разных определения, ибо первое это существительное, а второе прилагательное от слова истинный. "истинно" - тогда и только тогда, когда "истина" не равна 0, ровно так описано в стандарте непосредственно в разделе оператора if, который собственно оперирует истинными значениями.
>Пока я не вижу вежливой просьбы
на этом можем и закончить разговор, сами знаете с кого ничего не спрашивают.
>>Речь шла о языке Си, стандарт языка Си. Где якобы "по стандарту ложное значение 0, истинное не 0"
> ок, тогда выше есть выдержка определения условного оператора, там написано ровно то,
> что описал автор выше.Не надоело? Там даже слов true и false нет. Я понимаю, что со стандартом надо уметь работать, но уже можно было тупо поиском по тексту найти.
>>Пока я не вижу вежливой просьбы
> на этом можем и закончить разговор, сами знаете с кого ничего не
> спрашивают.Я знаю, что бремя доказательства лежит на заявителе, но некоторым важнее пафос, чем сохранить лицо.
>Не надоело? Там даже слов true и false нет.а что должно было быть, когда есть понятие нуля и не нуля?
>>Не надоело? Там даже слов true и false нет.
> а что должно было быть, когда есть понятие нуля и не нуля?Должно быть подтверждение заявления "по стандарту ложное значение 0, истинное не 0". А именно цитата стандарта со словами "value", "true" и "false". Что бы её найти, должен быть достаточно развит межушный ганглий. Пока ничего из вышеперечисленного не наблюдается. Даю последний шанс поискать самостоятельно.
> Должно быть подтверждение заявления "по стандарту ложное значение 0, истинное не 0".Так и написано
6.3.1.2 Boolean type
1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.
Дамы и господа, делайте ставки!В левом углу ринга непревзойдённый натягиватель смыслов, профессор болтологии, несравненный Sw00p aka Jerom! Уже неделю спит и видит в стандарте "ложное значение 0, истинное не 0".
В правом углу ринга действительная цитата стандарта языка Си:
7.18 Boolean type and values <stdbool.h>
3 The remaining three macros are suitable for use in #if preprocessing directives. They
are
true
which expands to the integer constant 1,
false
which expands to the integer constant 0 [...]Порвёт ли Sw00p aka Jerom объективную реальность как Тузик грелку?
Бокс!
> directives. They
> are
> true
> which expands to the integer constant 1,
> false
> which expands to the integer constant 0 [...]вот она истина, ну и замените 1 на 2 в своем макросе true и скормите оператору if (true)
пс: хук слева, противник потрясен но стоит на ногах, чем же он ответит.
> замените 1 на 2 в своем макросе trueУпростим:
Балабол заявил, что в стандарте "значение ... истинное не 0"
В стандарте: value ... true which expands to the integer constant 1
Следовательно, заявление балабола "в стандарте ... истинное не 0" ложно.
Предложения балабола изменить стандарт, что бы он соответствовал мнению балабола о стандарте, выглядит странно. Как раз потому что мнения балабола и стандарта расходятся, одно является балабольством, а второе -- стандартом.
> Балабол заявил, что в стандарте "значение ... истинное не 0"
> В стандарте: value ... true which expands to the integer constant 1повторяю еще раз, "истина" (как хранимое значение) не равно "истинное" (сравниваемое значение)
и в операторе if "истинное" это тогда когда сравнивается со значением не 0.
еще раз вопрос, заменив значение вашей "истины" в макросе на 2, от этого if (true) будет не истинным? А про если заменить false на 2 я промолчу.
> Предложения балабола изменить стандарт, что бы он соответствовал мнению балабола о стандарте,
> выглядит странно. Как раз потому что мнения балабола и стандарта расходятся,
> одно является балабольством, а второе -- стандартом.ничего в стандарте менять не нужно, вам просто нужно изучить русский и англ языки.
Заявление балабола: "по стандарту ... значение ... истинное не 0"Содержимое стандарта 7.18/3: "value ... true ... 1"
Всё сходится буквально, кроме "не 0" и "1".
Продолжаем наблюдать борьбу балабола с объективной реальностью. Да, тяжело остановиться, после недели упорствований.
> Заявление балабола: "по стандарту ... значение ... истинное не 0"да именно "истинное", а не "истина"
> Содержимое стандарта 7.18/3: "value ... true ... 1"
это содержимое макроса "истина", а "истинное" значение.
> Всё сходится буквально, кроме "не 0" и "1".
не 0, значить "истинно".
> Продолжаем наблюдать борьбу балабола с объективной реальностью. Да, тяжело остановиться,
> после недели упорствований.разницу между "истина" и "истинное" не видим, учите русский язык.
пс: можете больше не повторять свои коменты, ответ будет таким же.
Заявление балабола: "по стандарту ... значение ... истинное не 0"Содержимое стандарта 7.18/3: "value ... true ... 1"
Перестать быть балаболом очень просто. Необходимо и достаточно начать говорить правду. Что-то вроде: по стандарту значение истинное 1, а не "не 0". Что же мешает?
>> Содержимое стандарта 7.18/3: "value ... true ... 1"
> это содержимое макроса "истина", а "истинное" значение.Балабол не знает английский? Истина это truth. Но это слишком просто. Что-то ещё мешает балаболу. ;)
> не 0, значить "истинно".
Да он ещё и русский не знает. Но и это ещё не всё. ;)
продолжайте в том же духе, ниже копипаста комента
Что же заставило Sw00p aka Jerom, который впервые увидел выдержки из стандарта неделю назад, всё это время отрицать объективную реальность? Сможет ли балабол объяснить свои действия, или сольётся?
> неделю назад, всё это время отрицать объективную реальность?вы уже азбуку повторили?
Могу повторить последний фокус. Есть ещё пара лишних недель?
> Могу повторить последний фокус. Есть ещё пара лишних недель?продолжайте, флаг вам в руки
Хорошо. Осталось уточнить один момент. У тебя уже было такое, что администратор удалил множество твоих сообщений с матом? Или это кто-то другой за тебя постарался?
> Хорошо. Осталось уточнить один момент. У тебя уже было такое, что администратор
> удалил множество твоих сообщений с матом? Или это кто-то другой за
> тебя постарался?а с коих пор мат не должен пресекаться модераторами? с моей стороны мат только в ответ может быть, и то с целью привлечь внимания модератора, зная что он тем самым удалит всю ветку, хотя можно и проигнорить.
>> Хорошо. Осталось уточнить один момент. У тебя уже было такое, что администратор
>> удалил множество твоих сообщений с матом? Или это кто-то другой за
>> тебя постарался?
> а с коих пор мат не должен пресекаться модераторами?Значит это ты матерился.
> с моей стороны
> мат только в ответ может бытьВот отрицающему текст стандарта балаболу я обязательно поверю.
> и то с целью привлечь
> внимания модератора, зная что он тем самым удалит всю ветку, хотя
> можно и проигнорить.В тот раз тебе нажали на больное место и тебя прорвало.
> Значит это ты матерился.только щас дошло?
> Вот отрицающему текст стандарта балаболу я обязательно поверю.
наивный
> В тот раз тебе нажали на больное место и тебя прорвало.
эт на какое такое место? чтобы заткнуть человека, который оскорбляет в ынтернете, достаточно отправить его обратно из мамкиной утробы в папкин детородный орган, 2 литра пива свое дело сделало.
пс: и вам советую никого не оскорблять, кто знает, на что способно два литра водки.
Ой, ой, полегче на поворотах с нотациями и попыткой списать дефекацию ганглия на алкогольное опьянение. Всё есть в истории https://opennet.ru/51523-llvmКогда душка хватит от своего имени написать, тогда и поговорим.
Профессор нашёлся. Тьфу. Иди в подворотне языком шебурши про своих родителей.
> var.my_flag = 2;
> if(var.my_flag) {если ты проверяешь значение как if(x){ ... }, значит ты проверяешь его на "не ноль".
напр., if (ptr) { *ptr = VAL; } -- это указатель;на ноль или NULL ты его проверяешь как if (!ptr) {...}.
таким образом проверяются только целочисленные значения и указатели.
значения с плавающей точкой никогда так не проверяются, потому что машинный ноль -- не ноль.
все действительные значения проверяются операторами сравнения.
всегда.
> var.my_flag = 2;эта строка сразу выглядит ошибкой.
потому что название my_flag подразумевает ноль и не-ноль, причём не-ноль в сях обычно пишется 1.
другие ненулевые значения собьют с толку программистов, которые будут работать с кодом.
поэтому не-ноль -- это всегда 1.если же ты присваиваешь значению 2, значит ты не считаешь значение булевым.
(и ты не считаешь его действительным. чтобы присвоить действительное значение, писать надо с десятичной точкой x = 2.0, x = 0.0 или x = .0).если ты всё-таки хочешь использовать его как флаг, но при этом он обязательно должен уметь содержать разные ненулевые значения, то тебе следует оставить комментарий с пояснением в месте определения поля.
сишный стандарт -- он для людей, занимающихся разработкой системного или компактного ПО.
ты же стараешься изготовить некий newspeak (известный также как "новояз"), который лишит людей возможности делать ошибки и писать неправильные вещи, так что любой дурак сможет написать программу любой сложности.
все начинающие этим страдают.
поэтому правило: "создай систему, которой сможет пользоваться даже дурак, и только дурак захочет ею пользоваться" (с).тебе надо заняться друими вещами, вроде того же раста, предназначенного не столько для программистов, сколько для кодеров, чья работа -- без особых раздумий кодировать алгоритмы, спускаемые сениорами сверху.
>сишный стандарт -- он для людей, занимающихся разработкой системного или компактного ПО.Да вы издеваетесь?
Вы сами только что простыню накатали о такой простой и одназначной вещи как булева переменная.
Каким образом ЭТО для людей?Отсутствие системы типов как таковой это не для людей.
И да, код с такими чудесами ниразу не переносимый и не кроссплатформенный.
Анон все правильно говорит, ну всмысле про сравнение на неноль. дальше читать лень. Кто не понимает сей - начинает толкать ахинею про стандарты и бульёны
Простыня имеет отношение не к "компактным программам на C",
а к непонятливости некоторых комментаторов.Путающих к тому же предмет рассуждения дважды в пяти строках человечьего текста.
Компилятор бы вас не понял.
> Каким образом ЭТО для людей?Поинтересуйтесь на kernel.org.
> И да, код с такими чудесами ниразу не переносимый и не кроссплатформенный.Не поверите, но только одной из задач C была переносимость кода первых UNIX на разные платформы, с совместимостью которых в 70-ых были большие проблемы.
Также можете поинтерсоваться у любителей играть с ардуиной или писать для андройдов.
>если же ты присваиваешь значению 2, значит ты не считаешь значение булевым.значимость (значение) всегда предшествует истинности, машина ничего не знает об истинности, она работает со значениями. Истинность (какое из значений считать истиной) подразумевает человек,
2 - истина, 3 - инверсия (отрицание) истины (пример из марсианского языка).
Думаю, это все-таки тебе надо поразмыслить вот над чем. Программирование чего-либо - это не процесс ради процесса. Программированием обычно какую-то конечную цель пытаются достичь. И если на языке А это делается с головой болью, бессонными ночами и нервотрепкой в попытке разобраться, где произошло некорректное приведение типов или обращение к не той области памяти, а на языке Б такие ошибки сведены к минимуму, то разумный рациональный человек выберет язык Б.
А вот неосилятор языка Б будет орать на каждом углу о своей исключительности и гениальности: ведь он может на языке А написать за неделю то, что на языке Б делается спокойно за день. Только вопли его вряд ли кому-то будут интересны.
Харош троллить детей.
Ты пишешь в однобитовое поле двойку, теряя все биты переполнения. Ясное дело в сравнение уйдет ноль. Об этом, кстати, компилятор прямо говорит:warning: overflow in conversion from ‘int’ to ‘signed char:1’ changes value from ‘2’ to ‘0’
--
> если ты из указателя сделаешь bool, то ты рискуешь нарваться на ровно ту же самую проблему.А ты не делай bool, потому что это не правильно. И компилятор тебе об этом тоже совершенно недвусмысленно скажет. То, что С позволяет тебе по желанию стрелять в ногу не значит что ты обязан это делать. Просто пиши if (my_pointer) и не будет никаких проблем.
_Bool x = (_Bool) &var;
warning: the address of ‘var’ will always evaluate as ‘true’
> Харош троллить детей.
> Ты пишешь в однобитовое поле двойку, теряя все биты переполнения. Ясное дело
> в сравнение уйдет ноль. Об этом, кстати, компилятор прямо говорит:
> warning: overflow in conversion from ‘int’ to ‘signed char:1’
> changes value from ‘2’ to ‘0’Ты про principle of the least surprise слышал? Так вот, этот принцип _требует_, чтобы когда я выполнял бы в коде что-нибудь типа:
my_struc.field = does_sun_shines_now();
в этой самом my_struc.field оказывалось бы булевское значение. Без переполнений и прочего. Варнинг может считаться оправданием, но если здесь функция вернёт 2 то компилятор уже не напишет никакого варнинга.
> _Bool x = (_Bool) &var;
Мне, по-моему, ни разу не приходилось сталкиваться с кодом на C, который использовал бы _Bool. 20+ лет прошло с его введения в стандарт, а никто не пользуется. Я б тоже не стал: меня эстетически возмущает _Bool. Я могу представить себе имечко похуже, которое разработчики стандартов могли бы придумать, скажем _B0_o1, но даже оно не сильно хуже чем _Bool. "Как добавить в стандарт полезную фичу так, чтобы ею никто не пользовался бы?" -- "Сделай её настолько отвратной, насколько сможешь, и вуаля".
> Ты про principle of the least surprise слышал? Так вот, этот принцип
> _требует_, чтобы когда я выполнял бы в коде что-нибудь типа:
> my_struc.field = does_sun_shines_now();
> в этой самом my_struc.field оказывалось бы булевское значение.Упомянутый принцип в данном случае запрещает сохранять результат функции _now. Си язык императивный, значит команды выполняются последовательно. К моменту проверки my_struc.field тот момент "сейчас" уже в прошлом, Солнце могло зайти.
Корректна следующая конструкция, где результат 2 вполне допустим
if ( does_sun_shines_now() ) {}
Во-первых, тебя сейчас понесло в сторону. Даже если ты прав, то ты описываешь _ещё_ один источник удивления для программиста, не отменяя при этом тот, который описываю я.Во-вторых, ...
> К моменту проверки my_struc.field тот момент "сейчас" уже в прошлом, Солнце могло зайти.
То есть gettimeofday нельзя вызывать, потому что когда мы получили результат он уже неактуален? И сохранение файла с таймстампом некорректно, потому что таймстамп уже в момент сохранения отстаёт от текущего времени, и с каждой прошедшей секундой отстаёт ещё на секунду, так?
> Корректна следующая конструкция, где результат 2 вполне допустим
Нет. Если следовать твоей логике то он тоже недопустим, поскольку возврат из функции занимает время, за которое Солнце вполне могло зайти. Корректным способом будет лишь
1. sun.lock() -- залочили солнце, и всё связанное с ним, чтобы оно не меняло своего состояния
2. вызвали does_sun_shines_now, обработали результат
3. sun.unlock()
> Во-первых, тебя сейчас понесло в сторону. Даже если ты прав, то ты
> описываешь _ещё_ один источник удивления для программиста, не отменяя при этом
> тот, который описываю я.Ну да, когда состояние где-то сохраняется - это потенциальный источник ошибок. Некоторые этому почему-то удивляются. Я правильно понимаю, что Rust в основе своей функциональный с императивными возможностями? Тогда предложенная тобой запись там м.б. корректна.
> Во-вторых, ...
>> К моменту проверки my_struc.field тот момент "сейчас" уже в прошлом, Солнце могло зайти.
> То есть gettimeofday нельзя вызывать, потому что когда мы получили результат он
> уже неактуален? И сохранение файла с таймстампом некорректно, потому что таймстамп
> уже в момент сохранения отстаёт от текущего времени, и с каждой
> прошедшей секундой отстаёт ещё на секунду, так?Всё это в ряде случаев следует учитывать, но обычно прокатывает и так, поскольку ОС не является системой реального времени. С gettimeofday() дело обстоит ещё хуже, поскольку разрешение таймера даёт погрешность.
>> Корректна следующая конструкция, где результат 2 вполне допустим
> Нет. Если следовать твоей логике то он тоже недопустим, поскольку возврат из
> функции занимает время, за которое Солнце вполне могло зайти. Корректным способом
> будет лишь
> 1. sun.lock() -- залочили солнце, и всё связанное с ним, чтобы оно
> не меняло своего состояния
> 2. вызвали does_sun_shines_now, обработали результат
> 3. sun.unlock()Этот неудобный момент обходится за счёт т.н. sequence points.
> Ну да, когда состояние где-то сохраняется - это потенциальный источник ошибок. Некоторые этому почему-то удивляются.Принцип наименьшего удивления, если присмотреться, субъективный в своей основе, в том смысле что не заглядывая в головы программистов, и в то для решения каких задач они применяют свои головы, невозможно говорить об их удивлении. В случае struc.field = some_funny_call(), программист может не помнить о том, что field занимает 1 бит. Или он может не знать об этом, потому что это поле ещё вчера утром занимало 4 байта, но вчера днём его коллега занимался оптимизациями расхода памяти, заметил, что иногда одновременно существуют миллионы инстансов этой структуры, и упаковал её покомпактнее.
А если программиста удивляет сохранение состояния, то... не, это плохо, но если есть какие-то конкретные предложения о дизайне языка, которые могут снять это удивление, то можно поговорить предметно. Если же нету, то значит с этим просто надо жить.
> Я правильно понимаю, что Rust в основе своей функциональный с императивными возможностями?
В современном программировании сложно говорить о "функциональных" и "императивных" языках, поскольку граница размыта до невозможности. Есть динозавры, типа C и Haskell, в которых всё понятно, но с современными языками классификации, созданные в прошлом тысячелетии, уже не работают. Называть раст функциональным -- то же самое, что называть его ООП языком: да, он имеет встроенные инструменты, помогающие писать в функциональном или ООП стиле, но как в нём нет законченной реализации ООП, так же в нём нет законченной реализации поддержки функциональщины.
Современные языки выбирают из всех этих парадигм то, что им нравится, реализуют это и не парятся в отношении всего остального. Код на расте часто близок к функциональному стилю, отчасти потому, что так проще писать код на расте (меньше головных болей с лайфтаймами и владением), но ровно до тех пор, пока мутабельность не станет выгодной по скорости или по расходу памяти.
Взять к примеру PathBuf:
fn make_directories(prefix: &str) -> Result<(), io::Error>
let mut pathbuf = PathBuf::new();
pathbuf.push(prefix);
pathbuf.push("bin");
// работаем с путём $prefix/bin
pathbuf.pop();
pathbuf.push("share");
// теперь с путём $prefix/share
}Это не функционально от слова совсем. Но зато не надо под каждый путь выделять свежий кусок памяти из кучи.
И на фоне этого, раст можно называть функциональным, с императивными элементами, или императивным с функциональными элементами... Как угодно, но эти названия ничего не значат. Они бессмысленны совершенно, они свидетельствуют лишь о том, что развитие языков выросло из детских штанишек классификаций языков, а взрослую классификацию ещё не сшили.
В rust'е проблема с bool'ом не существует не из-за функциональности/императивности, а потому как bool -- это тип, который занимает 1 байт и принимает одно из двух значений {true, false}. Положить его в однобитную переменную просто так не выйдет, придётся писать обвязку, которая будет конвертать true/false в бит и обратно. И указатель в bool-переменную тоже положить не удастся, потому что он указатель, а не bool. Впрочем, у указателя есть метод is_null(), который недеструктивно конвертает указатель в этот самый bool. Короче эти проблемы решаются строгостью типизации.
А с sun'ом будет так, как его API скажет. Скажет API, что надо залочить sun, чтобы добраться до метода does_sun_shines_now, значит ты не сможешь вызвать этот метод, не залочив sun. И это можно сделать через лямбду, но можно и так -- запросив объект соответствующий залоченному Солнцу, и работая с ним с императивном стиле. Но это будет зависеть от API: как его разработчик решит делать, так и будет.
> Взять к примеру PathBuf:
> fn make_directories(prefix: &str) -> Result<(), io::Error>
> let mut pathbuf = PathBuf::new();
> pathbuf.push(prefix);
> pathbuf.push("bin");
> // работаем с путём $prefix/bin
> pathbuf.pop();
> pathbuf.push("share");
> // теперь с путём $prefix/share
> }Вот это хороший пример.
> Это не функционально от слова совсем. Но зато не надо под каждый
> путь выделять свежий кусок памяти из кучи.Это можно очень похоже написать на языке OCaml, который несомненно функциональный.
Если не вдаваться в дебри функций как first-class citizen, которые мало кому (включая меня) понятны, то:
1. признак императивности - наличие оператора, который даёт команду "верни результат". В Си это return.
2. признак функциональности - отсутствие такого оператора, как в функции с урока математики f(x) = 5x (и это понятнее людям без профдеформации).Насколько я вижу, у приведённой функции есть результат, таким образом этот код функциональный, но функция с побочным эффектом.
> И на фоне этого, раст можно называть функциональным, с императивными элементами, или
> императивным с функциональными элементами... Как угодно, но эти названия ничего не
> значат.Это в теории. На практике кто-то привык писать на императивном языке, ему говорят: "посмотри, вот замена, будет меньше ошибок". Человек смотрит, увиденное в шаблон не укладывается и возникает реакция "да нафик мне эти проверки от переполнения буфера". При этом например мне понятно, что чистые функции позволяют избежать более серьёзных проблем.
> Они бессмысленны совершенно, они свидетельствуют лишь о том, что развитие
> языков выросло из детских штанишек классификаций языков, а взрослую классификацию ещё
> не сшили.По-моему классификация по признаку "более лучший Х" это вообще уровень пелёнок, скатывающий обсуждения к срачам и синтаксису.
Не смешивай буль и бит. Это разные сущности.А второе элементарно решается с помощью #define bool _Bool или даже typedef _Bool bool;
> по стандарту ложное значение 0, истинное не 0.Почему-то многие это обстоятельство упускают из вида
Основные философские положения классического "C":
1. Всё - есть int ( арифметика с указателями );
2. Всё, отличное от лжи, - истина ( TRUE != 0 );
3. Инициализация переменных в зоне ответственности программиста.В совокупности с коротким методом вычисления логических выражений позволяет писать лаконичный и безопасный код:
char * pStr = NULL;
// < ... >
// исключается раскрытие и проверка *pStr, если pStr == NULL ( pStr == FALSE )
if ( pStr && *pStr )
{
// что-то делаем, если длина строки больше 0 ( строка не равна "" )
}Ну, и классический пример - безопасное копирование одной строки в другую без затрат на проверку указателей и размерностей массивов.
#include <stdio.h>int main()
{
char pSrc[] = "Hello world!";
char pDst[ sizeof pSrc ];
char *ps = pSrc;
char *pd = pDst;while ( *pd++ = *ps++ );
puts( pDst );
return 0;
}
> Ну, и классический пример - безопасное копирование одной строки в другуютолько в хеловорлде оно безопасно
> только в хеловорлде оно безопасноЭмоциональное замечание - читаем бездоказательное замечание.
:-)
Ну вообще там два копирования, следующий вариант скомпилируется в ряде случаев 1 в 1 с исходным
int main()
{
char pSrc[] = "Hello world!";
char pDst[] = "Hello world!";puts( pDst );
return 0;
}
> Ну вообще там два копирования, следующий вариант скомпилируется в ряде случаев 1 в 1 с исходнымВ исходном примере Одно копирование и Одна инициализация
Пожалуйста, слегка модифицированный код, где Одно копирование и Две инициализации, остальной код без изменений.
int main()
{
char pSrc[] = "Hello world!";
char pDst[ sizeof pSrc ] = { 0 };
char *ps = pSrc;
char *pd = pDst;while ( *pd++ = *ps++ );
puts( pDst );
return 0;
}P.S>
Согласен, все три примера ( исходный, модифицированный и Ваш ) выводят идентичный результат на консоль.Но, в Вашем примере нет показательной арифметики с указателями и границами массивов.
Это путает неофитов, слабо знакомых с основами "C". Оно Вам надо?
>> Ну вообще там два копирования, следующий вариант скомпилируется в ряде случаев 1 в 1 с исходным
> В исходном примере Одно копирование и Одна инициализацияА char *ps = pSrc; не инициализация? Копирование как таковое вроде в Си не определено. Я имел ввиду, что char pSrc[] имеет automatic storage duration, стало быть инициализируется посредством копирования данных. Чего можно было бы избежать.
> стало быть инициализируется посредством копирования данных. Чего можно было бы избежать.Общее != частное.
Физика изучает "идеальный газ", представляемый бесконечно малыми и абсолютно упругими шариками. Все знают, что в натуральный газ устроен иначе. Однако, инженеры двигают прогресс, полагаясь на математические модели, основанные на понятии "идеального газа".
В выражении "показательный пример" ключевое слово "показательный", что допускает некоторое затенение частностей в угоду повышения ясности главной сути примера. Ибо, "детская болезнь" неофита - слабое различие общего и частного.
В последнем оскорбительного нет. "Детская болезнь" неофита сама проходит с опытом. Опытный программист характеризуется умением разделять общее и частное. Зачем тогда нам требовать от ледокола ровной кромки льда?
Я не понял, при чём тут газ и лёд, и когда проходят болезни неофитов. Вон в соседней ветке (после #88) "ведущий разработчик" операционной системы плавает в теме storage duration.
> Я не понял, при чём тут газ и лёд, и когда проходят болезни неофитов.Просто хочется избежать деструктивного перехода на личности, что отвлекает сути дискуссии. Потому забавные примеры и ассоциативные образы.
:-)
Так вот общий случай - это работа с памятью. Частный случай - копирование. Перед тем как что-то куда-то копировать, хорошо бы понимать, какие бывают типы storage.
> позволяет писать лаконичный и безопасный код:"Халва, халва, халва, ... хм, чей-то во рту все еще не сладко - наверное недостаточно усердно повторял".
> Ну, и классический пример - безопасное копирование одной строки в другую без
> затрат на проверку указателей и размерностей массивов.
> #include <stdio.h>ЧСХ - "безопасТно" оно только в таком вот хелловроте,
а в реальности, отсутсвие размерности не позволит компилятору ускорить копирование в несколько раз векторизацией. Зато сэкономили "на спичках"^W проверку - да, это классический пример.
> а в реальности, отсутсвие размерности не позволит компилятору ускорить копирование в несколько раз векторизаЧто ты такое несешь ?! O_O
>> а в реальности, отсутствие размерности не позволит компилятору ускорить копирование в несколько раз векториза
> Что ты такое несешь ?! O_OЗачем ты лезешь в обсуждение, не зная основ?
movaps xmm0, xmmword ptr [rip + .L__const.main.pSrc+16]
movaps xmmword ptr [rbp - 32], xmm0
movaps xmm0, xmmword ptr [rip + .L__const.main.pSrc]
movaps xmmword ptr [rbp - 48], xmm0
vs.
.L2:
movzx edx, BYTE PTR [rsi+rax]
mov BYTE PTR [rcx+rax], dl
add rax, 1
test dl, dl
jne .L2
>> позволяет писать лаконичный и безопасный код:
> "Халва, халва, халва, ... хм, чей-то во рту все еще не сладко
> - наверное недостаточно усердно повторял".Иногда лучше реально жевать, чем об этом говорить, когда нечего сказать.
Вероятно, дело в другом:
Джуниоры выбирают сладкий смузи. Однако, здесь для тех, кто уже предпочитает виски со льдом в ущерб приторной содовой.> а в реальности, отсутсвие размерности не позволит компилятору ускорить копирование в несколько
> раз векторизацией.В реальности будет по-взрослому на быстрых функциях memcpy, strcpy и т.п.
Прошу заметить, что понятия "лаконичность" и "безопасность" относятся к стилю кодирования программ, исключая отдельные операторы или функции.
Наивно полагаясь на оптимизацию компилятора, джуниор просто перекладывает свою ответственность на других программистов, создавших компилятор.
Но и другие программисты ошибаются. Как следствие, тратим время на обход ошибок компилятора, что из серии "смотрю и не вижу", когда проверенный годами код, вдруг, перестаёт работать.
Эффективность локализации большинства ошибок пропорциональна величине исходного кода в собственной зоне разумного контроля.
> Иногда лучше реально жевать, чемчем сначала приводить "пример - безопасТное копирование строки", а затем придумывать отмазки ...
> Джуниоры выбирают сладкий смузи
> виски со льдом в ущерб приторной содовой.
> В реальности будет по-взрослому на быстрых функциях memcpy, strcpy и т.п.
> Прошу заметить, что понятия "лаконичность" и "безопасность" относятся к стилю кодирования
> программ, исключая отдельные операторы или функции.
> Наивно полагаясь на оптимизацию компилятора, джуниор просто перекладывает свою ответственность
> на других программистов, создавших компилятор.То, что ты очередной опеннетный теоретик-балабол, стало понятно еще из предыдущего примера, не нужно подтверждать это почетное звание еще раз ...
> То, что ты очередной опеннетный теоретик-балабол, стало понятно еще из предыдущего примера,
> не нужно подтверждать это почетное звание еще раз ...Юпитер, ты злишься, а значит ты не прав.
:-)
>> по стандарту ложное значение 0, истинное не 0.
> Почему-то многие это обстоятельство упускают из видаПотому что такого обстоятельства нет. На уровне АЛУ (процессора) есть флаги (нуля, переноса), они принимают два значения: 0 или 1. Из чего и следуют требования стандарта к типу _Bool и вольная интерпретация "истинное не 0" (т.е. человек интуитивно представляет себе результат сравнения достаточно хорошо для многих случаев, но в железе всё малость иначе).
> Основные философские положения классического "C":
> 1. Всё - есть int ( арифметика с указателями );
> 2. Всё, отличное от лжи, - истина ( TRUE != 0 );На уровне железа результаты команд сравнения не хранятся в регистрах общего назначения, соответственно не имеют тип int. Современный стандарт Си абстрагируется от флагов, но определяет результат конверсии целого в тип _Bool как эквивалент Zero Flag. А в "классическом Си" никакого TRUE не было.
> А в "классическом Си" никакого TRUE не было.Согласен, ибо "всё есть int", включая указатели. :-)
> if ( pStr && *pStr )За венгерскую нотацию полагается стерилизация, чтобы избежать распространения вредоносных мутаций ДНК.
> За венгерскую нотацию полагается стерилизация, чтобы избежать распространения вредоносных мутаций ДНК.как, по-вашему, правильнее:
if (the_pointer_to_the_string_with_our_QR_code_data && *the_pointer_to_the_string_with_our_QR_code_data) ...
или
// тут мы проверяем указатель на строку, в которой хранятся данные QR-кода
if (p && *p)?
и чем вам не угодил лаконичный pStr?
мешают вашим алгоритмам вычислять смысл содержимого?
>> За венгерскую нотацию полагается стерилизация, чтобы избежать распространения вредоносных мутаций ДНК.
> как, по-вашему, правильнее:
> if (the_pointer_to_the_string_with_our_QR_code_data && *the_pointer_to_the_string_with_our_QR_code_data)
> ...Что ты бред несёшь? В C не бывает "string", только "pointer to string". Зачем вообще это писать сокращённо или развёрнуто, если это и так ясно? Назови переменную qr, и этого за глаза и за уши хватит.
> и чем вам не угодил лаконичный pStr?
Попробуй чтоль заглянуть в википедию и почитать что там написано про венгерскую нотацию. Мне кажется, там была описана история, и почему майкрософтовское использование этой, исходно неплохой идеи, вылилось в полный бред.
> Назови переменную qr, и этого за глаза и за уши хватит.Я бы за qr уши оторвал. Вместе с пальцами.
>> Назови переменную qr, и этого за глаза и за уши хватит.
> Я бы за qr уши оторвал. Вместе с пальцами.Почему? Короткое и описательное имя переменной. Вот если у тебя в коде полсотни таких переменных, то пальцы надо оторвать, но не за qr, а за полсотни переменных.
> и чем вам не угодил лаконичный pStr?Префикс p в Венгерке означает указатель, а не массив.
>> if ( pStr && *pStr )
> За венгерскую нотацию полагается стерилизация, чтобы избежать распространения вредоносных
> мутаций ДНК.О трудах агронома Трофима Лысенко слышал, но не изучал. Селекция видов - не мой бизнес.
Допуская, что разведение верблюдов - ответственное дело, буду признателен за демонстрацию влияния способа именования переменных на семантику условного оператора из примера.
:-)
> Почему бы алгоритму этот смысл не вычислить?
> Нет, не исключена. В C enum может содержать _любое_ значение.У вас нет опыта разработки.
Если разработчик может допустить "_любое_" значение в переменных, имеющих конкретный смысл и конкретный спектр принимаемых значений, то он немедленно признаётся профнепригодным и увольняется.
Потому что источником неверных и некорректных значений может быть только внешняя среда -- пользователь, некорректные настройки, etc. -- "_любое_" значение может прийти только отсюда.
Именно эти значения проверяются и исправляются, когда возможно.
Если "_любые_" значения появляются в других местах, значит программа генерирует неверные значения и работать корректно не может в принципе.Когда код ориентирован на такие значения и изо всех сил их исправляет, ошибки в нём искать крайне сложно.
Поэтому любой нормальный программист пишет код так, чтобы при малейшей ошибке, возникающей по вине внутренних переменных, программа упала сразу и со сброшенным на диск дампом.
Если вы считаете, что алгоритмы должны сами "вычислять смысл", то программирование -- это не ваша сфера.
>Поэтому любой нормальный программист пишет код так, чтобы при малейшей ошибке, возникающей по вине внутренних переменных, программа упала сразу и со сброшенным на диск дампом.
>Потому что источником неверных и некорректных значений может быть только внешняя среда -- пользователь, некорректные настройки, etc. -- "_любое_" значение может прийти только отсюда. Именно эти значения проверяются и исправляются, когда возможно.
>Если "_любые_" значения появляются в других местах, значит программа генерирует неверные значения и работать корректно не может в принципе.Так, а как ТАК пишут код чтобы программа СРАЗУ упала при ошибке во внутренних переменных без проверок этих внутренних значений на корректность?
Ну, например, если передать NULL в dest в strcpy(), то будет ошибка сегментации и работать ничего не будет.
Если наша программа такова, что dest -- при корректной работе проги -- не может быть нулевым, то некорректную работу мы увидим сразу.А если strcpy() не упадёт, а каким-то образом скажет "ОШИБКА: у вас в dest передан NULL, копирование невозможно", то возникнет сразу пачка проблем:
1. Программа продолжит работать, хотя часть её -- копирование -- не было выполнено;
смысла в таком продолжении нет, потому что данные уже некорректны.
Поэтому программа упадёт где-то в другом месте, и вам придётся основательно шерстить код, чтобы найти первопричину.И ещё худший вариант: программа не упадёт, а испортит какие-то данные или недовыполнит какого-то действия, а вы этого не заметите;
2. Если вывод будет проводиться в stderr/stdout, то тоже проблема: многие процессы не имеют потока вывода и никто сообщения не увидит.
У многих других объём вывода такой, что сообщения никто не заметит.Поэтому сценарий будет как в п.1, только уже у клиента в релизной версии (т.е. раз оно уже запускается как демон, то, скорее всего, дебаг с потоками вывода уже успешно завершён).
3. Если вывод происходит в системный лог, например, то само использование strcpy() будет тянуть за собой какой-нибудь syslog -- совершенно неадекватное усложнение при возможности просто упасть.
И это также не исключает сценария первого пункта.Поэтому программа при _внутренних_ ошибках -- зависящих _только_ (подчёркиваю подчёркиваниями) от устройства программы и ни от чего больше -- должна упасть сразу.
Это сэкономит вам время во время отладки.Если у ошибок есть зависимость от внешних данных, то такие данные обязательно проверяются, ошибки с ними обрабатываются, после чего данные можно считать внутренними.
Пример с NULL в strcpy(), ессно, слишком толстый.
Но он примерно показывает суть, когда надо падать, а когда -- проверять, корректировать или штатно завершать работу с кодом ошибки.
>Поэтому программа при _внутренних_ ошибках -- зависящих _только_ (подчёркиваю подчёркиваниями) от устройства программы и ни от чего больше -- должна упасть сразу.А она знает что она должна упасть?
> Если разработчик может допустить "_любое_" значение в переменных, имеющих конкретный смысл
> и конкретный спектр принимаемых значений, то он немедленно признаётся профнепригодным
> и увольняется.Хахахаха. Это ты так троллить пытаешься?
>> нормальный программист пишет код так, чтобы при малейшей ошибке,
>> возникающей по вине внутренних переменных, программа упала сразу и со сброшенным на диск дампом.Да ну? :)
Оглянитесь. Вне поделок на десктопе такое не допустимо. Автомобили, промышленное оборудование, авиация, и даже банальная водокачка, программ "падальщиков" не потерпят. А ещё удивитесь, что есть ГОСТ'ы, в которых написано, как правильно должно быть, в целом. Более того отдельно оговорено поведение не то что если "переменные испортились", но и если их намеренно испортили.
Логи и дампы можете делать какие угодно, но ошибки надо обрабатывать.
Ошибки и иные внештатные ситуации, обрабатываются как обычно, как реакция на изменение переменных и действия пользователя. Как обрабатываются, другой вопрос, но в любом случае, что бы минимизировать возможный ущерб, и поскорее восстановить работоспособность. То что программно нерешаемо, дополняется аппаратными средствами.
Вы путаете падения релизов с падениями некорректных сборок и падениями дебажных версий -- все эти падения сильно разные.Падения некорректных сборок неизбежны, но это может быть косяк не только разрабов, но и мантейнеров дистров (со сборкой напортачить могут и те, и другие).
Падения релизов не допустимы -- это косяк разработчиков.
А падения дебажных версий очень полезны -- это процесс разработки.
Так вот тут речь идёт именно о дебажных версиях: если проект серьёзный и ошибку не заметят ни ваши тестеры, ни контрольная группа предзаказчиков, то после поступления продакшн -- когда ошибка проявится и клиентура потеряет деньги/данные/etc. -- проблема у вас будет вне зависимости от обработки ошибки.
Поэтому правило примерно такое:0. если ошибка возникает внутри кода по вине программистов, она обрабатывается программистами на этапе отладки: отыскивается и устраняется;
1. если ошибка _может_ возникнуть вне кода -- по вине пользователей, админов, etc. -- тогда она обрабатывается: значения проверяются на допустимые, и если они не корректны, то либо выдаётся сообщение об ошибке и работа завершается, либо каким-то образом значения корректируются, либо сбрасываются на предыдущие или дефолтные;
2. если ошибки возможны из-за неверной сборки, то все требования по сборке должны быть правильно описаны, а скриптам сборки следует в должной степени проводить все нужные проверки (задача это сложная, с плясками с бубном и трёхэтажными заклинаниями, косяки тут весьма вероятны).
> Падения релизов не допустимы -- это косяк разработчиков.В идеале, но это не значит, что сбои не возникнут, не смотря на все старания и тесты.
> 1. если ошибка _может_ возникнуть вне кода -- по вине пользователей, админов,а также вредительства и непредвиденного воздействия
(даже без злого умысла пользователь способен )> .. значения проверяются на допустимые, и если они не корректны, то либо
> выдаётся сообщение об ошибке(пишем в лог, сообщаем на сервер поддержки..)
> и работа завершается,
Вам бы для промышленности что то написать, а ещё лучше для авиации. Или просто обдумать работу подобного ПО.
> либо каким-то образом значения корректируются, либо сбрасываются на предыдущие или дефолтные
Так ИНОГДА совсем нельзя. Последствия какие будут?
Операция не отработала, возник сбой, смотрим на что он влияет, оцениваем важность, смотрим сколько у нас времени на реакцию, включаем блокировки, логгируем, действуем согласно ТУ.
А важные значения при передаче еще штампами времени и валидности сопровождают, и фиктивные или устаревшие значения могут быть отброшены в другом модуле, и есть шансы получить ужасные последствия.
ещё раз: у вас речь идёт о падениях релизов;
речь про core dumped идёт в отношении дебажных версий;
> Так ИНОГДА совсем нельзя. Последствия какие будут?вот об этом была и речь:
>> Падения релизов не допустимы
> А падения дебажных версий очень полезны -- это процесс разработки.Нет.
> Так вот тут речь идёт именно о дебажных версиях: если проект серьёзный
> и ошибку не заметят ни ваши тестеры, ни контрольная группа предзаказчиков,Если проект серьезный, то программисты расставляют везде где надо assert. А где не надо - обработку неправильных значений с возвратом ошибки.
Программа НЕ ДОЛЖНА НИКОГДА падать. Это закон. Любое падение - ЧП и обязано быть рассмотрено в отдельном порядке.Сходите на полгодика в автомотив поработать, наберетесь неоценимого опыта.
>Если разработчик может допустить "_любое_" значение в переменных, имеющих конкретный смысл и конкретный спектр принимаемых значенийОх уж этот мне юношеский максимализм. Давно в профессии? Подозреваю, что год-два, не более, раз такую ахинею несёшь.
Возможность совершать ошибки заложено в нас природой. Мы - существа, живущие в вероятностном мире, и должны уметь выживать в этом мире, поэтому наше поведение тоже вероятностно. Когда человек ошибается - это нормально и точно не повод гнать из профессии.
Отцу русской демократии помогут языки со строгой типизацией. Открой для себя достижения прогресса. Си к таковым, увы, не относится. Это Г давно уже следует похоронить и забыть, как о страшном сне.
> следует похоронить и забыть, как о страшном сне.Есть такая поговорка, программист на Си может писать на Си на любом языке программирования.
Если всякий язык сводить к Си и низкоровому мышлению, там где это не неуместно, без представления работы в целом, на более высоких уровнях, то на выходе два основных варианта, или "противотанковый" стиль программирования, но медленно и с атавизмами, или тормоза, жор памяти, отладочные дампы, и немедленные падения.
Ну бывает, вроде бы и язык новый, а проблемы старые.
Если написать код на Vala, транслировать в С и скормить этому чуду - он прожует?
Если найдёт аномалии, что вы с этим будете делать?
Выкинет вала и будет писать на С.
Так сделал бы только человек с удручающе низкими когнитивными способностями.
> Если найдёт аномалии, что вы с этим будете делать?Для начала на тривиальном примере посмотрим, что будет делать с аномалиями ведущий программист Пока Линукс. Ты ведь уже изучил Си, у тебя #define больше не объявляет переменную, а типизация перестала быть строгой?
Находим вот тут https://github.com/mikhailnov/bbb-load-tester/blob/565759e69...
static int width = 160; //640; // Default for Flash
static int height = 100; //480; // Default for Flash
static char *vidsendbuf = NULL;
static int vidsendsiz = 0;static void open_vpipe()
{
///
vidsendsiz = width * height * 3;vidsendbuf = malloc( vidsendsiz );
///
}
аномалию: malloc() есть, а free() нет.Внимание, вопрос: есть ли и где ошибка?
Преодолеет ли автономный разработчик необходимый для системного программирования минимум, или какой-то чайник расчехлит в два счёта его "хорошие познания" (ц)?
В чем прикол ? Один буфер на весь запуск или что-то не так ?
Прикол в том, что код написал "ведущий программист", как заявляет его работодатель. Значит он сам может ответить на достаточно простой вопрос, надо немножко подождать. В крайнем случае кого-то спросит. Они же как бэ разрабатывают операционную систему, а не тупо пилят? ;)
> Прикол в том, что код написалНет. Смотри историю коммитов: https://github.com/mikhailnov/bbb-load-tester/commits/49d172...
В первом коммите есть ссылка на источник.> "ведущий программист", как заявляет его работодатель.
Это где такое написано? Вот чтоб прям программист и прям ведущий.
> Внимание, вопрос: есть ли и где ошибка?
Там open_vpipe() вызывается один раз и из main(), free() перед завершением программы смысла иметь не будет.
>> Прикол в том, что код написал
> Нет. Смотри историю коммитов: https://github.com/mikhailnov/bbb-load-tester/commits/49d172...
> В первом коммите есть ссылка на источник.А, ну да. RPM-разработчики не отвечают за код под которым подписываются.
>> "ведущий программист", как заявляет его работодатель.
> Это где такое написано? Вот чтоб прям программист и прям ведущий.На сайте шаражки. "В первый день конференции Михаил Новосёлов, один из ведущих разработчиков компании, выступил с докладом..."
>> Внимание, вопрос: есть ли и где ошибка?
> Там open_vpipe() вызывается один раз и из main(), free() перед завершением программы
> смысла иметь не будет.То есть ты хотел сказать, что система за тобой подчистит, т.е. в отсутствии free() ошибки нет.
В данном частном случае это верно, принимается.Я обещал расчехление в два счёта, это был счёт "раз". Вопрос "есть ли и где ошибка?" в силе. Поинтересуйся у остальных ведущих разработчиков.
"один из ведущих разработчиков" != "ведущий программист", как бы тебе ни хотелось натянуть сову на глобус.
Этот код напоминает мою раннюю писанину на баше: глобальные переменные, оперирование ими из отдельных функций, несамодостаточность функций, как следствие, невозможность сделать нормальные автотесты функций.
То есть найти ошибку в приведённом фрагменте из 7 строчек ты не смог. Я не считаю нужным тебе на неё указывать и вообще учить, поскольку ты за 5 лет не осилил азы Си и публично признал, что не являешься программистом. Осталось тебе приступить к сбору пакетиков в специально отведённом месте.
очевидно, что open_vpipe() используется только в этом C-файле -- это служебная внутренняя функция, её суть -- в подсчёте аргумента malloc'а из width и height, а также в понятном (разработчику) названии.результат её выполнения освобождается силами простого free(vpipe);
никаких лишних аргументов для free() считать не надо, поэтому обёртка для него не нужна;и что не так?
аа, увидел.но сначала вопрос: ёлки-палки, кто ж так код сокращает?:
> {
> ///
> vidsendsiz = width * height * 3;
>
> vidsendbuf = malloc( vidsendsiz );
> ///
> }это ж непонятно.
сокращайте многоточиями.vidsendbuf нигде не высвобождается.
open_vpipe() вызывается один раз, затем создаётся поток, который пишет буфер в v4l2sink, а в текущем потоке вызывается вечный цикл, в котором в начало буфера пишутся три байта (в зависимости от текущей секунды с пересчётом на 4) и весь буфер сдвигается на три байта влево.выход из программы происходит из второго потока в случае, если невозможна запись в v4l2sink.
странностей тут вижу две:
1. выхода из первого потока не вижу, поэтому close() не должен бы выполниться, поэтому дескриптор v4l2sink должен быть закрыт системой;
2. высвобождения буфера не происходит, поэтому он также должен быть закрыт системой;если полагаться на систему и не писать free(...), то и close() не нужен;
а если есть close(), который не выполняется, то вроде как и free() нужен, хотя он тоже не выполнится.
нареканий к сям тут не должно быть.
надо у программиста интересоваться, что он сказать хотел и почему выхода нет.
Про отсутствие free() я явно написал и лишнее не цитировал, поскольку вопрос касается только работы с памятью (и на мелочи вроде int для размера закрываем глаза). Программист операционных систем ответил в #126, что система за ним подчистит, а код вообще писал не он. :) То что Вы копали глубже и нашли close() лишь усугубляет ситуацию.
В итоге "ведущий разработчик" публично признал в #178, что он не программист. Вопрос "зачем там вообще allocated storage" снят. :)
работает без сети? база уже входит в поставку?
Рабтает. База как и раньше скачивается отдельно, три вида: Small, Medium, Large.
ага, прочёл уже. https://github.com/IntelLabs/control-flagнужно попробовать. надеюсь не будет тонны варнингов на отсутствие скобок в & ^ |
попробовал medium. гиг в оперативке, на час - 10к строк кода/40 файлов. ничего не нашло. слабенький компьютер, маленький проект.
А знаете, какой еще инструмент может определить аномалии и непохожести кода на чужой код? Любой антиплагиат. Если у меня свой интересный стиль написания кода, это не значит, что у меня там ошибки и аномалии. cppcheck, clang-analyzer и -fsanitize всякие, если научиться ими пользоваться, дадут хорошее определение ошибок. А если еще и вспомнить великое искусство использования отладчиком, так вообще красота.
Прогнал свой хелловорлд, 5600 строк страшноватого С (главная функция одна занимает 2000 строк, знаю-знаю...) и т.д., достаточно хаков ибо надо быстро, а не понятно даже ребенку.Нашло чуть более 400 "Expression" вида "if (d < 0) {" и т.д., причем все "Expression is Okay".
Ничего не понял, все закрыл.
Ты Си плюс-плюсник, другого оттебя и не ожидаешь. Любой чистосишник знает, что при превышении количества строк выше ста, надо код выносить на новый файл. Тебя плюсовика этому видимо не учили.И не позорь сишный стан.
Плюсплюсник не станет городить метод из 2000 строк.
> Плюсплюсник не станет городить метод из 2000 строк.Именно.
И метод такой большой ради скорости - это реализация виртуальной машины с большим свичом.
Разбиение на отдельные функции приводит к усложнению поддержки и меньшей читабельности.Но это все офтопик. А топик в том, что этот инструмент в таком говнокоде (с точки зрения общепринятых практик) не нашел проблем.
>Разбиение на отдельные функции приводит к усложнению поддержки и меньшей читабельности.Ты сам понимаешь какую чушь ты несёшь?
Посмотрите, к примеру, ВМ OCaml, что бы не задавать глупых вопросов.
Защищать рукожопых плохое занятие.
Анон, а что сделал ты, что бы я прислушался к твоему мнению? Задизайнил язык, который оказал влияние на индустрию, написал к нему компиляторы в машинный код и байт-код + интерпретатор? Или всего лишь сумел настроить Тор и набросил на Опеннет?
Бесполезный софт. Опеннетовские сишники пишут код без ошибок, надо просто их размножить. Это сложно, т.к. девушек здесь нет, но что поделать?
Ногебайсо, бум размножаться. Но что поделать ?