Неравенство указателей

В прошлом разделе мы рассмотрели лишь один способ сравнения указателей — сравнение на равенство. Теперь же мы рассмотрим неравенство указателей, а именно операторы отношения: <,>, <= и >=. Я выделил неравенство в свой собственный раздел, потому что ситуация с ним в C++ гораздо сложнее, чем с проверкой на равенство. Если с равенством всё довольно просто и, в целом, соответствует нашей интуиции, то с неравенством это не так. Немного переделаем код из прошлого раздела, чтобы получить вот такой пример:

#include <stdio.h>

int main()
{
    int first = 5;
    int second = 15;
    int* firstPtr = &first;
    int* secondPtr = &first + 1;
    printf("First < second? %d\n", firstPtr < secondPtr);
    return 0;
}

Какой будет вывод? 1. Тут всё понятно и соответствует нашей интуиции. Но давайте совсем чуть-чуть изменим код:

int* firstPtr = &first;
int* secondPtr = &first + 2;

Что будет выведено после этого изменения? Неизвестно, т.к. этот код содержит неопределённое поведение (НП). Правда, тут НП даёт сам факт прибавления двойки к указателю, поэтому данный пример не очень показателен. Давайте рассмотрим другой:

int* firstPtr = &first;
int* secondPtr = &second;

А теперь какой будет вывод? Правильно, снова неизвестно. Мы уже говорили раньше, что порядок размещения объектов не специфицирован и не известно, что будет размещено раньше first или second. Т.е. логично предположить, что результат неспецифицирован, но предсказуем на конкретном компиляторе. Но на самом деле ситуация несколько сложнее. В примере выше мы имеем сравнение указателей на 2 несвязанных объекта с помощью операторов отношения, а их правила отличаются от тех, что мы рассмотрели для оператора равенства.

Для начала давайте разберёмся, что считается связанным, а что — нет. Связанными считаются члены композитных объектов (структур, классов, объединений) и массивов. Таким образом, операторы сравнения чётко определены при сравнении: составных частей композитных объектов (включая подобъекты при наследовании) и элементов массива (включая воображаемый элемент сразу за последним элементом оного). Все остальные объекты считаются несвязанными, с точки зрения операторов отношения.

Разобравшись с этим, давайте ещё раз перепишем наш пример (мы ещё с прошлым не закончили, но этот будет более наглядным):

#include <stdio.h>

int main()
{
    int first = 5;
    int second = 15;
    int* firstPtr = &first;
    int* secondPtr = &second;
    printf("First < second? %d\n", firstPtr < secondPtr);
    printf("Second < first? %d\n", firstPtr > secondPtr);
    return 0;
}

Как думаете, что должен вывести этот код? Полагаю, что правильный ответ вас удивит. Более того, правильных ответа тут 2: один для C, а другой для C++. Итак, с точки зрения C мы имеем НП, потому что сравнивать указатели на несвязанные объекты нельзя (6.5.8/p5). С другой стороны, в C++ подобное сравнение неспецифицированно: при сравнении указателей на 2 несвязанных объекта ни один из указателей не должен быть больше другого (expr.rel/p3.3), а когда ни один не больше другого, стандарт не специфицирует результат операторов отношения (expr.rel/p4). Хотя это и является разночтением, суть в обоих языках одинакова: для указателей определён лишь частичный порядок. Да, можно рассматривать под микроскопом эту разницу, а можно просто принять очевидный факт: осмысленное сравнение двух несвязанных указателей невозм��жно ни в C, ни в C++.

Но какова причина подобных ограничений? Почему нельзя было в языке сделать нормальное сравнение указателей? Полагаю, причина довольно проста: не во всех архитектурах можно провести осмысленное сравнение двух адресов в памяти. Сейчас многие привыкли к плоской модели памяти, когда адреса линейно увеличиваются от нуля до какого-нибудь числа, но так было не всегда, и неизвестно, что будет дальше. В плоской модели сравнение на больше/меньше не является проблемой, но что делать, к примеру, в сегментированной модели памяти, когда любой адрес это комбинация сегмента и адреса внутри сегмента? Как можно определить меньше или больше указатель на сегмент А со смещением М, указателя на сегмент Б со смещением К? Да, можно принять какие-то условности и произвести сравнение, но от этого подобное сравнение осмысленным не станет. Поэтому, вероятно, в таком низкоуровневом языке как C++ стандарт и не пытается навязывать спорное поведение. Тем более, что сравнение несвязанных между собой указателей для получение некого содержательного результата это, в принципе, сомнительная затея.

