Many small classes for Vulkan structs or one BIG class?

Question

I'm learning vlukan and did the Tutorial on their homepage up to where you see the first Triangle on the screen. Within the tutorial everything is put into the main.cpp with it growing easily over 1000 LOC.

I want to emphasize that my goal is to learn more about C++ and how it behaves "under the hood".

Now my question is if I should reafactor this giant class into multiple small ones and what this does to the compiled code:

Assuming I want the following:

VkInstance

I need the following for this:

VkInstanceCreateInfo (Struct to create the instance which in turn needs)

std::vector<VkLayerProperties> (Array of layer properties, for example to support GLFW windows)

std::vector<const char*> (Array of extension names, for example debug utils to write to the console)

My idea would be to create the following structure of my own classes:

class Instance{
    InstanceLayers layers;
    InstanceExtensions extensions;
};

Within the constructor I would have the following:

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

Would the compiler Replace the whole function call with code here or would it create a jump? Are jumps bad if they happen often and where can I read on this topic?

Those are all very broad questions, which makes this a bad fit for SO. Additionally every question should be constrained to a single one, you are asking too many things at once. And regarding performance: It's impossible to tell from such a vague idea, performance should be measured on concrete implementations — UnholySheep, Jul 16 '20 at 10:05
And regarding DOD: You haven't mentioned any kind of input data here at all. In 3D rendering that would be primarily meshes and textures, it has very little to do with your rendering API itself (except that an API might support certain operations that are helpful for processing your data) — UnholySheep, Jul 16 '20 at 10:08
`std::vector` already uses RAII to allocate and clean. What will the difference be with your class? — user253751, Jul 16 '20 at 10:09
[Don't reinvent the wheel](https://github.com/KhronosGroup/Vulkan-Hpp) — Botje, Jul 16 '20 at 10:15
@user253751 I didn't know about vector cleaning up after itself, I would call delete. But for every Vulkan struct I would call the apropriate delete function. — Bernd Eissing, Jul 16 '20 at 10:36
@Botje interesting repo i will take a look at it. I'm sure I can learn some stuff. But I'm more interested in learning Vulkan than a library for it. — Bernd Eissing, Jul 16 '20 at 10:37
@UnholySheep From your comments I understand that in DOD classes are still necessary to create the Framework and provide readability. The structure doesn't matter much as long as I ensure my data is being processed efficiently. — Bernd Eissing, Jul 16 '20 at 10:40
Classes are never necessary. Anything that can be done with classes can be done without classes, it just takes more code. — user253751, Jul 16 '20 at 10:43
Your question is now asking about micro-optimization and compiler specific behavior in the context of a constructor that you will presumably call only once during the lifetime of your program. And whether jumps are "bad" highly depends on a lot of factors, you can't just formulate a generic rule for this. In order to understand high performance optimization on an assembly instruction level you need deep knowledge of your target architecture — UnholySheep, Jul 16 '20 at 11:42
I see it's not as simple as I thought. I will look at some examples to get a better understanding of the compiler and generated assembly. — Bernd Eissing, Jul 16 '20 at 12:24

score 0 · Answer 1 · answered Sep 15 '20 at 17:32

Since 3D graphics does not end with rendering a single triangle, there is one advice.

Try rendering multiple complex meshes textured with multiple images and/or lighted with different rendering models. Along the way you will encounter lots of challenges to keep Vulkan code at a minimum. E.g., you would not want to copy'n'paste shader module loading/creation code, texture loading code etc. Render passes and framebuffers (for offscreen rendering, not the only swapchain and implicit image views from the tutorial), pipelines and descriptor sets - these are the items on which you concentrate the most and which require management. It is unlikely that for you the initialization process and the representation of extension lists is the biggest problem.

Good luck with mastering C++ (no matter if you use classes or not). Be more practical, don't try to optimize everything from the start. Usually generalization comes from extracting similar parts from the already written code for lots of cases, not from the ground up.

Many small classes for Vulkan structs or one BIG class?

1 Answers1