LightElf (26.07.2020 18:00, просмотров: 656) ответил fk0 на Вот именно в этом я и пытаюсь убедить -- что сами упакованные
структуры нихрена не продуманная "фича", страдающая множественными
дефектами и не совместимостью со стандартным языком C/C++. Поэтому
её нет в стандарте. Потому, что куда не ткнись, любое нетривиальное
использование (кроме непосредственного обращения к членам как к
значениям) -- неопределённое поведение. А как код-то писать? Шаг
влево-вправо -- "баги".Не надо делать мне как лучше, оставьте мне как хорошо
-
- В основе языка C лежит ЯВУ (B)CPL к которому добавлены системные возможности. Структуры (record, записи) в ЯВУ могут быть представлены неупорядоченными множествами. Для несистемного языка этого вполне достаточно. В С структуры появились не сразу, первые версии были без структур и Ричи сразу планировал прямое соответствие описания структур фактическому бинарному (битовому) расположению в памяти. К тому же первые версии C создавались для CISC машин, поэтому в оригинале RxTx(1382 знак., 29.07.2020 14:43)
- Косяк стандартизаторов в том, что этой недофичи попросту нет в
стандарте? Оригинально. Её и не хотят принимать, потому, что очень
много спорных моментов возникает. Значит компилятор должен уметь
генерировать код умеющийся обращаться к невыравненным данным вообще
(сейчас такой обязанности у компилятора нет). Значит объявление
такой структуры должно автоматически вводит множество типов
унаследованных от базовых (типа int), но со своим выравниванием.
Значит эти типы должны fk0(375 знак., 26.07.2020 18:06)
- Все эти спорные моменты уже давно решены и реализованы. Так или
иначе. Почему бы просто не стандартизовать ежу существующее
поведение? - LightElf(26.07.2020 18:10)
- А где задокументировано, как они решены и реализованы? Если нигде,
то что тогда стандартизировать? Я что-то не уверен, что всё прямо
так решено: в начале топика я давал ссылку -- смотри, оно
упакованный тип от неупакованного в упор не отличает. Легко это
превратить в баг. И присваивание указателей, значит, проканает без
ошибок. fk0(248 знак., 26.07.2020 22:19, ссылка, ссылка)
- ну смотри, проблема такая (паддинг, упакованные типы) существует?
существует. другие проблемы связанные с физической реализацией
работы с конкретными типами существуют? существуют. (переполнения
там, арифметика с насыщением). так почему бы хоть какое-то общее
множество не внести в стандарт? слишком уж далеко виртуальная
абстрактная машина стала абстрагироваться от существующей
физической реализации АЛУ в процессорах. - Mahagam(29.07.2020 15:28)
- Потому, что весь топик об этом. Чтоб внести в стандарт упакованные
структуры -- нужно вообще ввести новые типы данных не совместимые с
существующими (с чего баг начался). - fk0(29.07.2020 17:41)
- а может хватило бы модификатора? по типу volatile. который не меняет тип, но меняет работу с ним. Mahagam(130 знак., 30.07.2020 01:15)
- Потому, что весь топик об этом. Чтоб внести в стандарт упакованные
структуры -- нужно вообще ввести новые типы данных не совместимые с
существующими (с чего баг начался). - fk0(29.07.2020 17:41)
- ну смотри, проблема такая (паддинг, упакованные типы) существует?
существует. другие проблемы связанные с физической реализацией
работы с конкретными типами существуют? существуют. (переполнения
там, арифметика с насыщением). так почему бы хоть какое-то общее
множество не внести в стандарт? слишком уж далеко виртуальная
абстрактная машина стала абстрагироваться от существующей
физической реализации АЛУ в процессорах. - Mahagam(29.07.2020 15:28)
- А где задокументировано, как они решены и реализованы? Если нигде,
то что тогда стандартизировать? Я что-то не уверен, что всё прямо
так решено: в начале топика я давал ссылку -- смотри, оно
упакованный тип от неупакованного в упор не отличает. Легко это
превратить в баг. И присваивание указателей, значит, проканает без
ошибок. fk0(248 знак., 26.07.2020 22:19, ссылка, ссылка)
- Все эти спорные моменты уже давно решены и реализованы. Так или
иначе. Почему бы просто не стандартизовать ежу существующее
поведение? - LightElf(26.07.2020 18:10)