Вот пример, когда программист попытался использовать сравнение указателей на несвязанные объекты для сомнительной пользы: stack growth direction. Человек решил определять направление роста стека, сравнивая указатель на параметр функции с указателем на объект внутри функции. Очевидно, что эта проверка не работает по описанным нами ранее причинам. Но даже если бы ограничения на сравнение не было, подобный алгоритм изначально предполагает слишком многое: стек растёт линейно в одном направлении, параметры передаются через стек, локальные объекты выделяются на стеке и, в конце концов, стек вообще есть. Но если мы делаем столько допущений, то мы скорее всего и так знаем на какой архитектуре у нас запускается приложение, а следовательно проще посмотреть спецификацию и «зашить» это в коде.

Тем не менее на этом наше приключение с операторами отношения не заканчивается, потому что C++ имеет в стандартной библиотеке следующие функторы: std::less и std::greater (а также их X_equal собратьев). Логично предположить, что это просто обёртки над операторами отношения, которые созданы для удобства использования в стандартной библиотеке. Это так и есть, но для этих 4-х функторов есть интересная приписка (описанная в comparisons/p2). Согласно этому пункту, для всех этих функторов должна существовать специализация под указатели, и она обязана выдавать линейный порядок! Другими словами, каждый из этих функторов можно применять для сравнения любых указателей, даже несвязанных. Интересный поворот, не правда ли?

Одной рукой комитет пишет, что подобное сравнение нерегламентировано, другой — заставляет авторов стандартной библиотеки придумывать способ сравнения. Это просто блеск. Мы говорили, что осмысленное сравнение указателей получить на всех архитектурах невозможно, тогда зачем вообще подобные требования? Полагаю, что причина в контейнерах. Представьте, что у вас есть объект следующего типа: std::map<char*, SomeObject>. Т.е. ключом в нашем словаре выступает указатель. Очевидно, что часто эти указатели будут на области никак не связанные, а мы всё же хотим, чтобы код просто работал. Не могу сказать, что я постоянно встречаю подобные типы, но и редкими я их назвать не могу — это вполне обычное желание: иметь указатель ключом. Но если не иметь специального правила, которое бы позволило сравнивать несвязанные указатели, тогда реализация словаря была бы невозможной. Поэтому появление такого требования к std::less и компании вполне понятно.

Другое дело, что подобное решение является очень скользким. Предположим, что мы живём в другом мире, где много конкурирующих реализаций C++, и мы имеем целый ворох C++ компиляторов и реализаций стандартных библиотек. Одни хорошо делают компиляторы, другие делают библиотеки. И вот получается интересная история: каким образом автор библиотеки может надёжно реализовать std::less без помощи компилятора? Я, честно говоря, не представляю как это можно сделать, но можно предположить, что каким-то сложным путём это было бы достижимо. С другой стороны, разработчики компиляторов тоже не могут не понимать, что разработчики библиотек как-то должны решать эту проблему, поэтому, вероятно, они бы предоставляли средства для реализации подобного.

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

Каламбур

Начнём этот подраздел с повторения кода, который мы привели в самом начале раздела:

string versionToStr(uint32_t version)
{
    uint16_t* values = (uint16_t*)&version;
    return to_string(values[0]) + "." + to_string(values[1]);
}

Там мы указали, что в коде содержится неопределённое поведение, а затем выяснили почему: мы обращаемся к объектам uint32_t через указатель на uint16_t, что нарушает ПСС. Но загвоздка в том, что хотя я и придумал этот пример за пару минут, он не выглядит излишне натянутым. Наоборот, программисты C++ настолько привыкли играть типами, что подобный код для многих является чуть ли не повседневной практикой. Особенно подобный код характерен для различных сетевых взаимодействий и прочих вещей, которые спускаются ниже типичного пользовательского слоя (UI и тому подобного). К примеру, гипотетический программист-сетевик, при написании кода сетевого протокола, мог воспользоваться вот такой простой «болванкой» для сообщений:

