Здравствуйте, Mystic Artifact, Вы писали:

MA>>>Любой двоичный тип данных может быть выражен как просто число.
E>>Это не совсем правда, или я не понял о чём ты. Например, не любой указатель в С++ может быть так выражен. Указатель на поле, например, -- это двоичный тип?
MA> Единственная причина, почему указатель не мог быть приравнен к соответствующей размерности числу — это разного рода виды теневой памяти и прочее. Сюда же относится и сегментная память, с которой работают текущие процессоры. Но, она всегда настраивается на "плоский" режим, а C++ не позволяет работать с сегментами. Таким образом это все быстро вырождается в то, что мы имеем 32/64-битные адреса и они де числа.

1) Почему это С++ не умеет работать с сегментной памятью?

Или имеется в виду, что нет средств разбора сегментного указателя? В принципе на конкретной платформе можно интерпретировать указатель, как структуру с числовыми bitfields и там уже работать, так же как и мз double, например, можно явно мантису выкачать.

2) Указатели в С++ и С не обязательно просто адреса.
Подумай, например, об указателе на метод класса с виртуальной базой

MA> Я отвечаю по мере. Ну вот ты в теме. Я не отрицаю вообще-то, что, что-то там. Я говорю, что язык не дает. Он дает указатель и все. А из чего он состоит — не дано. Более того, он ссылается всегда сегмент данных. И да. Именно поэтому нельзя путать их с указателями на функцию, и интерпретировать так же — но готов ли к этому современный код? Нормальный современный код не парится.

Указатель на функцию может иметь sizeof больше, чем у void*, если что. Например на RISC архитектурах, где популярно иметь регистр с указателем на быструю память, обычно содержит в указателе на функцию адрес кода и адрес нужного сегмента данных.

E>>Формально вычитать нельзя ничего, кроме указателей на один и тот же объект/массив или сразу за его конец.
MA> Правильно. Это как-то контролируется? Есть много нельзя, мало как можно.
Ну так UB жеж

MA> Именно. Это и говорит о том, что они не различимы. Разница, в x86 потом происходит только во флагах и их интерпретации. Дело в том, что при 16-битной сетке нет разницы — то ли ты вычьтешь единицу, то ли прибавишь 65535. Мы не говорим о пространственных теориях приводящих к UB. В процессора нет UB, он работает по модулю и отлично и выдает кучу флагов...

Мы же говорим о ПО -- трансляторе и о человеке -- читателе программы. И тому и другому есть разница.

MA> Да. Я тут в теме кидал, никто не оценил, почти единственный обратный цикл... компактен и роли не роялит. Ну в моем восприятии — это все крайне вторично. Гораздо сложнее понять что делает код вообще, потом как он делает и ессно низкоуровневые нюансы не рассматриваются, они просто теряются, да и не могу их назвать чем-то странным.

Можно пропустить нюанс и неверно понять всё в целом. Но я согласен. Борьба со всякими стандартными трюками вроде i-->0 или *dst++ = *src++ довольно бессмысленна. Реальные проблемы разработки лежат в иных плоскостях

E>>Ничего я не ставлю. Просто код, который оперирует с абстракциями так, что нужно всё время помнить о том, как это будет выглядеть в бинарном представлении, обычно читабельным не считают
MA> Выше было в скобочках, но тут явно — это крик души, а не выпад лично к тебе. Люди которые приблизительно понимают как это будет выглядеть — обречены этой херней страдать. Но иногда — выхлоп того стоит. Спору нет. Это же кстати касается далеко не только C++.

+100500

E>>А вообще да, гражданские -- дураки. Строем не ходят, в машкодах не программируют и всё такое
MA>