Или немножно руками задать floorplan

Но это всё уже трудозатратно

самый жырный формат, для хранения не оч

Для хранения да, я и предлагаю — если приспичило посимвольно что-то делать.

@zamazan4ik вот тебе еще оптимизаций - https://godbolt.org/g/815CBg

@zamazan4ik вот тебе еще оптимизаций - https://godbolt.org/g/815CBg

да я видел, как ты там гадишь в issue 😊

да я видел, как ты там гадишь в issue 😊

лень мануалы копать, у кого быстрее

на глаз у гцц

и посмотри как во второй функции гцц фейлится

дело реально в порядке операций https://godbolt.org/g/B5HjBw

где-нибудь в природе есть хорошая либа для runtime reflection для C++ ? Всё что я вижу на github похоже не развивается - даже пробовать страшно

Ну, Qt же что-то похожее реализует, да?

Я видел только чтоб реализацию из Qt использовали, там она достаточно «взрослая».

Я видел только чтоб реализацию из Qt использовали, там она достаточно «взрослая».

она норм, если нет проблем с тем, что она добавляет нехилый оверхед. По сути, каждое свойство или видимый метод - лишняя строка и все сравнивается на уровне строк

Ну да, это верно. А есть ли другие распространённые идеи для реализации runtime reflection?

Ну самая очевидная идея - использовать отладочную информацию.

Есть clreflect например.

Собираешь с отладочной информацией - получаешь рефлекшн.

Donald Williamson писал на базе кланга.

Я когда-то писал на базе макросов runtime reflection.

Есть clreflect например.

тоже похоже мертвый проект

На базе макросов было что-то в boost

но это отстойно. должно быть автоматически всё

clreflect — последний коммит год назад.

Ну самая очевидная идея - использовать отладочную информацию.

Мне она, признаться, очевидной не кажется. Но вот то, что эта идея интересная — это да.

автоматически всё — это в сишарп или джава. Или ждите, может в стандарте что-нибудь появится.

Там были интересные пропозалы на эту тему.

В стандарте более крутой вариант - статическая рефлексия

Оно уже попало в стандарт?

Нет ;) Ещё обсуждают. Когда я последний раз пробовал - работало не всё Например лямбды не работали

Я помню толк то ли Александреску, то ли Sutter рассказывали про какую-то штуку с классами забавную.

Про доопределения своих типов классов.

Забыл как это называлось.

Вот там он рефлекшон использовал активно.

саттер последнее время про метаклассы рассказывает

Дада.

Метаклассы.

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

Т.е. если рефлешн появится в 2025, то метаклассы где-нибудь в 2030 )

Можно не дожить короче.

В общем думаю в бусте должны озаботиться созданием библиотеки для runtime рефлексии на базе отладочной инфы

Не, там нету вроде. Не было в 2013 году по крайней мере.

В бусте уже есть либы которые отладочную информацию используют

Да? Круто.

Например boost stacktrace умеет выводить callstack

c реальными именами функций из отладочной инфы

В общем идея использовать отладочную инфу кажется здравой, но видимо мало кому нужно

А после того как в стандарте появится статическая рефлексия, то ещё меньше кому надо будет

С другой стороны при использовании статической рефлексии единственный способ программирования - TMP. Что не всегда удобно

Если надо на базе входных данных строить какое-нибудь дерево например из наследников узла разных, то рантайм рефлекшон удобнее. И сериализовать обратно из произвольной композиции таких узлов.

ну скорей всего на практике будет использоваться какая-то комбинация compile-time и runtime программирования

вот тут пример библиотеки сделанной на базе compile-time рефлекcии и TMP : http://matus-chochlik.github.io/mirror/doc/html/

Вот интересно, почему в С++ по умолчанию предпочитают unsafe методы? например в std::array и std::vector operator[] индекс не проверяет, а at ( n ) проверяет

не логичнее ли было сделать наоборот?

по умолчанию safe вариант, если хочется перформанса, меняешь на at() где требуется

не один раз подрывался на этой хрени

Исторически сложилось так, что самые простые варианты самые производительные.

[] в си без проверок

ну в си вообще варианта с проверкой нет

что жалко

Пожалели size_t байт

Ты имей в виду, что на этих языках ещё для ембеда пишут.

Причем какой-нибудь new T[n] все равно сохраняет размер массива в память, если у T есть деструктор

Где такое поведение по умолчанию непозволительно.

Почему?

Потому что когда у тебя оперативная память в байтах ичисляется — ты не хочешь лишний оверхед.

Пожалели size_t байт

а процессорное время на проверку?

И время конечно же.

Ну вот если памяти и перформанса не хватает, я отключу проверку

но дайте safety по умолчанию

расплата за эту ошибку как правило очень высокая

но дайте safety по умолчанию

да не, за индексами надо самому следить по умолчанию

потому что перетереть можно случайно что угодно, можно даже segfault не получить, просто некорректную работу

какждый доступ к элементу чтобы еще проверять это дорого

Можно. емнип, можно включить опцию компилятора, чтобы проверял.

почему дорого? одна проверка дорогая, все последующие дешевы

в процессоре единственная проблема подрузить размер массива

сделать проверку индекса ничего не стоит

почему дорого? одна проверка дорогая, все последующие дешевы

почему одна? не понял, может я не понимаю как можно сделать

ну смотри когда мы делаем первую проверку нужно загрузить размер массива из памяти

для всех последующих он уже в регистре