Возможно ли достичь аргумента с нескольким определением типа?

Question

[Евгений Иванович]

В С++ не хватает определения функций с множественным типом аргумента. Может это как то можно по другому написать?

псевдокод

inline PFN_vkVoidFunction vulkanGetProcAddress(const VkInstance & device, const std::string & name) {return vkGetInstanceProcAddr(device, name.c_str());}
        inline PFN_vkVoidFunction vulkanGetProcAddress(const VkDevice & device, const std::string & name) {return vkGetDeviceProcAddr(device, name.c_str());}

|
|
|
^

 inline PFN_vkVoidFunction vulkanGetProcAddress(const [VkInstance | VkDevice] & device, const std::string & name) {return

Можно попробовать добавить через метарасширения путем модернизации компилятора llvm, но я не умею, если знаете - можете подсказать, желательно с примерами.

Comments

[jcmvbkbc]

inline PFN_vkVoidFunction vulkanGetProcAddress(const VkInstance & device,
                                               const std::string & name)
{return vkGetInstanceProcAddr(device, name.c_str());}

inline PFN_vkVoidFunction vulkanGetProcAddress(const VkDevice & device,
                                               const std::string & name)
{return vkGetDeviceProcAddr(device, name.c_str());}

Может это как то можно по другому написать?

А в приведённой записи что не устраивает?

[Евгений Иванович]

jcmvbkbc, Почти идентичные функции, различающиеся по первому типу VkDevice и VkInstance .

[jcmvbkbc]

Евгений Иванович, на мой взгляд всё прекрасно в этих двух функциях.

Можно попробовать добавить через метарасширения путем модернизации компилятора llvm,

Модификация компилятора и расширение языка для добавления синтаксического сахара -- это создание себе проблем на ровном месте и в данном случае выглядит совершенно неоправданно.

[Евгений Иванович]

jcmvbkbc, зато возможно и даже осуществимо.

[mayton2019]

Непонятно при чем здесь LLVM? Это вообще не его задача и его уровень. Это как раз задача уровня языка С++.

В Scala 3 подобное поведение описывается через union type. Но внутри функции ты все равно обязан
отработать паттерн-матчинг к двум типам. Поэтому выигрыш неочевиден. Просто декларируется одна
функция вместо двух.

Если VkInstance и VkDevice - родственные типы то попробуй поработать с базовым типом. Или создай над ними типы-обертки. Это будет в духе ООП.

[Wataru]

Евгений Иванович, вопрос, а в чем смысл этого общего объявления, если определения у функций все равно разные? Там же разные функции внутри вызываются.

[Евгений Иванович]

Wataru, Одним именем функции отличается.

[Евгений Шатунов]

Евгений Иванович, в чем конкретно заключается твой вопрос?

[Mercury13]

Что там с вопросом?

[Евгений Иванович]

Mercury13, Решено.

Answer 1

[Mercury13]

Конкретно в вашем случае нет нужды извращаться, перегрузка функций — самое лучшее.

А так здесь есть два вопроса.
1. А что напишем в скобках вместо непонятного return?
2. В какой код оно должно скомпилироваться?

Пример стандартный шаблонный.

template <class Device>
SomeFunction getProcAddress(const Device& device, const std::string& name);

template <>
inline SomeFunction getProcAddress<VkInstance>(
        const VkInstance& device, const std::string& name)
  { return vkGetInstanceProcAddr(device, name.c_str()); }

Это стандартное использование шаблонов Си++ с далёкого 1998 года.

Пример через if constexpr. Си++17, значит.

template <class Device>
inline SomeFunction getProcAddress(const Device& device, const std::string& name)
{
  if constexpr (std::is_same_v<Device, VkInstance>) {
    return vkGetInstanceProcAddr(device, name.c_str());
  } else {
    // false нельзя! — проверка произойдёт в любом случае, будет компилироваться ветка или нет.
    static_assert(std::always_false_v<Device>, "Unknown type");
  }
}

Используется в функции std::visit, чтобы исполнить разный код для разных вариантов std::variant и ничего не забыть.

Что написано в скобках — ну, сами видите. Во что скомпилируется — в две разных функции.

В некоторых случаях — вероятно, не в вашем — можно ещё поиграться с виртуальным полиморфизмом.

Comments

[Евгений Иванович]

Отлично.