struct Message
{
    int id;
    std::vector<uint8_t> payload;
};

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

auto payload = (uint16_t*)msg.payload.data();
//Дальше работаем с payload...

Этот код выглядит вполне невинным (в конце концов мы просто интерпретируем набор байт!), но мы-то уже знаем, что породили НП, и что так делать нельзя! Тем не менее подобный код содержится в массе проектов различного уровня сложности и не является чем-то необычным. Про ПСС слышало не так много людей, и в результате мы имеем кучу кода с бомбой замедленного действия: он может работать сейчас, но никто не гарантирует, что продолжит работать завтра. А отлавливать проблемы, вызванные НП, это то ещё приключение. Поэтому нужно запомнить раз и навсегда: в C++ игры с типами (type punning), через простые преобразования, весьма и весьма ограничены и, заигравшись, очень легко можно напороться на НП. Так что к любому явному преобразованию нужно подходить с умом; не лишним будет напомнить, что преобразованию в стиле C не место в C++ коде — его очень сложно отследить.

Однако, как вы могли заметить, проблема у нас именно в части интерпретации, а не в части нашей изначальной структуры. Так может можно как-то изменить процесс интерпретации, чтобы всё работало так, как нам нужно, но при этом не вызывало НП? Действительно, такой способ есть и он очень прост: используйте memcpy/memmove. Т.е. наш код должен выглядеть как-то так:

std::vector<uint16_t> payload(msg.payload.size());
std::memcpy(paload.data(), msg.payload.data(), msg.payload.size());
//Дальше работаем с payload...

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

Внимательный читатель скорее всего заметил, что по сути пример с интерпретацией через преобразование мало чем отличается от примера с копированием. Просто в первом случае идёт интерпретация исходной последовательности байт, а во втором происходит та же самая интерпретация, только копии последовательности. У многих людей резонно возникает вопрос: а почему я должен платить производительностью за какие-то непонятные ограничения? Откуда и почему эти ограничения возникли? В результате код продолжается писаться с полным игнорированием ПСС. Думаю, что можно выделить три группы кода, который нарушает данное правило:

• Старый код.

• Код, который пишут люди, не знающие об этом правиле.

• Код, который пишут люди, знающие об этом правиле, но сознательно его игнорирующие.

Интересно отметить, что в ядре Linux содержится код, который нарушает это правило. Я доподлинно не знаю, к какой конкретно группе отнести этот код, но склоняюсь к третьей: об этом известно и, насколько я знаю, с этим никто ничего делать не собирается. Более того, если вы поищите в интернете мнения касательно этого правила, то обнаружите, что лагерь его противников достаточно велик. Не думаю, что какое-то другое правило, превращающее код в НП, имеет столько сопротивления, сколько ПСС.

Разумеется, компиляторы не могли просто последовать слепо стандарту и проигнорировать огромную базу своих пользователей, которые отказываются подчиняться. В результате для clang и gcc есть следующие флаги: -fstrict-aliasing и -fno-strict-aliasing. Первая опция включается автоматически при любом уровне оптимизации, а вторая служит для того, чтобы отключить это правило на любом уровне оптимизации. Ядро Linux, как вы понимаете, собирается с -fno-strict-aliasing. Для MSVC никаких ключей нет.

Но откуда взялось это правило, почему оно появилось? Почему существует масса кода, который игнорирует это правило? Тут ответ довольно прост: оптимизация. Этому правилу уже очень много лет. Не берусь утверждать, но возможно оно было всегда; по крайней мере оно было в C++03 и C99. Просто компиляторы им не пользовались, до определённого момента. А потом всё резко изменилось. Об этом мы и продолжим разговор.

Оптимизация

Итак, как многие наверное знают, основная причина наличия многих «тёмных мест» (больше известных как НП) в стандарте C++ — оптимизация. C++ всегда позиционировался как довольно низкоуровневый язык программирования высокого уровня, поэтому очень часто его выбирают из тех соображений, что написанный на этом языке код будет выдавать максимальную производительность. Давайте рассмотрим такой простой код:

