А зачем нужна рефлексия и почему все с ней так носятся?

сериализаторы классно писать

не так и сложно на самом деле. Просто чуть-чуть времени этому уделять, и жизнь становится проще. И переписывать ради переписывания не стоит.

+++ Ну, правда, всякие там for(Type a : blah) не напишешь. Да и смысл auto был немного в другом можно заменить разве что на какой-то макрос, ну или заюзать компиляторозависимую штуку

а, и лямбд нету. Они бывают довольно удобны, но и без них жить можно

+++ Ну, правда, всякие там for(Type a : blah) не напишешь. Да и смысл auto был немного в другом можно заменить разве что на какой-то макрос, ну или заюзать компиляторозависимую штуку

зачем? оставь как есть и не надо обмазываться говном макросным. А когда будет возможность - перепишется и всё

ага

А зачем нужна рефлексия и почему все с ней так носятся?

Можно получить информацию о методах и полях (название, количество аргументов, возвращаемый тип и т.п.), а так же информацию о базовых классах Как минимум можно реализовать сериализацию ЛЮБОГО класса ровно одной строкой. Да и прикреплять всякие СЯП куда проще

А зачем нужна рефлексия и почему все с ней так носятся?

Потому что это уберполезно.

отголоски этого есть, аля typeid - но все же это все не то

Потому что это уберполезно.

Угу. Все надеялись что в С++17 добавят, но в комитете все разругались (было несколько вариантов реализации статической рефлексии, не смогли выбрать самый удачный)

сериализаторы классно писать

Только для этого кажись

Только для этого кажись

Только это не ограничивается "записать экземпляры в файлик"

Вот другой пример:

Только для этого кажись

написание компараторов

Только это не ограничивается "записать экземпляры в файлик"

А я не ограничивал

Именно статическую рефлексию хотят сделать?

написание компараторов

Не вижу профита

редактор карт. Ты можешь увидеть свойства у объектов и их менять так, как душе удобно. И для этого тебе не надо руками регистрировать переменные

Не вижу профита

добавил поле, а в компаратоор забыл добавить его

Именно статическую рефлексию хотят сделать?

Хотели добавить в С++17, а как сейчас - не знаю. Ждем С++20

добавил поле, а в компаратоор забыл добавить его

Добавил поле но забыл что оно учитывается в компораторе

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

Добавил поле но забыл что оно учитывается в компораторе

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

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

Да го сразу новые модификаторы чо уж там

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

Потихоньку превращаемся в шарп, хе-хе.. :D

Да го сразу новые модификаторы чо уж там

фактически, атрибуты + рефлексия - замена модификаторам

Зачем тогда си++

Зачем тогда си++

Работа с памятью

Зачем тогда си++

Не платишь за то, что не используешь?

я лично против шарпа ничего против не имею как языка. Приятно на нём писать

я лично против шарпа ничего против не имею как языка. Приятно на нём писать

Я имею

Если статически, то действительно круто выходит. Динамически - уже какая-то джава. В rust есть derive, у него в чём-то схожая функциональность. Можно автоматически генерировать классу функции.

#holywar ?

Кстати есть где-то перечисление всех вариантов рефлексии которые рассматривали?

Если статически, то действительно круто выходит. Динамически - уже какая-то джава. В rust есть derive, у него в чём-то схожая функциональность. Можно автоматически генерировать классу функции.

По факту динамическая и не нужна

Потомучто имена там на самом деле данные

@arseny ну сначала в любом случае статика будет. Если динамику добавят - то они её как-то хитро обыграют (например, компилятор будет автоматически пытаться использовать статическую рефлексию, если это возможно)

но так-то да, статики более чем достаточно

@arseny ну сначала в любом случае статика будет. Если динамику добавят - то они её как-то хитро обыграют (например, компилятор будет автоматически пытаться использовать статическую рефлексию, если это возможно)

Я хочу явно видеть компильтайм всегда

И так от констекспр плевался

@arseny ну сначала в любом случае статика будет. Если динамику добавят - то они её как-то хитро обыграют (например, компилятор будет автоматически пытаться использовать статическую рефлексию, если это возможно)

И специальный ключик, который будет ее отключать. Как typeid и исключения.

Я хочу явно видеть компильтайм всегда

А что делать, если ты работаешь с dll, причем либа часто перекомпилируется, меняются методы и поля (и тебе надо за изменениями следить)?

