The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск языка программирования Rust 1.38, opennews (??), 27-Сен-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


11. "Выпуск языка программирования Rust 1.38"  +7 +/–
Сообщение от someman (?), 27-Сен-19, 11:10 
Лучше начать с C. Он проще и ближе к тому как все устроено. А потом уже можно постепенно открывать для себя абстракции, которыми так переполнены плюсы. А раст наверное нужно учить, когда  тебя реально достанут сегфолты, утечки памяти, неопределенное поведение, неадекватные сообщения об ошибках. Вот тогда можно и на раст посмотреть, чобы было с чем сравнивать)
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

19. "Выпуск языка программирования Rust 1.38"  –1 +/–
Сообщение от eganruemail (?), 27-Сен-19, 11:39 
[i]А раст наверное нужно учить, когда  тебя реально достанут сегфолты, утечки памяти, неопределенное поведение, неадекватные сообщения об ошибках.[/i] - по моему опыту чаще происходит профессиональная деформация: первое время пугает, а потом начинаешь жить с этим.

по моему опыту [i]сегфолты, утечки памяти, неопределенное поведение, неадекватные сообщения об ошибках[/i] это те проблемы, которые можно решить в относительно короткое время - хуже всего если ошибка в алгоритме.

Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск языка программирования Rust 1.38"  +3 +/–
Сообщение от Ordu (ok), 27-Сен-19, 13:13 
> по моему опыту [i]сегфолты, утечки памяти, неопределенное поведение, неадекватные сообщения об ошибках[/i] это те проблемы, которые можно решить в относительно короткое время

Ты везучий. Мне приходилось и по два дня сидеть, отлавливая причину сегфолта. Ну, то есть, разадресация NULL как причина находится легко, но если в коде при этом разадресуется указатель, который _никак_не_может_быть_NULL_!!!, то значит реальная причина сегфолта где-то в другом месте, в том коде который записал в этот указатель NULL. А это может быть, если по-хорошему, вообще любой кусок кода. Конечно, с большей вероятностью, проблема в каком-то куске кода который явно работает с этим указателем. Но это не всегда так, иногда этот кусок кода берёт другой якобы ненулевой указатель и записывает его сюда, но указатель оказывается нулевым, то есть проблема не здесь, где в указатель записывается NULL, а там откуда этот NULL пришёл. А иногда, какой-то совершенно левый код ошибается с индексом массива, вытаскивает из стека совершенно не тот указатель, который хотел, интерпретирует его как указатель на какую-то структуру, работает с ней, производит несколько рандомных изменений кучи, и так случается что сам при этом не сегфолтится и перезаписывает твой указатель нулём.

Такие штуки неплохо отлавливает valgrind, но только если он не зафлуживает при этом весь вывод руганью на libc или на ещё на какую-нибудь интересную библиотечку, которую ты подключил депендансами.

Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск языка программирования Rust 1.38"  +2 +/–
Сообщение от eganruemail (?), 27-Сен-19, 13:58 
[i]но если в коде при этом разадресуется указатель, который _никак_не_может_быть_NULL_[/i] - то можно поставить бряк на модификацию этого указателя.

[i]А это может быть, если по-хорошему, вообще любой кусок кода.[/i] - не согласен. в худшем случае это код, который пишет в память в пределах одного процесса.

[i]А иногда, какой-то совершенно левый код[/i] - если у Вас в проекте появился совершенно левый код, то это повод для беспокойства вне завимости от языка.

Ответить | Правка | Наверх | Cообщить модератору

63. "Выпуск языка программирования Rust 1.38"  +1 +/–
Сообщение от Аноним (63), 27-Сен-19, 14:47 
Вах, зачем так много пишешь?! Достаточно - УВР!!!!
Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск языка программирования Rust 1.38"  +/–
Сообщение от Ordu (ok), 27-Сен-19, 16:07 
> [i]но если в коде при этом разадресуется указатель, который _никак_не_может_быть_NULL_[/i]
> - то можно поставить бряк на модификацию этого указателя.

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

> [i]А это может быть, если по-хорошему, вообще любой кусок кода.[/i] - не
> согласен. в худшем случае это код, который пишет в память в
> пределах одного процесса.

Хорошее уточнение.

> [i]А иногда, какой-то совершенно левый код[/i] - если у Вас в проекте
> появился совершенно левый код, то это повод для беспокойства вне завимости
> от языка.

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

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

84. "Выпуск языка программирования Rust 1.38"  –1 +/–
Сообщение от eganruemail (?), 27-Сен-19, 17:07 
[i]Если ты знаешь где он находится.[/i] - после того как Вы попали в исключение, то Вам уже известно какой поток, состояние регистров и стека. Чаще прочего этого достаточно чтобы определить, где проблема.

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

