Все по-старому пока что: на мой комментарий не ответили, свой issue не создавал, но собираюсь.
у меня стойкое ощущение, что модель, надо опять переписывать, и докидать немного реальности
Если не учитывать текущие обсуждения о destructive-move и дополнения по provenance-модели (которую я тоже все еще не читал), то я бы сказал, что скорее "подлатать" было бы достаточно. Если же учитывать, то осмелюсь делать выводы только после того, как ознакомлюсь с упомянутыми темами намного подробнее. "Идейно" модель кажется довольно неплохой, переделку с нуля, наверное, не хотелось бы скорее.
модель умеет в объекты живущие одновременно по нескольким адресам? а в разные объекты живущие по одним и тем же? а если у нас несколько типов памяти (не только ram как на PC)
а ещё не ясно есть ли компиляторы которые нормально определяют конверсии число — указатель и обратно, все системщики пользуются, а оно формально взрывоопасно
кстати, к разным типам памяти, в разных типах памяти могут быть байты разных размеров, вот тут начинается ад, правда хз есть ли настолько упоротые архитектуры
"По нескольким адресам" - насколько мне известно, такого нет; "сможет ли" - сходу сказать сложно. Если это касательно destructive-move, то, полагаю, желательно точнее понимать, что же все-таки хочется, либо сразу заложиться на какую-то абстрактную семантику (например, что хочется определить, что можно объект снимать с одного региона хранилища и перекладывать на другой; достаточно будет перенос сделать атомарным и настроить ему sequencing, чтобы объект "в двух разных местах" нельзя было пронаблюдать). "Несколько объектов по одному адресу" - да, такое есть: nested-within про это. Но это в контексте "сырых" адресов без provenance'а, с ним указатели/ссылки будут разные, хоть и с численно равным адресом.
первое можно если два маппинга страниц указывают на одну и туже память, второе подразумевает, что оба объекта одновременно в своём лайфтайме, просто нет одновременного доступа, т.е. перед доступом нужно с помощью магических действий выбрать нужный объект
Хочется уточнений, что значит "нормально" все-таки. С "provenance-punning'ом", чтобы можно было обходить ограничения адресной арифметики? GCC это явно запрещает, в Clang рассматривался случай, когда provenance ошибочно протекал в сравнения указателей, так что думаю, что тоже нет. Положение дел на MSVC мне не известно)
нормально, это когда не взрывается, пусть и мне придётся компилятору наставить хинтов, чтобы он аккуратнее оптимизировал
Понимаю идею с первым, второе, опять же, есть уже сейчас с "магией" разного уровня. Опять же, например struct { int i; } s; уже про это =)
Возможность более "глубоко" вторгаться в модель руками хотелось бы, да.
второе, емнип, ещё оверлеями назвать можно
хотелось бы ею манипулировать до байтика
Я, кстати, Вас возможно как-нибудь поспрашиваю насчет идей с create_storage(): нужно как-то формализовать системную сторону вопроса.
Обсуждают сегодня