Re[28]: Carbon
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.04.24 05:33
Оценка: +1 :))
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:

V>Почему конкретнос в span<> использутся знаковые индексы — потому что это смещения, для которых как раз знаковые и пригодны, о чём я сразу же и сказал, а ты побежал спорить от "недостаточной компетенции" (С) Синклер.
Напомню, что в статье речь не только об индексах, но и о size(), который ну никак-никак отрицательным быть не может.
Оттуда же пример про unsigned area(unsigned h, unsigned w).

V>Да ничего там не запрещено:

V>

V>In an unchecked context, overflows are ignored and any high-order bits that do not fit in the destination type are discarded.

Продолжаем отжиг в жанре "гляжу в книгу — вижу фигу".
Это и есть defined behavior.
Следите за руками: в дотнете прибавление единицы к int 0x7FFFFFFF даёт int 0x80000000 (overflows are ignored). Здесь нет никаких бит для отбрасывания, т.к. весь результат fits in the destination type.
А в C++ такое прибавление даёт undefined behavior.

V>"destination type" для переменной в памяти или возвращаемого значения метода это одно, а для промежуточного значения при вычислении формулы унутре регистров может быть другим.

Для интегральных типов — нет, не может.

V>В сегодняшних плюсах — это консенсус производителей процессоров и огромного сообщества разработчиков на С/С++, где размер сообщества значительно больше размера сообщества дотнетчиков.



V>Это не тебе решать.

Естественно. Просто это уже решено.

V>Моё "приведённое поведение" лишь демонстрирует суть проблемы (если кто еще не уловил, почему в твоей версии были oops) — часто в железе выгодней оперировать размером в слово, чем в полуслово с постоянной коррекцией результата или с вызовом инструкций с длинными префиксами, как это происходит для инструкций в полуслово для intel-архитектуры.

Зачем вы повторяете глупость? Расскажите мне, каким размером оперирует в железе is_max<long>? Каким размером оперирует is_max<unsigned long>?
И почему первая выдаёт oops, а вторая — wow?

V>Учитывая, что за десятки постов обсуждения с коллегой никто из вас так и не догадался, что происходит и почему именно так — я посчитал нужным продемонстрировать происходящее явным образом.

Все, кому надо, давно обо всём догадались. Один вы продолжаете тупить.
Если вас посетит нестерпимое желание продолжать, распишите по шагам, что там происходит за "расширение полуслова до слова" для int64, и что делается при "постоянной коррекции результата".
Возможно, вас посетит просветление. Хоть и вряд ли.

V>Со всеми тремя из их официальной книги об истории и ходе разработки дотнета.

V>Уже не в первый раз тебе рекомендую, а то витаешь в облаках, несёшь дичь какую-то из пальца насосанную.
Давайте что ли ссылку на книгу. А то ваша способность читать то, чего нету, и не читать то, что есть, достигла легендарного уровня.

V>И чем там поможет знаковое в сравнении с беззнаковым?

Тем, что по условию, входные числа — знаковые.
V>И чем там поможет дотнет в режиме unchecked?
V>Там тупая потеря результата, если не удаётся расширить промежуточное значение (я же тебе же об этом же и отвечал ).
Ну, так вопрос-то как раз в том, как этой потери избежать. Результат там совершенно точно влазит в диапазон long, не так ли

Вот, скажем, std::midpoint — канонический пример, где лучшие специалисты планеты смогли найти ответ только с третьей попытки. И это — совсем недавнее прошлое. Вряд ли там дотнетчики виноваты.
Они вообще не в курсе всей драмы с midpoint и неожиданными UB на ровном месте.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.