На Арифметике Указателей начал прикуривать. С++

Борис Литвинов, чтобы писать на mql5 указатели могут и не понадобится. К тому же в mql указатели по синтаксису и идеологии ближе к объектам C#, а не к указателям С++.
Прочтите по диагонали справку по mql, она хорошо структурирована и похожа на учебник и в бой.
А чтобы написать dll лучше иметь знания поглубже, но это зависит от того, что dll делает.

Jame Bonds, мне вот  интересно, то что уже прошел для того что бы начать писать на MQL5 хватит, или идти дальше не оглядываясь.

Борис Литвинов, вот-вот, оптимизм так и плещет через край! 
Главный прикол здесь в том, что в MQL нет адресной арифметики. 

А так же DDL первую в жизни свою хочу, вкрутить в квик!
У меня там сейчас на qpile и lua всё

Учебник неправильный. То, что ничего не падает, это просто везёт. Вот, можно посмотреть, какой мусор печатается вместо 10, 11, 12, 10 (наверху есть зелёная кнопочка Run, а также можно нажать F9).

Если бы было понимание адресной арифметики, то это было бы замечено сразу в исходном коде. Такие ошибки как раз и называют «переполнением буфера».

Но это — явные ошибки. А есть ещё неявные. Вот эта программа — неправильная. Факт того, что она печатает то, что и ожидается, означает, что нам просто везёт, потому что программа компилируется там ещё и без оптимизации. Стоит включить оптимизацию, и может произойти всё, что угодно, вплоть до падения.

Кстати, f1() специально написана на голом C, а f2(), которая делает в точности то же самое, — с использованием всего лишь нескольких специфических для C++ механизмов. Они не являются необходимыми, просто напихал слегка, чтобы дать хотя бы лёгкое представление о сложности «недетского» C++. В этой функции использовано явно меньше 1% всех имеющихся механизмов C++.

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

Язык C — относительно (относительно!) небольшой, универсальный и достаточно низкоуровневый, чтобы исподволь сформировать также дополнительное понимание, как всё работает в компе. Позволит, в числе прочего, как писать свои DLL'ки, так и использовать его потом как неплохую базу для изучения других языков, если понадобится. Ну, или почти с нулевым усилием использовать, хоть и плюясь, MQL.

В приведённом примере есть выражение 256u**p+++*p++. Я специально записал его без пробелов, чтобы подчеркнуть «непростоту», обычно пробелы ставят, где надо.

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

Расставлю скобки: 256u * (*(p++)) + (*(p++)).

Суффикс u означает, что константа беззнаковая. Итак, 256 умножается на значение из первой «ячейки», указатель продвигается на следующую и к этому прибавляется значение из следующей ячейки, раз указатель до этого продвинулся, и указатель продвигается ещё раз.
Грубо говоря, в математическом виде это могло бы выглядеть так: sum = 256 * a[1] + a[2].

Теперь начинаются тонкости, почему программа неправильная.

Во-первых, подвыражения могут вычисляться в любом порядке, то есть, сначала может быть вычислена правая часть (*(p++)), а только потом левая 256u * (*(p++)). Это сделано для того, чтобы компилятор имел больше возможностей для  оптимизации кода.
В данном случае математический эквивалент станет таким: sum = 256 * a[2] + a[1].

Потому что правое подвыражение же тоже продвигает указатель. Совершенно другой результат получается.

Более того, продвигание указателей может быть отложено на самый последний момент, и тогда математический эквивалент станет ещё интереснее: sum = 256 * a[1] + a[1].

Но это всё — ещё не самое страшное. Из-за этого всего просто результат был бы неправильным, и — всё. Звучит, — да, интересно. Просто неправильно вычисляется, а так — ничего страшного. 

Но есть ещё кое-что. В этом самом выражении дважды происходит изменение одной и той же переменной (указателя p). А эта ситуация есть, так называемое, undefined behavior.
Страшная штука. Она означает следующее: при исполнении данного кода может быть всё, что угодно, от нормального выполнения, до условно, форматирования жёсткого диска. На практике, всё же, всё не так страшно: не до форматирования жёсткого диска, а, «всего лишь» до падения программы.

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

И это всё ещё голый С, без всякого, там, C++.

А теперь вопрос: даёт ли тот «учебник» с неправильной программой, в которой «нахально торчит» неоднократное переполнение буфера, а также стиль обучения «по верхушкам» понимание вот этого всего?

Насколько легко «накодить» такого, вроде бы, «безупречного» кода, из-за которого программа будет падать?

Каковы шансы, обучившись «по верхушкам», хотя бы понять, из-за чего всё падает или неправильно вычисляется после включения оптимизации?

Надеюсь, я дал представление, насколько всё непросто, и сколько там всего. В том числе, не очевидного, тонкого и, на восприятие не программиста, мягко говоря, странного.

Eskalibur, mmap наверное =))

Eskalibur, умные указатели
https://habr.com/post/352570/

Борис Литвинов, там вообще сплошные парадоксы и прочие квантовые эффекты наблюдаются.

Например, есть некий кусок кода с временем исполнения C, условно состоящий из двух «подкусков» кода с временами исполнения A и B. После «оптимизации» второго «подкуска» его время выполнения B уменьшается. Однако, при этом, при неизменном коде первого «подкуска» его время исполнения A увеличивается, причём сильнее, чем уменьшается время исполнения второго «подкуска» B.

В результате, в выражении C = A + B, при уменьшении B сумма C увеличивается. Потому что уменьшение B само по себе вызывает ещё большее увеличение A.

Видимо, с кешами процессора это связано. Код второго «подкуска» выталкивает данные из кеша, а это чрезвычайно дорого. Одна и та же инструкция может выполняться в десятки раз дольше, если данные не в кеше. Поэтому, если выполнение кода второго «подкуска» каждый раз выталкивает данные из кеша, необходимые для первого «подкуска», то неудивительно, что первый «подкусок» начинает выполняться медленнее, несмотря на то, что его код не менялся.

Так что ассемблер — это то, куда совершенно точно соваться не следует. Разве, что для развлечения. 

Борис Литвинов, почему нет? хорошие хотелки =)
надо наверное много куда потыкаться, чтобы найти свою тропинку

tranquility, тут access violation если не повезёт

tranquility, на компиляторах Си строго действует правило — чтение слева. По крайне мере на всех по иксами.