Confusing Jumps in code style between nested for loops and nested lambda functions

Xem xét các phần được trích dẫn Instances, Validation Layers, Logical Device and Queues và Window Surfaces, so sánh các ví dụ về vòng lặp và lambda của chúng cùng những phần giải thích xung quanh. Quyết định xem tutorial có cần một phong cách nhất quán hay một phần giải thích về những khác biệt hay không; được xem là hoàn thành khi các ví dụ và hướng dẫn bị ảnh hưởng đưa ra một cơ sở rõ ràng, mạch lạc.

Hello!

Im quite new to all of this, i hope it's okay that i give some feedback coming from my experience with the tutorial. Even if my own specific solutions are inadequate for any reason, at least it might help with identifying some potential issues :)

Ive been going through the beginning stages of the newer tutorial and keep seeing quite dramatic jumps in the examples when it comes to style of code. I'm wondering if there is a reason for this back and forth that is lost one me, as i am quite new to graphics APIs as a whole?

Someone else had opened an issue on Hard to read lambda formatting, and from there i got the impression, that the examples are written in a lambda style, in an attempt to make understanding them easier, while also having some optimization benefits. If that's the case, I'm still left a little confused on why some examples are fully in a lambda style, while others are not. Wouldn't it make sense to write all examples in a lambda style from the get go?

Being a little more specific, in the chapter on Instances, where there is talk about making sure that all of the GLFW required extensions are supported by the Vulkan implementation, the example code given looks like this. A for loop with a lambda in it:

// Get the required instance extensions from GLFW.
uint32_t glfwExtensionCount = 0;
auto glfwExtensions = glfwGetRequiredInstanceExtensions(&glfwExtensionCount);

// Check if the required GLFW extensions are supported by the Vulkan implementation.
auto extensionProperties = context.enumerateInstanceExtensionProperties();
for (uint32_t i = 0; i < glfwExtensionCount; ++i)
{
    if (std::ranges::none_of(extensionProperties,
                             [glfwExtension = glfwExtensions[i]](auto const& extensionProperty)
                             { return strcmp(extensionProperty.extensionName, glfwExtension) == 0; }))
    {
        throw std::runtime_error("Required GLFW extension not supported: " + std::string(glfwExtensions[i]));
    }
}

Later on in the next chapter on validation layers, we get the same code with a small refactor in the form of a wrapper function for glfwGetRequiredInstanceExtensions(). But now the body of the function is all of a sudden, a nested lambda function with no for loop at all:

void createInstance()
{
    ...

		// Get the required extensions.
		auto requiredExtensions = getRequiredInstanceExtensions();

		// Check if the required extensions are supported by the Vulkan implementation.
		auto extensionProperties = context.enumerateInstanceExtensionProperties();
		auto unsupportedPropertyIt =
		    std::ranges::find_if(requiredExtensions,
		                         [&extensionProperties](auto const &requiredExtension) {
			                         return std::ranges::none_of(extensionProperties,
			                                                     [requiredExtension](auto const &extensionProperty) { return strcmp(extensionProperty.extensionName, requiredExtension) == 0; });
		                         });
		if (unsupportedPropertyIt != requiredExtensions.end())
		{
			throw std::runtime_error("Required extension not supported: " + std::string(*unsupportedPropertyIt));
		}

    ...
}

Later on in the tutorial the inverse of this happens, where lambda functions appear at first, but later disappear completely.
In the chapter Logical Device and Queues, we are given a code example with a lambda in it:

std::vector<vk::QueueFamilyProperties> queueFamilyProperties = physicalDevice.getQueueFamilyProperties();
auto graphicsQueueFamilyProperty = std::ranges::find_if(queueFamilyProperties, [](auto const &qfp) { return (qfp.queueFlags & vk::QueueFlagBits::eGraphics) != static_cast<vk::QueueFlags>(0); });
auto graphicsIndex = static_cast<uint32_t>(std::distance(queueFamilyProperties.begin(), graphicsQueueFamilyProperty));
vk::DeviceQueueCreateInfo deviceQueueCreateInfo { .queueFamilyIndex = graphicsIndex };

And then next chapter on Window Surfaces, we get an example with no lambda functions at all, when refactoring the code to also check that the queue supports presenting:

 // find the index of the first queue family that supports graphics
    std::vector<vk::QueueFamilyProperties> queueFamilyProperties = physicalDevice.getQueueFamilyProperties();

    // get the first index into queueFamilyProperties which supports both graphics and present
    uint32_t queueIndex = ~0;
    for (uint32_t qfpIndex = 0; qfpIndex < queueFamilyProperties.size(); qfpIndex++)
    {
      if ((queueFamilyProperties[qfpIndex].queueFlags & vk::QueueFlagBits::eGraphics) &&
          physicalDevice.getSurfaceSupportKHR(qfpIndex, *surface))
      {
        // found a queue family that supports both graphics and present
        queueIndex = qfpIndex;
        break;
      }
    }
    if (queueIndex == ~0)
    {
      throw std::runtime_error("Could not find a queue for graphics and present -> terminating");
    }

The solution i would think of for this, is just sticking to one style from start to finish to reduce confusion. A little explanation as to why lambda functions should be preferred in the context of Vulkan, would also help of course.

I Hope this was at least somewhat helpful, and if it wasn't, feel free to delete it :). I also want to say thank you to everyone who is working on this. Despite it's flaws, it's still an amazing resource to learn from, and putting all of it together is a lot of work, for which i think the whole community is grateful :)