т.е. интерфейс остается тем же

А что делать, если ты работаешь с dll, причем либа часто перекомпилируется, меняются методы и поля (и тебе надо за изменениями следить)?

Инклудить интерфейс не?

а вот реализация...

т.е. интерфейс остается тем же

Ну ты через него же работаешь

Тебе больше ничего не нужно

Или ты думаешь тебе позволят доставать то что не объявлено?

Выглядит как дрисьня

а как ты через интерфейс получишь список полей, м? В нем-то всего лишь чисто виртуальные методы

Или ты думаешь тебе позволят доставать то что не объявлено?

позволят, ещё как

Или ты думаешь тебе позволят доставать то что не объявлено?

Выглядит как дрисьня

не хочу лезть в субъективщину

позволят, ещё как

Нельзя так делать

Это нарушение инкапсуляции кажется

Ну вот смотри, друг

Не буду

Это дичь

Все

Тогда к чему все это? Монолог?

Допустим мы разрабатываем игрушку. Есть интерфейс сущности IEntity. Все новые виды сущностей (монстры, окружение и т.п.) наследуются от IEntity и переопределяют виртуальные методы Вот мы дошли до редактора карт, в котором мы расставляем эти сущности (объекты). Как изменять свойства объекта, как их читать? Интерфейс - просто перечисление чисто виртуальных методов. Перекомпилировать редактор карт каждый раз? =))

Редактор карт знает лишь о каком-то IEntity, не более

Редактор карт знает лишь о каком-то IEntity, не более

Ну выбери чем будет IEntity. Кажется ты хочешь контейнер свойств. Только непонятно зачем тебе релексия если это явно контейнер

Динамическая рефлексия всегда сводится к контейнеру

Потомучто имена там на самом деле данные

Потомучто

ERROR: S client not available

Динамическая рефлексия всегда сводится к контейнеру

почему это? хранить пары имя-смещение

Динамическая рефлексия должна будет приводить к ощутимому росту бинарника.

да, идем дальше Вот хранится внутри class Player: public IEntity экземпляр кастомного класса Health. Ты хотел бы чтобы в редакторе оно высветилось как подкатегория + можно было дергать свойства Health. Но класс объевлен только в рамках сборки данного объекта, редактор карт знать-не знает ни о Player, ни о Health

Динамическая рефлексия должна будет приводить к ощутимому росту бинарника.

Я в пример ставлю редактор карт. Как игрушка в конце собираться будет - дело двадцатое

Да, можно руками регистрировать каждое поле. Это будет работать. Но вы же заставляете это делать геймдевелоперов - они не должны об этом думать, они должны игру писать

да, идем дальше Вот хранится внутри class Player: public IEntity экземпляр кастомного класса Health. Ты хотел бы чтобы в редакторе оно высветилось как подкатегория + можно было дергать свойства Health. Но класс объевлен только в рамках сборки данного объекта, редактор карт знать-не знает ни о Player, ни о Health

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

а более аргументированно можно?

вот приведи свою реализацию, как бы сделал ты

а более аргументированно можно?

Чё аргументировать? У тебя концептуально не правильный подход

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

Все что ты перечислил

То есть ты предлагаешь руками перечислять свойства через методы IEntity/IEngine? Или как?

Как сделать красиво?

То есть ты предлагаешь руками перечислять свойства через методы IEntity/IEngine? Или как?

Не надо ничего перечислять это должно быть подобие контейнера

псевдокод можешь показать? Мне просто скоро подобную задачу надо будет решать, вот и интересуюсь

Не могу

Ясно

Зачем редактору карт вообще знать что там в игре в бинарнике?

Свойства. Вот отмечаешь нужные переменные, которые редактор может менять, и в редакторе они появляются

Сериализация решает эту проблему.

речь же не о игре самой

Если я правильно понимаю.

Да просто я вижу что твои мысли вдохновлены редактором Джаваформ и винформ

нет конечно, лол

Посмотри вон даже на UE4

у них целая тулза для рефлексии забахана

только чтобы узнать какие свойства дергать

никаких намеков в интерфейсе тупо нет (и не должно быть)

И все что она делает это контейнер, только рядом, отвечаю

Контейнер? Какой контейнер? Там кодогенерация, в том числе часть действительно сериализуется

Контейнером я много чего обозвать могу