n
что у тебя за ёба-штуки, что ты ТАК боишься оверхеда на вызов?..
у меня академический интерес, блин)
Size: a a a
2021 March 21
n
Какой?
на вот эту Execute и прочую блюпринтовую обёртку)
VS
на вот эту Execute и прочую блюпринтовую обёртку)
У нативных вызовов будет только мизерный оверхед из-за виртуальности, у блюпринтовых иначе никак без блюпринтового оверхэда не обойдёшься, потому что они.. Ну... И есть блюпринтовые.
n
У нативных вызовов будет только мизерный оверхед из-за виртуальности, у блюпринтовых иначе никак без блюпринтового оверхэда не обойдёшься, потому что они.. Ну... И есть блюпринтовые.
не, там Execute внутри какую-то адовую фигню творит, каждый раз проверяет на рефлексию и т.д.
VS
Так у тебя Execute будет только вызываться для блюпринтовых реализаций, для нативных ты будешь сразу _Implementation вызывать.
KD
в идеале мне надо:
1. возможность определять метод интерфейса как в плюсах так и в бп
2. при имплементации интерфейса в плюсах чтоб не было оверхеда на БП
3. удобное и одинаковое АПИ в месте вызова, чтоб не надо было думать где интерфейс имплементирован (в ++ или в бп)
Я пока не нашёл, как можно хотя бы 1 и 2 вместе сделать, даже без учёта п.3
1. возможность определять метод интерфейса как в плюсах так и в бп
2. при имплементации интерфейса в плюсах чтоб не было оверхеда на БП
3. удобное и одинаковое АПИ в месте вызова, чтоб не надо было думать где интерфейс имплементирован (в ++ или в бп)
Я пока не нашёл, как можно хотя бы 1 и 2 вместе сделать, даже без учёта п.3
Возможно я тебя шокирую, но подумай о использовании компонента вместо интерфейса.
VS
Ну или так.
n
Так у тебя Execute будет только вызываться для блюпринтовых реализаций, для нативных ты будешь сразу _Implementation вызывать.
а тогда п.3 не работает - надо при каждом вызове проверку делать либо ещё сверху обёртку дополнительную)
n
Возможно я тебя шокирую, но подумай о использовании компонента вместо интерфейса.
технически это вариант, но с точки зрения API оно в моём случае будет ещё менее удобно. Точнее, в идеале мне и то и другое надо будет всё равно
VS
А у тебя в самом интерфейса будет эта обёртка. Отдельный метод виртуальный, который базово вызывает Execute, а в потомках переопределён на вызов нативного метода.
VS
Ты иначе это в принципе без обёртки в каком-либо месте не сделаешь.
VS
Потому что где-то решение это надо принимать.
VS
Но вообще как по мне лучше разделять ВР и плюсы, я не очень уверен, что оно стоит вот этих всех усилий.
VS
Излишняя абстракция это как преждевременная оптимизация.
ВШ
в идеале мне надо:
1. возможность определять метод интерфейса как в плюсах так и в бп
2. при имплементации интерфейса в плюсах чтоб не было оверхеда на БП
3. удобное и одинаковое АПИ в месте вызова, чтоб не надо было думать где интерфейс имплементирован (в ++ или в бп)
Я пока не нашёл, как можно хотя бы 1 и 2 вместе сделать, даже без учёта п.3
1. возможность определять метод интерфейса как в плюсах так и в бп
2. при имплементации интерфейса в плюсах чтоб не было оверхеда на БП
3. удобное и одинаковое АПИ в месте вызова, чтоб не надо было думать где интерфейс имплементирован (в ++ или в бп)
Я пока не нашёл, как можно хотя бы 1 и 2 вместе сделать, даже без учёта п.3
нативизируй БП, хотя приписку _Implementation придется потерпеть
n
нативизируй БП, хотя приписку _Implementation придется потерпеть
я не могу заставлять юзеров АПИ нативизировать их блюпринты)
ВШ
я не могу заставлять юзеров АПИ нативизировать их блюпринты)
можешь порекомендовать
ВШ
и на этом успокоиться
n
можешь порекомендовать
рекомендация и трнебование это несколько разные вещи, но и даже рекомендация так себе звучит...
IP
Котаны, подскажите, почему не совпадают отрезок с гридом?