Vulkan API — (vkEnumeratePhysicalDevices() == VK_ERROR_INITIALIZATION_FAILED) = true

ИМХО деструктор пусть продолжает делать vkDestroyInstance( instance, nullptr ); Просто не особо логично удалять Instance пока прога всё нуждается в вулкане, если задуматься над семантикой этого самого Instance.

да — но енто происходит просто из-за передачи по значению. Я же хз — имеет ли смсл вообще передавать инстанс хендл не по значению?
все же наверна переделаю — сделаю типа отдельный метод разрушения.

Я же хз — имеет ли смсл вообще передавать инстанс хендл не по значению

Если он у тебя объект в полном смысле слова, то только запрет на копирование и только по ссылке пусть гуляет.

Если он у тебя что-то навроде дескриптора, то естественно, ЛОМАТЬ надо отдельным методом )

Мне больше нравятся полноценные объекты. От них как-то надёжностью веет ) и, что чуть ли не важнее, не воняет человекомерзким COM с его AddRef, Release, и прочим :D

Ага, мне уже пояснили.

Однако мне нравится, как люди игнорируют грабли с vector и initializer_list. Вроде как в этот раз не наступили, значит норм.

Я тоже больше люблю круглые скобки в инициализаторах. Даже если внутри круглых – фигурные (initializer_list) :D

Просто стараюсь «бережно» относиться к коду, не навязывая своего вкуса фломастеров и образа мысли ))

Ну и да, контекстно заменить все фигурные на круглые - это напрягаться надо :D

А тут пару амперсандов нарисовать и вперёд :D

Так то можно докопаться и до того, что «а чего это VkPhysicalDevice и VkDevice в разных классах», «а чего это не учтена очевидная точка роста – поддержка не только xcb» и прочее, прочее, прочее.

так енто не у меня — я про VkInstance от vulkan api

Так то можно докопаться и до того, что «а чего это VkPhysicalDevice и VkDevice в разных классах»

ну тут физ девайсы внутри девайса — там же мне нафиг енти физ девайса снаружи обертки ненужны — мне по сути нужны именно логические — которые будут в коде уже с апи участвовать — а физические нужны что бы создать логические... по ентмоу енто встроенный отдельный класс.

а чего это не учтена очевидная точка роста – поддержка не только xcb

тут все еще проще — мне надо для композитного менеджера именно поддержка только xcb — остальное пока лесом.

В данном конкретном случае логичнее именно что ссылку (или указатель) на Instance иметь. Потому что семантически инстанц не часть набора VkDevice-ов и владение им не должно переходить ни к конструктору, ни к лямбде, ни к Devices.

Мы говорим о разных вещах. Ты — о том, как успользовать инстанс. Я — о его интерфейсе. Если сделать интерфейс строже (запретить копирование), то ты не сможешь использовать инстансы неправильно (по ошибке скопировать например).

А move-семантика нужна, чтобы иметь возможность передать владение инстанса. Это не имеет никакого отношения к тому, как он передается в обычные функции.

#include <vulkan/vulkan_core.h>
#include <xcb/xcb.h>
#include <vulkan/vulkan_xcb.h>

А нафига это? все это подключается в vulkan/vulkan.h Для xcb достаточно добавить дефайн VK_USE_PLATFORM_XCB_KHR

И почему бы не воспользоваться готовым vulkan.hpp, который уже лежит рядом с vulkan.h ?

А нафига это? все это подключается в vulkan/vulkan.h Для xcb достаточно добавить дефайн VK_USE_PLATFORM_XCB_KHR

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

И почему бы не воспользоваться готовым vulkan.hpp, который уже лежит рядом с vulkan.h ?

а по нему доки есть? я чот не видел покачто. но да надо обязатиельно заглянуть туда.

https://github.com/KhronosGroup/Vulkan-Hpp/

ок спс — почитаю — вроде бегло выглядит неплоха.

А нафига это? все это подключается в vulkan/vulkan.h Для xcb достаточно добавить дефайн VK_USE_PLATFORM_XCB_KHR

чото так не взлетает — грит

ошибка: «VK_KHR_XCB_SURFACE_EXTENSION_NAME» was not declared in this scope; did you mean «VK_KHR_SURFACE_EXTENSION_NAME»?

воткни #define VK_USE_PLATFORM_XCB_KHR перед #include

а ну да — точно. спс

да — классно там получается архитектурно — мне вкатило — мой код принял такой вид:

int main() {
    vk::ApplicationInfo appInfo { .pApplicationName = "vulkan_xcb",
                                  .applicationVersion =
                                  VK_MAKE_VERSION( 0, 0, 1 ),
                                  .pEngineName = "vulkan_xcb_engine",
                                  .engineVersion =
                                  VK_MAKE_VERSION( 0, 0, 1 ),
                                  .apiVersion = VK_API_VERSION_1_0 };

    auto instance =
    vk::createInstance( { .pApplicationInfo = &appInfo } );

    std::vector< vk::PhysicalDevice > physDevices =
    instance.enumeratePhysicalDevices();

    for ( auto && physDevice : physDevices )
        std::cout << physDevice.getProperties().deviceName
                  << std::endl;

    return EXIT_SUCCESS;
}

Ну это понятно. Но тут легко отстрелить себе ногу. А я язык этот знаю не очень, вообще не заметил

ТС, ты бы не завязывался на X, кстати

чойта? — у меня цель сделать композитный менеджер для иксов...

А, ну ладно. Если спецом для иксов.

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

внутренней кросплатформенной поддержки нету у вулкана жеж

Вулкану вообще пофиг, с какой платформой работать

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

я именно об ентом указывал

Прототип ибо most vexing parse.

«most vexing parse» называется правило разрешения синтаксической неоднозначности между объявлением функции с параметрами и передачей аргументов в конструктор при объявлении переменной. В случае Instanse instanse(); неоднозначности нет, это может быть только объявлением функции без параметров.

В случае Instanse instanse(); неоднозначности нет, это может быть только объявлением функции без параметров.

Откуда взялось требование наличия параметров? Instance instance(); это также вызов конструктора без параметров.

Грамматика инициализатора не допускает пустых круглых скобок, так что T x(); нельзя распарсить как объявление переменной x с инициализатором ().

У Мейерса по поводу скобок в инициализации сказано всегда использовать фигурные, чтобы нее нарываться на вот такое, что у ТСа случилось.

И правда. Но толку с этого… Только нерегулярность добавили. По крайней мере я не вижу, где оно ведёт себя иначе по сравнению с most vexing parse.

У Мейерса по поводу скобок в инициализации сказано всегда использовать фигурные

Я так пробовал однажды, оно плохо читается.

как же так — ведь в конструкторе ты можешь инициализировать после двоеточия с пустыми круглыми скобками — типа

Type::Type() : var() {}

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

как же так — ведь в конструкторе ты можешь инициализировать после двоеточия с пустыми круглыми скобками — типа

Type::Type() : var() {}

У member initializer-ов своя грамматика.

а кто мешает сделать так?

Type::Type() : var{} {}

С взялся тут этот вопрос?