int easySum(int* in, int* out)
{
    for(int i = 0; i < 10; ++i)
        *out += *in;
    return *out;
}

Опустив опасность переполнения (ведь оно невозможно, иначе НП 😉) , что можно сказать об этом коде? Мы принимаем два указателя: один «входящий» (in), второй «исходящий» (out). Мы поочерёдно (10 раз) прибавляем к тому, на что указывает out то, на что указывает in. Затем мы возвращаем значение по указателю out.

Функция очень простая, так что давайте наденем очки компилятора и посмотрим на этот код его глазами (используя вольную терминологию, а не строгий язык стандарта): запускаем цикл, в каждой итерации которого читаем значение из in, потом значение из out, складываем первое со вторым и записываем в out. По окончании цикла возвращаем значение из out. Т.е. мы имеем 2 операции чтения и одну операцию записи памяти в цикле, а также одну операцию чтения после цикла. Итого: 10*2 + 1 = 21 операция чтения, и 10 операций записи.

Не нужно быть экспертом в оптимизации, чтобы понимать, что для такой простой функции мы что-то слишком сильно наседаем на память. А, как известно, память — это одно из самых медленных звеньев, когда мы говорим о вычислениях: процессор может очень быстро щёлкать числа и очень долго ждать запросы из памяти. Теперь давайте снимем очки компилятора и наденем очки оптимизатора, что можно сделать с этой функцией?

Первое, что бросается в глаза: мы каждый раз читаем значение из in, это никуда не годится. Давайте вынесем чтение из цикла:

int easySum(int* in, int* out)
{
    auto __tmpIn = *in;
    for(int i = 0; i < 10; ++i)
        *out += __tmpIn;
    return *out;
}

Теперь мы можем засунуть __tmpIn в регистр и получается, что мы только что сократили 10 чтений памяти до 1. Но идём дальше: зачем нам постоянно записывать в out, когда мы можем сначала всё сложить в какой-то временной переменной (которая тоже может размещаться в регистре), а потом разом все записать в out? Сказано — сделано:

int easySum(int* in, int* out)
{
    auto __tmpIn = *in;
    auto __tmpOut = *out;
    for(int i = 0; i < 10; ++i)
        __tmpOut += __tmpIn;
    *out = __tmpOut;
    return *out;
}

Это ещё минус 9 чтений памяти, и минус 9 операций записи. Наконец, уберём ещё одну операцию чтения:

int easySum(int* in, int* out)
{
    auto __tmpIn = *in;
    auto __tmpOut = *out;
    for(int i = 0; i < 10; ++i)
        __tmpOut += __tmpIn;
    *out = __tmpOut;
    return __tmpOut;
}

Теперь, убрав всё лишнее чтение и запись из функции, становится очевидным (если это кому-то было не очевидно в самом начале), что цикл здесь совершенно не нужен:

int easySum(int* in, int* out)
{
    return *out += *in*10;
}

И всё: два чтения и одна запись. Неплохо мы сократили взаимодействие с памятью? Теперь вызовем нашу функцию:

int a = 1;
int b = 0;
std::cout << easySum(&a, &b);

Получим свою 10 и удалимся довольные. Стоп, автор, мы тут вроде про указатели, оптимизации и сложные правила говорим, чего ты нам суёшь примеры для первоклассников? Действительно, немного увлёкся, давайте вернёмся к нашей теме и вызовем функцию так:

std::cout << easySum(&a, &a);

Мы рассчитываем получить в ответе 2^10 = 1024, а получаем... 10! Выходит, что надев очки оптимизатора, мы забыли их протереть и превратили корректную функцию непонятно во что. Поэтому отматываем полностью нашу оптимизацию, и функция возвращается в свой первозданный вид — её нельзя оптимизировать, т.к. если первый и второй аргументы указывают на один и тот же объект, то всё сломается! Мы обязаны в каждой итерации читать *in и *out из памяти и ничего нельзя с этим сделать, из-за пресловутой возможности обоих указателей ссылаться на один и тот же объект.

