там массив инициализируется листом

что эквивалентно int arr[] = {}

то есть не std::initializer_list, а braced-init-list как встроенная конструкция компилятора, и из неё может неявно инициализироваться массив?

В cil

Вот массивы ладно, но не хватает возможности мне так кажется залитералить произвольный constexpr init list. Чтобы в span его например. И в иерархию span. Он же по любому существует в момент вызова, достаточно как для строк его в .data сунуть со static lifetime.

нельзя это сделать constexpr массивом или std::array, и дальше из него конструировать, тоже в компайл тайм, другие нужные классы?

Здравствуйте, господа.
Архитектура вынуждает осуществить явное приведение типов вида
B* C::* -> D* C::* при условии, что B - невиртуальный предок D, а приводимое значение в действительности указывает на поле C типа D* (т.е., по сути, обычный Base* to Derived*, однако, с сохранением информации о том, что сам указатель хранится в поле произвольного C). static_cast и dynamic_cast такого функционала не предоставляет, reinterpret_cast слишком либерален, т.к. готов, согласно 7.6.1.10/10 осуществлять любые приведения вида T1 C1::* -> T2 C2::*, где T1 и T2 либо оба объекты, либо функции. Я что-то упускаю, кроме того факта, что наличие таких приведений в архитектуре в принципе нежелательно?

кажется, вы упускаете, что такое преобразование невозможно
если я еще не засыпаю, то преобразование B* -> D* может содержать арифметику, и записать требуемую арифметическую операцию после чтения поля в указатель на член нельзя

Если я еще не засыпаю, Вы что-то странное написали =)
Что подразумевается под "записать арифметическую операцию в указатель на член"?.. И о какой арифметике вообще речь идет? Изменение адреса? Само преобразование возможно с использованием reinterpret_cast, как я написал выше, однако, он допускает вообще практически любое преобразование подобной формы, вот я и интересуюсь, есть ли какой-то более строгий способ.

ну смотрите, если struct Derived : Base1, Base2, то преобразование Base2* -> Derived* отличается от reinterpret_cast тем, что необходимо произвести вычитание фактического значения указателя, то есть при наличии Base2* C::* получение Derived* выглядит как (а) чтение Base2* (б) смещение его на sizeof(Base1). Ни при каких условиях чтение Derived* C::* так себя не ведёт, компоненты (б) там нет

при этом возможность произвести reinterpret_cast, конечно, совершенно не гарантирует, что результатом можно будет пользоваться

В общем да, оно будет, компилятор все знает и все умеет, но только при условии что B* это по факту указатель на D*. Тогда будет поле C, Иначе, там будет мусор. Самый безопасный способ работать изнутри B используя CRTP (причем C должно быть и в B и в D, тогда в самом худшем случае мы получим не мусор, а поле C из B

Да, это я дичь нес все это время. Оплошность понятна, благодарю Вас. В данном случае, впрочем, использование reinterpret_cast возможно, т.к. по смещению реально лежит указатель на Derived*.

Как синхронизировать удаление объекта?
Дано: некий объект с двумя методами (назовем их Read() и Write()), работает в агрессивной многопоточной среде, сами методы lock-free
Задача: синхронизировать уничтожение - если объект еще читается или пишется, ждать окончания операций
Гарантируется, что новых обращений не будет, речь о "задолженностях"
Идея лочить shared_mutex в методах и деструкторе кажется крайне сомнительной

поставь мьютексы в методы и деструктор

Да, вопрос в том, насколько это хороший вариант и единственный ли он

Можно, но их надо раздельно создавать как lvalue, хочется иногда как literal -> sv делать { 1,2,3 } -> span<const int>.

lock-free - там же всеравно есть атомарные счетчики как минимум? Что мешает дождаться их обнуления в деструкторе? Или прям для каждого потока свой участок памяти?