Re[8]: Откуда эта лютая любовь к знаковым целым?
От: Mystic Artifact  
Дата: 07.05.20 23:44
Оценка:
Здравствуйте, Erop, Вы писали:

E>Суть типов вроде ptrdiff_t не в том, что это какие-то супер-совместимые числа, а в читабельности. И поясняю читателю кода, из каких соображений я выбрал тут разрядность и знаковость целого...

Абсолютно согласен и думаю это справедливо.

E>Соответственно, если я использую такой тип для функции вроде fseek, это будет, в первую очередь непонятно, так как разрядности длины сегмента/адреса и длины файла никак не связаны...

Отличный пример. Да!

MA>>Любой двоичный тип данных может быть выражен как просто число.

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

MA>>Адрес — это просто число. Это мантра. Повторяй до просветления...

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

E>Формально вычитать нельзя ничего, кроме указателей на один и тот же объект/массив или сразу за его конец.

Правильно. Это как-то контролируется? Есть много нельзя, мало как можно.

E>Это не совсем правда. При вычитаниях unsigned от signed очень даже отличаются, хотя и имеют одинаковое бинарное представление...

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

MA>>В чем спор то?

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

E>1) не подойдёт. В С жёсткая статическая типизация

E>2) кроме множества значений, тип задаёт и набор операций. Проблема unsigned в том, что в области вычитаний они не соответствуют целым ;(
Ну я же утрировал... Хотя с JS и number — оно реально представлено реальными int32 и double если нужно.

E>Ничего я не ставлю. Просто код, который оперирует с абстракциями так, что нужно всё время помнить о том, как это будет выглядеть в бинарном представлении, обычно читабельным не считают

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

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

 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.