[i]с точностью до точного порядка инструкций[/i] - если нужно писать с точностью до порядка инструкций, то я пишу на ассемблере.
я редко пишу на ассемблере.

[i]Слово "левый" было использовано в смысле "занимающийся чем-то иным".[/i] - я неправильно Вас понял. Предположил, что под левый код мы понимаем плохо документированный код, который попал в проект под давлением бизнеса(резко понадобилась функциональность и наскоро где-то что-то купили и вставили).

У меня наибольшие проблемы возникали когда время от времени программа неправильно работает(и никто толком ни в чем не уверен). Ничего не падает, но вроде бы иногда работает неправильно. И думай что-хочешь.

Ответить | Правка | Наверх | Cообщить модератору

128. "Выпуск языка программирования Rust 1.38"  –1 +/–
Сообщение от Ordu (ok), 27-Сен-19, 20:54 
> [i]Если ты знаешь где он находится.[/i] - после того как Вы попали
> в исключение, то Вам уже известно какой поток, состояние регистров и
> стека. Чаще прочего этого достаточно чтобы определить, где проблема.

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

> Понятное дело, что может быть код, который случайным образом портит память: но
> такой код, как правило, сам довольно быстро вызывает исключения и всё
> становится более менее понятно.
> [i]с точностью до точного порядка инструкций[/i] - если нужно писать с точностью
> до порядка инструкций, то я пишу на ассемблере.
> я редко пишу на ассемблере.

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

> У меня наибольшие проблемы возникали когда время от времени программа неправильно работает(и
> никто толком ни в чем не уверен). Ничего не падает, но
> вроде бы иногда работает неправильно. И думай что-хочешь.

Угу. Это ещё хуже, потому что нет точного критерия "программа сработала неправильно". Сегфолт по-крайней мере окончателен. Но представь себе, что какая-то часть программы иногда работает неправильно, а другая часть иногда на это неправильно реагирует сегфолтом. И при этом неправильное поведение остаётся внутри программы незамеченным, если не было сегфолта. А если при этом неправильное поведение случается при каком-нибудь очень интересном стечении обстоятельств, которое происходит с частотой 0.0001, то есть один раз из 10000. И мало того, оно зависит от чего-нибудь, что меняется от запуска к запуску -- показания часов, состояние генератора случайных чисел, скорость чтения с жёсткого диска, переключение задач в точно заданный момент, обрыв tcp-соединения между входящими килобайтами с номерами 128*k+31 и 128*k+32 для любого целого k>0, или ещё что-нибудь в этом роде.

Представь себе это. Чуешь как интересно будет отлаживать? Особенно если ты не знаешь всех этих особенностей бага до того, как начал его ловить.

Ответить | Правка | Наверх | Cообщить модератору

131. "Выпуск языка программирования Rust 1.38"  –1 +/–
Сообщение от Аноним (139), 27-Сен-19, 21:43 
то есть, тестов нет. Ни юнит, ни функциональных. Я прав?
Ответить | Правка | Наверх | Cообщить модератору

152. "Выпуск языка программирования Rust 1.38"  +/–
Сообщение от Ordu (ok), 27-Сен-19, 23:25 
> то есть, тестов нет. Ни юнит, ни функциональных. Я прав?

Тесты снижают вероятность такого, но не изничтожают её. И да, это если они есть. Тесты, например, плохо умеют в data-race'ы. Крайне плохо. Тут разве что fuzzing может помочь, и то я не знаю, насколько он может помочь: я не пробовал им искать data-race'ы.

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

Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск языка программирования Rust 1.38"  +1 +/–
Сообщение от Аноним (69), 27-Сен-19, 15:53 
> хуже всего если ошибка в алгоритме

Вроде бы язык, который от этого помогает, ещё не изобрели. Или я что-то пропустил?

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

190. "Выпуск языка программирования Rust 1.38"  +/–
Сообщение от Аноним (189), 29-Сен-19, 12:08 
Ещё хуже, если ошибка - на генном уровне, а чел в программинг попёрси, да ещё и течёт постоянно, как сучка, как только речь про плюсы заходит.
Будто бы пролистывание пары книжек по Си++ и участие (по чьей-то глупости или недосмотру) в паре Си++ проектов исправит эту ошибку генах...
Скорблю.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

37. "Выпуск языка программирования Rust 1.38"  –5 +/–
Сообщение от Аноним (37), 27-Сен-19, 13:11 
Не начинай с сей, иначе будешь потерян для общества: начнёшь переизобретать строки, списки, классы…
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру