замапить тип даных на енум тока специализацией шаблонов можна?

Можно. Энум тот же инт (почти)

нахуя я тут шаблонав наделал, лучше бы просто отнаследовался

С современным c++ это удобно делается через template <Enum e> decltype(auto) helper() { if constexpr (e == Enum::foo) { return (Type1*)nullptr; } else if constexpr (...) .... } template <Enum e> using enum_to_type_t = std::remove_pointer<decltype (helper<e>())>;

С современным c++ это удобно делается через template <Enum e> decltype(auto) helper() { if constexpr (e == Enum::foo) { return (Type1*)nullptr; } else if constexpr (...) .... } template <Enum e> using enum_to_type_t = std::remove_pointer<decltype (helper<e>())>;

современным это сколько++ ? хотелось бы до 14

17. 14 только через специализацию

17. 14 только через специализацию

спс

С современным c++ это удобно делается через template <Enum e> decltype(auto) helper() { if constexpr (e == Enum::foo) { return (Type1*)nullptr; } else if constexpr (...) .... } template <Enum e> using enum_to_type_t = std::remove_pointer<decltype (helper<e>())>;

if constexpr (e == Enum::foo) { return (Type1*)nullptr; } else if constexpr (...) это же выглядит тоже как специализация

та же куча строк с выбором

Слово template всего в двух местах, не говоря про <>

Я обычно заранее думаю про расширяемость удобную

Я обычно заранее думаю про расширяемость удобную

ты - молодец

Специализация шаблона более раширяема

Чем ифики

здарова всем

ребят есть вопросик. Допустим есть класс сцены GraphicsScene, который создает только класс Graphics. Есть класс физики сцены PhysicsScene - его создает класс Physics. Если я наследую от GraphicsScene и PhysicsScene класс Scene, то как создавать экземпляры этого класса?

множественное наследование?

да

Как создавать всмысле где создавать или что?

Еще раз повторяю, класс Graphics является фабрикой для создания экземпляров класса GraphicsScene и только он может его создать. Класс Physics является фабрикой для создания экземпляров класса PhysicsScene и только он может его создать. Я хочу организовать класс Scene, который наследуется от классов GraphicsScene и PhysicsScene(множественное наследование). Как мне создать экземпляры классов Scene?

Еще раз повторяю, класс Graphics является фабрикой для создания экземпляров класса GraphicsScene и только он может его создать. Класс Physics является фабрикой для создания экземпляров класса PhysicsScene и только он может его создать. Я хочу организовать класс Scene, который наследуется от классов GraphicsScene и PhysicsScene(множественное наследование). Как мне создать экземпляры классов Scene?

зделай фабрику для создания экземпляров класса Scene

зделай фабрику для создания экземпляров класса Scene

ну хорошо, а что в ней? Как мне правильно инициализировать правильно экземпляры в этой фабрике?

Ведь часть интерфейса класса Scene должна создаваться по правилам GraphicsScene, а другая часть по правилам PhysicsScene.

ну хорошо, а что в ней? Как мне правильно инициализировать правильно экземпляры в этой фабрике?

ну если Scene композицией зделано то там пара мемберов созданых предыдущими фабриками а если множественое наследование то это залёт

композицией понятно что легко

а вот если наследованием...

композицией понятно что легко

ну так зделай

а вот если наследованием...

мож можно внутрение мемберы подвесить на интерфейс получапный от наследования

ну типа переопределяеш все методы

тоесть ответ на мой вопрос - никак?

Scene { grscenemethod() {return GraphicsScenemember.grscenemethod()} }

Фабрики же не какой-то магией объект создают.

Смотри, что там, продублируй в своей фабрике.

А что это за движок?

GraphicsScene* graphicsScene = graphics -> createScene(....); PhysicsScene* physicsScene = physics -> createScene(....);

И я не знаю что там внутри createScene

А что это за движок?

один из них PhyX

PhysX*

я могу сделать композицией, но это не то что нужно. Композиция имеет ввиду: объект состоит из чего-то. А наследование: объект есть что-то

Как раз Scene - это класс, который есть физическая сцена и графическая сцена

а не так что Scene - состоит из графической и физической сцены

я могу конечно в фабрике, которая создает объекты Scene хранить все сцены вот так: std :: map<std :: string, std :: pair<GraphicsScene*, PhysicsScene*» scenes

всем привет

здарова

я тут пытаюсь мигрировать с VS2005 на VS2012 с легаси проектом

вылазит ошибка, которую я, прочитав msdn, так и не понял как поправить

внутри класса есть такие два поля: template class LOGGER_API std::allocator<std::string>; template class LOGGER_API std::vector<std::string, std::allocator<std::string> >;

error C2252: an explicit instantiation of a template can only occur at namespace scope

почему раньше работало, теперь нет?

да хуй его знает.

внутри класса есть такие два поля: template class LOGGER_API std::allocator<std::string>; template class LOGGER_API std::vector<std::string, std::allocator<std::string> >;

Предполагая что часть форматирование сеъел телеграм - это не поля. Это запрос на явное инстанцирование шаблона. Скорее всего вам надо просто удалить эти строчки

Ведь часть интерфейса класса Scene должна создаваться по правилам GraphicsScene, а другая часть по правилам PhysicsScene.

Это в Scene прописывается

Создавать объекты так же как и любые другие

Предполагая что часть форматирование сеъел телеграм - это не поля. Это запрос на явное инстанцирование шаблона. Скорее всего вам надо просто удалить эти строчки

спасибо, сейчас попробую сделать так

а в стандарте по этой теме что-нибудь сказано? Почему старый компилятор это спокойно переваривал, а новый — нет

хотя, насколько я понял, компилятор MS не всегда следует стандарту

Скорее всего, это какой-то глюк старой версии компилятора.

т.е. так в принципе нельзя делать? или нет смысла?

вообще проект довольно дикий, оригинальный разработчик очень давно уволился. например, у этих "полей", которые оказывается и не поля, объявлен дополнительный спецификатор LOGGER_API, видимо, кто-то планировал обращаться к ним извне DLL

но... *барабанная дробь*

они в приватной секции класса

и френдов нет

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

Этож инстанс класса

ERROR: S client not available

Шаблона*

Ну логично что доступ к ним хотели сделать извне иначе нафига инстансить

т.е. так в принципе нельзя делать? или нет смысла?

Так делать можно и порой нужно (например если вы хотите чтобы тело вашего шаблонного класса скомпилировалось куда-то в dll). Делать так для стандартных классов - странновато (моё предположение, что прошлый разработчик натолкнулся на проблему со статической линковкой стандартной библиотеки к dll http://www.boost.org/doc/libs/1_64_0/doc/html/boost_dll/missuses.html и пытался так её обойти)

Ппц

У меня в Лабе подгрузка функций выглядит как ваш буст дол вызов оказывается

Длл*

Сами писали?

Да лабы по винапи были

Только разбор имён я не завез

Поэтому надо писать было настоящие

Поздравляю, вы сделали всё верно

;)

Кстати magic_get расширяем? ну если мне хочется както спецефично определить get для типа например?

типа field_info

А какой именно специфики хочется добавить?

А какой именно специфики хочется добавить?

О, я хотел бы уметь получать tuple из указателей на поля! struct A { int a; float b; } auto fields = magic_field_get<A>(); fields == std::tuple<int A::*, float A::*>(&A::a, &A::b);

https://kristerw.blogspot.ru/2017/05/interprocedural-optimization-in-gcc.html

О, я хотел бы уметь получать tuple из указателей на поля! struct A { int a; float b; } auto fields = magic_field_get<A>(); fields == std::tuple<int A::*, float A::*>(&A::a, &A::b);

Хм... сходу не могу придумать, как такое сделать из коробки

Хм... сходу не могу придумать, как такое сделать из коробки

Так ведь есть сейчас get<I>, который выдаёт знает тип и смещение поля. Подсовываем ему std::declval<T>, кастуем к указателям. Или так не сработает?

Хотя, вижу проблему в том, что для получения значений указателей придётся походить около UB

Просто скастовать не получится - указатель на поле/функцию класса на самом деле 2 указателя + пачка костылей на некоторых платформах, чтобы это знание скрыть от пользователя. Просто reinterpret_cast не поможет

Так вроде ж указатель на поле - это просто смещение от начала структуры?

С функциями ясно, там всякая виртуальность мешает

Так вроде ж указатель на поле - это просто смещение от начала структуры?

А ведь верно. Но циферку offset кастовать к типу 'указатель на поле' - это UB. Добавлять пока такое не хочется

А ведь верно. Но циферку offset кастовать к типу 'указатель на поле' - это UB. Добавлять пока такое не хочется

Печально, ну ладно

...

сейчас изобрели какой-нибудь новый модный способ узнать существует ли метод у класса?

да, называется detection idiom

где он находится?

в гугле, на SO, в крутых либах