Но если чуть-чуть изменить нашу функцию:

long easySum(int* in, long* out)
{
    for(int i = 0; i < 10; ++i)
        *out += *in;
    return *out;
}

То мы спокойно можем превращать её в одну строчку: return *out += *in*10;, потому что out и in больше не могут указывать на один и тот же объект — язык это запрещает. Вот вам и плоды использования ПСС в свою пользу. Но выполняют ли подобную оптимизацию компиляторы? Давайте проверим. Вот во что превращает clang нашу функции с int (я сократил количество итераций до 4, чтобы меньше кода было):

mov     eax, dword ptr [rsi]
add     eax, dword ptr [rdi]
mov     dword ptr [rsi], eax
add     eax, dword ptr [rdi]
mov     dword ptr [rsi], eax
add     eax, dword ptr [rdi]
mov     dword ptr [rsi], eax
add     eax, dword ptr [rdi]
mov     dword ptr [rsi], eax

А вот вариант с long:

movsxd  rax, dword ptr [rdi]
shl     rax, 2
add     rax, qword ptr [rsi]
mov     qword ptr [rsi], rax

Т.е. компилятор выполнил ровно то, что мы описали выше, воспользовавшись ПСС. У GCC ассемблер несколько иной, но принцип тот же. На MSVC, к сожалению, разницы никакой нет — не умеет он использовать это правила в целях оптимизации. Полагаю, можно считать, что когда компилируешь с помощью MSVC компиляция всегда происходит с флагом -fno-strict-aliasing. Разумеется, никаких официальных заявлений в документации вы не найдёте, но, на мой взгляд, пока не заявлено обратного, мы можем это предполагать. ПСС это действительно очень спорная тема, поэтому Micrisoft не пойдёт на то, чтобы молча добавить НП к целой куче существующего кода, не добавив ключа для компилятора.

Итак, мы рассмотрели простейшую и очень утрированную функцию, благодаря которой смогли легко проследить, что же мы можем выжать из ПСС. Конечно, мы сами себе создали проблему, после чего героически её решили: изначально in нужно было передавать по значению, а не указателем, т.к. никакого смысла в указателе там нет. И тогда эта функция была бы оптимизирована на любом компиляторе, включая MSVC.

Но хочется отметить некоторый интересный момент: многие новички, узнав что в C++ все параметры нужно передавать по константной ссылке, берутся за дело слишком рьяно и начинают даже интегральные типы передавать по ссылке! Так что если код с указателем и выглядит чрезвычайно натянутым, то вот такая функция вполне может появиться: int easySum(const int& in, int& out). Выглядит по-другому, а суть та же самая — компилятор не может оптимизировать эту функцию, т.к. обе ссылки могут указывать на один объект. Поэтому, да, пример натянутый, но не так сильно оторван от реальности, как может показаться.

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

struct Vector4d
{
    int x;
    int y;
    int z;
    int w;
};

Для которой есть следующая операция сложения со скаляром:

void sumVec(Vector4d& vec, const int& val)
{
    vec.x += val;
    vec.y += val;
    vec.z += val;
    vec.w += val;
}

А вызываем мы всё это так:

long scalar = 10;
Vector4d vec{0, 1, 2, 3};
sumVec(vec, scalar);

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

mov     eax, dword ptr [rsi]
add     dword ptr [rdi], eax
mov     eax, dword ptr [rsi]
add     dword ptr [rdi + 4], eax
mov     eax, dword ptr [rsi]
add     dword ptr [rdi + 8], eax
mov     eax, dword ptr [rsi]
add     dword ptr [rdi + 12], eax

Примерно тот же код мы имели в предыдущей функции суммы. Но почему компилятор не оптимизировал нашу функции, у нас же разные типы, значит он должен был воспользоваться ПСС и использовать более эффективный код! На самом деле компилятор не может оптимизировать эту функцию, потому что обе ссылки могут указывать на один объект. Причём этого можно добиться двумя разными способами. К примеру, мы могли бы вызвать функцию так: sumVec(vec, vec.x), или вот так (маловероятно): sumVec(vec, reinterpret_cast<int&>(vec)). Первый способ очевиден и не требует пояснений, а вот второй возможен благодаря шестому пункту правил, который явно разрешает указателю на сложный тип указывать на объект простого, если в составе сложного типа есть этот самый простой. Т.к. наша структура состоит из объектов типа int, то мы можем, имея Vector4d&, сослаться на объект типа int, приведя исходную ссылку к int&.

