Kae*_*Rin 7 c++ strict-aliasing language-lawyer vulkan
所以最近我一直在使用Vulkan-Hpp(Vulkan Api的官方c ++绑定,Github Link)。
查看源代码,我发现它们围绕本机Vulkan结构(例如vk::InstanceCreateInfo环绕VkInstanceCreateInfo)创建包装器类。(注意:环绕而不是源自)
调用本地Vulkan API时,将指向包装类的指针reinterpret_cast编入本地Vulkan结构中。使用示例vk::InstanceCreateInfo:
//definition of vk::InstanceCreateInfo
struct InstanceCreateInfo
{
/* member function omitted */
private:
StructureType sType = StructureType::eInstanceCreateInfo;
public:
const void* pNext = nullptr;
InstanceCreateFlags flags;
const ApplicationInfo* pApplicationInfo;
uint32_t enabledLayerCount;
const char* const* ppEnabledLayerNames;
uint32_t enabledExtensionCount;
const char* const* ppEnabledExtensionNames;
};
//definition of VkInstanceCreateInfo
typedef struct VkInstanceCreateInfo {
VkStructureType sType;
const void* pNext;
VkInstanceCreateFlags flags;
const VkApplicationInfo* pApplicationInfo;
uint32_t enabledLayerCount;
const char* const* ppEnabledLayerNames;
uint32_t enabledExtensionCount;
const char* const* ppEnabledExtensionNames;
} VkInstanceCreateInfo;
//And the usage where reinterpret_cast takes place
template<typename Dispatch>
VULKAN_HPP_INLINE ResultValueType<Instance>::type createInstance( const InstanceCreateInfo &createInfo, Optional<const AllocationCallbacks> allocator, Dispatch const &d )
{
Instance instance;
Result result = static_cast<Result>( d.vkCreateInstance( reinterpret_cast<const VkInstanceCreateInfo*>( &createInfo ), reinterpret_cast<const VkAllocationCallbacks*>( static_cast<const AllocationCallbacks*>( allocator ) ), reinterpret_cast<VkInstance*>( &instance ) ) );
return createResultValue( result, instance, VULKAN_HPP_NAMESPACE_STRING"::createInstance" );
}
Run Code Online (Sandbox Code Playgroud)
所以我的问题是:vk::InstanceCreateInfo和VkInstanceCreateInfo是两种不同的类型。此外,VkInstanceCreateInfo是标准布局,但vk::InstanceCreateInfo不是(因为它具有混合的访问说明符)。这reinterpret_cast两种类型的指针之间的ing 是Vulkan-Hpp合法的吗?这是否违反严格的别名规则?
注意:在这种情况下,您可以假定VkInstanceCreateFlags和vk::InstanceCreateFlags可以互换(否则将使我的问题递归)
就标准而言,是的,vk::InstanceCreateInfo通过指向对象的指针访问VkInstanceCreateInfo对象违反了严格的别名。即使两种类型都是具有等效布局的标准布局,它仍然会违反严格的别名。该标准不允许您假装一种类类型是另一种类,即使它们具有等效的布局。
所以这段代码依赖于一些特定于实现的行为。
Is that wrong? Would doing an additional copy for every single Vulkan interface function call make you feel better about it, even if it would work without it? It's ultimately up to you how much UB you feel like tolerating.
| 归档时间: |
|
| 查看次数: |
145 次 |
| 最近记录: |