Vulkan 结构的许多小类还是一个大类？答案

【问题标题】：Many small classes for Vulkan structs or one BIG class?Vulkan 结构的许多小类还是一个大类？
【发布时间】：2026-01-01 08:15:02
【问题描述】：

我正在学习 vlukan，并在他们的主页上完成了教程，直到您在屏幕上看到第一个三角形。在本教程中，所有内容都放入 main.cpp 中，并且可以轻松增长超过 1000 LOC。

我想强调我的目标是更多地了解 C++ 以及它在“幕后”的行为方式。

现在我的问题是我是否应该将这个大类重构为多个小类，以及这对编译后的代码有什么影响：

假设我想要以下：

VkInstance

为此我需要以下内容：

VkInstanceCreateInfo（结构体创建又需要的实例）

std::vector<VkLayerProperties>（图层属性数组，例如支持 GLFW 窗口）

std::vector<const char*>（扩展名数组，例如要写入控制台的调试工具）

我的想法是创建我自己的类的以下结构：

class Instance{
    InstanceLayers layers;
    InstanceExtensions extensions;
};

在构造函数中，我将拥有以下内容：

Instance::Instance(){
    ...
    const auto requiredExtensions = extensions->getExtensions();
    ...
}

编译器会在这里用代码替换整个函数调用还是会创建一个跳转？如果经常发生跳跃是不是很糟糕？我可以在哪里阅读有关此主题的信息？

【问题讨论】：

这些都是非常广泛的问题，这使得它不适合 SO。此外，每个问题都应该限制在一个问题上，你一次问了太多事情。关于性能：不可能从这样一个模糊的想法中分辨出来，性能应该根据具体的实现来衡量
关于国防部：您根本没有在这里提到任何类型的输入数据。在主要是网格和纹理的 3D 渲染中，它与您的渲染 API 本身几乎没有关系（除了 API 可能支持有助于处理您的数据的某些操作）
std::vector<VkLayerProperties> 已经使用 RAII 进行分配和清理。你的班级会有什么不同？
Don't reinvent the wheel
类从来都不是必需的。任何可以用类完成的事情都可以在没有类的情况下完成，只是需要更多的代码。

标签： c++ assembly compilation vulkan project-structure

【解决方案1】：

由于 3D 图形不会以渲染单个三角形结束，因此有一个建议。

尝试使用多个图像渲染多个复杂的网格和/或使用不同的渲染模型进行照明。在此过程中，您将遇到许多挑战，以将 Vulkan 代码保持在最低限度。例如，您不想复制“n”粘贴着色器模块加载/创建代码、纹理加载代码等。渲染通道和帧缓冲区（用于离屏渲染，不是教程中唯一的交换链和隐式图像视图）、管道和描述符集- 这些是你最关注的，需要管理的项目。对您来说，初始化过程和扩展列表的表示不太可能是最大的问题。

祝你好运掌握 C++（无论你是否使用类）。更实际一点，不要试图从一开始就优化一切。通常，泛化来自于从很多情况下已经编写的代码中提取相似的部分，而不是从头开始。

【讨论】：