Как мы уже говорили ранее, этот пункт правил является весьма противоречивым, и он будет удалён из будущих версий стандарта C++ [1]. Про C пока сказать сложно, но дело в том, что подобная интерпретация данного пункта вряд ли является причиной, по которой компилятор не стал оптимизировать наш код. Скорее всего, причина как раз в том, что скаляр может ссылаться на один из членов структуры. Т.е. тот факт, что данный пункт пропадает из C++20 ничего для этой функции не меняет — она не может быть оптимизирована. В противном случае, она попросту будет сломана для таких случаев sumVec(vec, vec.x). Но, как и в прошлый раз, небольшая смена типа в сигнатуре функции всё меняет: void sumVec(Vector4d& vec, const long& val); после чего мы получаем вот такой ассемблер:

movdqu  xmm0, xmmword ptr [rdi]
movd    xmm1, dword ptr [rsi] 
pshufd  xmm1, xmm1, 0        
paddd   xmm1, xmm0
movdqu  xmmword ptr [rdi], xmm1

Видя, что ссылки не могут ссылаться на один объект, компилятор избавился от чрезмерного общения с памятью, а также воспользовался более эффективными SIMD-инструкциями, чтобы выполнить сложение.

Очевидно, что пример снова натянутый и там изначально не должно было быть ссылки у val, так для чего я это всё показываю? Первое, чтобы вы на простейших примерах видели, на что способен оптимизатор, когда у него развязаны руки. Второе, чтобы лучше понять ситуации, в которых компилятор может быть уверен, что разные указатели не могут указывать на один объект, а в каких не может. И, наконец, третье, чтобы вы понимали, что скрывается за НП, когда мы говорим о нарушении ПСС. В мире C++ любят говорить, что из-за НП может происходить всё, что угодно, вплоть до стирания жёсткого диска, но подобное описание мало что говорит о технической стороне вопроса, что, в свою очередь, не позволяет адекватно анализировать риски и строить предположения. Тем более, что, как я уже говорил, правило ПСС нарушалось, нарушается и будет нарушаться сплошь и рядом, и вы должны самостоятельно и сознательно решить, хотите вы его нарушать или нет.

Заключение

На просторах данного блога мы уже не раз затрагивали указатели (и кто знает сколько раз ещё затронем?). Крупнейшими можно считать цикл по указателям и эту статью. Так как цикл был предназначен в первую очередь новичкам в C++, он написан с очень большим количеством допущений и прибегает к объяснению указателей через призму реального мира. Другими словами, объясняя концепцию указателей, я использовал реальную (но очень упрощённую) модель памяти, которая используется в x86 архитектуре. Это простой и наглядный метод, который используется многими людьми, которые пытаются объяснить указатели тем, кто их не понимает.

И не только указатели объясняется через какие-то существующие архитектуры — практически любая сложная абстракция объясняется через существующие решения. Взять, к примеру, те же барьеры памяти, которыми оперируют знатоки многопоточного кода, хотя C++ никакими барьерами не оперирует! Все подобные примеры объединяет одно: рассмотрение программы C++ через призму конкретной реализации. И здесь программист попадает в ловушку восприятия, которую мы отчасти и продемонстрировали в настоящей статье. Его учили конкретным воплощениям абстракций, но язык так не работает!

Язык C++ работает с абстрактной, несуществующей моделью (архитектурой), поэтому, когда пишется программа на C++, применять можно только те знания, которые соответствуют этой модели. Таким образом, при написании C++-программы нужно оперировать концепцией отношений (синхронизируется с, происходит до и т.п) и указателями, вместо барьеров и адресов. Только так можно писать корректные и переносимые программы.

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

В качестве бонуса предлагаю ознакомиться со статьей, посвящённой особенностям различных архитектур, существовавших в истории: «C Portability Lessons from Weird Machines»