Список проголосовавших за комментарий "<blockquote>Jame Bonds, мне вот интересно, то что уже прошел для того что бы начать писать на MQL5 хватит, или идти дальше не оглядываясь.</blockquote><br/> Борис Литвинов, вот-вот, оптимизм так и плещет через край! <img smile="wink"/><br/> Главный прикол здесь в том, что в MQL <a href="/r.php?u=https%3A%2F%2Fdocs.mql4.com%2Fru%2Fbasis%2Fsyntax&s=1174041204">нет адресной арифметики</a>. <img smile="biggrin"/><br/> <br/> <blockquote>А так же DDL первую в жизни свою хочу, вкрутить в квик!<br/> У меня там сейчас на qpile и lua всё</blockquote><br/> Учебник неправильный. То, что ничего не падает, это просто везёт. Вот, можно <a href="/r.php?u=https%3A%2F%2Fwww.onlinegdb.com%2FSyH1BOrz7&s=3588107154">посмотреть</a>, какой мусор печатается вместо 10, 11, 12, 10 (наверху есть зелёная кнопочка <strong>Run</strong>, а также можно нажать <strong>F9</strong>).<br/> <br/> Если бы было понимание адресной арифметики, то это было бы замечено сразу в исходном коде. Такие ошибки как раз и называют «переполнением буфера».<br/> <br/> Но это — явные ошибки. А есть ещё неявные. Вот <a href="/r.php?u=https%3A%2F%2Fwww.onlinegdb.com%2Fr1TN7CrG7&s=3726582652">эта программа</a> — неправильная. Факт того, что она печатает то, что и ожидается, означает, что нам просто везёт, потому что программа компилируется там ещё и без оптимизации. Стоит включить оптимизацию, и может произойти всё, что угодно, вплоть до падения.<br/> <br/> Кстати, <strong>f1()</strong> специально написана на голом C, а <strong>f2()</strong>, которая делает в точности то же самое, — с использованием всего лишь нескольких специфических для C++ механизмов. Они не являются необходимыми, просто напихал слегка, чтобы дать хотя бы лёгкое представление о сложности «недетского» C++. В этой функции использовано явно меньше 1% всех имеющихся механизмов C++.<br/> <br/> Именно поэтому я и предлагаю ограничиться голым C. Среди программистов-то, знающих голый C, трудно найти человека, который, хотя бы, более или менее знает C++.<br/> <br/> Язык C — относительно (относительно!) небольшой, универсальный и достаточно низкоуровневый, чтобы исподволь сформировать также дополнительное понимание, как всё работает в компе. Позволит, в числе прочего, как писать свои DLL'ки, так и использовать его потом как неплохую базу для изучения других языков, если понадобится. Ну, или почти с нулевым усилием использовать, хоть и плюясь, MQL.<br/> <br/> В приведённом примере есть выражение <strong>256u**p+++*p++</strong>. Я специально записал его без пробелов, чтобы подчеркнуть «непростоту», обычно пробелы ставят, где надо.<br/> <br/> Во-первых, как мне кажется, не каждый разберётся, что это тут такое понаписано. И буква <strong>u</strong> ещё какая-то затесалась… И, главное, это всё компилируется и работает...<br/> <br/> Расставлю скобки: <strong>256u * (*(p++)) + (*(p++))</strong>.<br/> <br/> Суффикс <strong>u</strong> означает, что константа беззнаковая. Итак, 256 умножается на значение из первой «ячейки», указатель продвигается на следующую и к этому прибавляется значение из следующей ячейки, раз указатель до этого продвинулся, и указатель продвигается ещё раз.<br/> Грубо говоря, в математическом виде это могло бы выглядеть так: <strong>sum = 256 * a[1] + a[2]</strong>.<br/> <br/> Теперь начинаются тонкости, почему программа неправильная.<br/> <br/> Во-первых, подвыражения могут вычисляться в любом порядке, то есть, сначала может быть вычислена правая часть <strong>(*(p++))</strong>, а только потом левая <strong>256u * (*(p++))</strong>. Это сделано для того, чтобы компилятор имел больше возможностей для оптимизации кода.<br/> В данном случае математический эквивалент станет таким: <strong>sum = <strong>256 * </strong>a[2] + a[1]</strong>.<br/> <br/> Потому что правое подвыражение же тоже продвигает указатель. Совершенно другой результат получается.<br/> <br/> Более того, продвигание указателей может быть отложено на самый последний момент, и тогда математический эквивалент станет ещё интереснее: <strong>sum = <strong>256 * </strong>a[1] + a[1]</strong>.<br/> <br/> Но это всё — ещё не самое страшное. Из-за этого всего просто результат был бы неправильным, и — всё. Звучит, — да, интересно. Просто неправильно вычисляется, а так — ничего страшного. <img smile="biggrin"/><br/> <br/> Но есть ещё кое-что. В этом самом выражении дважды происходит изменение одной и той же переменной (указателя <strong>p</strong>). А эта ситуация есть, так называемое, undefined behavior. <br/> Страшная штука. Она означает следующее: при исполнении данного кода может быть всё, что угодно, от нормального выполнения, до условно, форматирования жёсткого диска. На практике, всё же, всё не так страшно: не до форматирования жёсткого диска, а, «всего лишь» до падения программы.<br/> <br/> Причём, современные компиляторы при оптимизации используют этот undefined behavior в свою пользу: скорее всего, код, соответствующий этому выражению, будет просто выкинут. Причём, молча. Компилятор будет доволен: мощно соптимизировал. <img smile="biggrin"/><br/> <br/> И это всё ещё голый С, без всякого, там, C++.<br/> <br/> А теперь вопрос: даёт ли тот «учебник» с неправильной программой, в которой «нахально торчит» неоднократное переполнение буфера, а также стиль обучения «по верхушкам» понимание вот этого всего?<br/> <br/> Насколько легко «накодить» такого, вроде бы, «безупречного» кода, из-за которого программа будет падать?<br/> <br/> Каковы шансы, обучившись «по верхушкам», хотя бы понять, из-за чего всё падает или неправильно вычисляется после включения оптимизации?<br/> <br/> Надеюсь, я дал представление, насколько всё непросто, и сколько там всего. В том числе, не очевидного, тонкого и, на восприятие не программиста, мягко говоря, странного."