Ошибки работы с памятью в Си: Segmentation fault, Memory leak. Инициализация указателей: NULL. Проверка корректности адреса. Ответственность за освобождение памяти. Курс молодого бойца по информатике (Язык Си). cs.mipt.ru/c_intro
Спасибо! за столь огромный труд! После использования функций gets() или указателя без инициализации или массива на стеке, или гарантия доступа за границы массива (*(name - 1) и *(name+sizeof(name)+1). ) программирование на языки Си это нервный тик при объявлении объектов памяти. шаг -> расстрел.
@@garrygaller2853 какие далеко идущие выводы из ни}{✓я, однако! Больше 50 процентов действующего медицинского и, особенно, военного ПО, написано во времена, когда и Си считался слишком высокоуровневым для таких задач. И люди, пишущие подобное ПО, скорей всего пошлют вас лесом, если вы начнёте втирать им эту дичь про проблемы языка. Это все равно, что столяру вы начнёте рассказывать, какие ужасные проблемы у вот этого молотка или вот этой циркулярной пилы! Она ведь очень опасна -- можно и руку себе отрезать! Все эти современные тенденции создания языков, которые пытаются обезопасить идиота от его собственного мозга, родились из-за бума электронной и IT индустрии, в результате которого программистом быть стало тупо модно, и в программисты повалили все, кому не лень. Люди на своем-то родном языке, зачастую, мысли выражать не умеют, а лезут на ЯП выражаться и ещё других потом учить начинают.
@@user-cu9wl3dn5j Выделил память -- отдай обратно. Следи за границами. Я понимаю, что сейчас уже в микроконтроллеры джава-машину суют, но тогда, может, будем на велосипед ставить турбовентиляторный двигатель, полный комплект средств безопасности, двух пилотов (ну ладно, одного)... А потом получаем программистов, которые за деньги пишут код, но не могут даже в битовые операции -- тупо не знают, как это. (Это вот прям совсем не шутка и не преувеличение) Потому что низззяяяя! Вдруг чего-нибудь не так там сделаешь! Когда я учился, так же пугали ассемблером. Мол, там же можно прям в регистры процессора писать и память портить, как вздумается. А еще, о УЖАС!, там нужно руками контекст в стеке сохранять -- это ж сколько напартачить можно!
@@Ma_X64" И люди, пишущие подобное ПО, скорей всего пошлют вас лесом" Далеко идущее заявление. Потому что среди специалистов как раз таки есть понимание всех проблем языка и необходимости их исправлять. Так что скорей пошлют тебя, горе-оптимиста. Все остальное в твоем посте - бессмысленная дичь. Новые языки создаются потому что таково требование времени и этого нельзя избежать.
здравствуйте Тимофей! Благодарю вас за чудесный курс (стдент МГТУ). Появился вопрос про ситуацию на 12ой минуте видео. Если в цикле перевыделять память одной и той же переменной, то как ее потом освободить? Я считал, что в таком случае результат будет такой же, как у функции реаллок и у указателя будет меняться размер принадлежащего ему пространства памяти, и использование одного free будет достаточно.
Дело в том, что неважно, в какую переменную кладется результат malloc() - каждый раз выделяется новый блок памяти, и переменная "p" перезаписывается, чтобы указывать на этот новый блок. Таким образом, по завершении цикла "p" указывает на последний выделенный блок, а все блоки, выделенные до этого - потеряны - указателей на них нет.
Garbage collector жрет много ресурсов и эффективность у него не стопроцентная, всегда будет утечка, лучше один раз написать правильно на С, чем всё время коллектору анализировать код и память. Поэтому С форевер.
Вот как раз думал повторить СИ. Как раз с памятью что там. Начал с этого вопроса. И как то идея повторить СИ. Раньше мне как-то ума не хватало на программирование. То есть прошел курс, понял. Но как то сверхсложным все казалось. Так что вот теперь надо еще раз. Кстати может повторить прямо. По урокам, думаю. Это СИ. Раньше, я его 1 раз быстро минимум какой то прошел и сразу на СИ++. Трудно, страшно. Поэтому и рад был что с СИ там за уроков 7 что ли... Быстро разделался то же по видел тогда учил. Но тогда - это первый раз. Без всякой специальной подготовки. Поэтому конечно, это был АД для меня. Мой МОЗГ не был готов к такому. Но усвоить и пройти удалось. Думаю теперь еще раз! Повторить все.
Очень странно... числа Вы сравниваете с 0, хотя с ними разночтений не бывает. А вот указатели лучше таки сравнивать с константой NULL - может быть в некоторых компиляторах не совсем ожидаемая реакция на попытку неявного преобразования...
6:54 - Вы убиваете сравнение с NULL. При этом в других роликах сравниваете числа с нулем. Это не замечание, а скорее удивление. Поведение преобразование чисел к булевым однозначно: не ноль = тру, ноль = фолс Кажется, Страуструп писал о том, что поведение неявного преобразования указателей к булевому не столь однозначно... но может это на каком-нить семинаре мейл.ру или яндекса звучало... точно не скажу. ЗЫ я сам тоже в учебных примерах не сравниваю с NULL... исключительно из соображений "красоты" :))
@@shurakm Замечание вполне дельное, поскольку нужно изначально формировать правильный подход, код должен быть осмысленным и единообразным, а не просто работать, тогда это не только облегчит его чтение, понимание и отладку, но и не приведёт к непредсказуемым ошибкам при переносе на другую платформу или другой язык, где NULL вполне может быть, скажем, -1. То есть нужно "NULL" воспринимать не как "0", а как значение переменной по умолчанию, иначе вообще забыть про "NULL" и везде писать "0", но большое количество "магических чисел" в коде может угнетать и резко снизить его понятность спустя годы.
А stack overflow, buffer overflow Вы не относите к проблемам работы с памятью? Ведь большинство уязвимостей строится именно на этих ошибках. Странно, что тут ничего об этом не сказано
