For instance, putting XR_EXT_debug_utils definitions into xr::ext::DebugUtils would mean that a C++ client would be able to write xr::ext::debugUtils::Messenger instead of xr::DebugUtilsMessengerEXT. Since setup and teardown will likely be using many related classes, this allows clients to declare a scoped using namespace statement and produce significantly less verbose code.

Current generated headers does not compile. The generated AsyncRequestIdFB struct in openxr_atoms.hpp uses XR_NULL_ASYNC_REQUEST_ID_FB, but this macro is actually not declared in openxr.h.

A quick workaround maybe add a global variable NO_NULL_ATOMS in cpp_generator.py and return 0 for such atoms in computeNullAtom.

As described in section 3.1.2. on the OpenXR loader design.

The design would be really similar to Vulkan-Hpp.

OpenXR-Hpp already has a the DispatchLoaderDynamic. However, in my opinion, three things are missing to make it as easy to use as in Vulkan-Hpp:

• Add an optional DynamicLoader that will explicitly link to the loader library at run-time (via LoadLibrary on Windows for example).
• Use XR_NO_PROTOTYPES to optionally remove the DispatchLoaderStatic and the calls to OpenXR C functions. Using this macro, the application doesn't have to link against the OpenXR loader at build time and can link explicitly at runtime (using the DynamicLoader or something else). XR_NO_PROTOTYPES is already in openxr.h but I haven't found a way to generate is for openxr.hpp. Did I miss something?
• Provide a XR_HPP_DEFAULT_DISPATCHER similar to VULKAN_HPP_DEFAULT_DISPATCHER. After setting this macro to a global DispatchLoaderDynamic. The developer of the application would not have to provide the dispatcher to function calls, even for extensions functions.

For a beginner like me, I really like the design in Vulkan-Hpp because I don't have to think about the dispatcher at all once it is set up, even when I use extensions. I also like that I'm not using the trampolines functions.

Would you be open to a contribution to add this? Or did I miss something in the generator that allow this?

Right now there's a hard dependency on the matching openxr.h header which isn't awesome for the current deployment model, anyway.

Each extension defined has a preprocessor macro defined as well, so we can guard e.g. the enum values with that.

The enhanced function contains this code

  XrPlaneDetectionStateEXT state_tmp;
  PlaneDetectionStateEXT state;
  Result result = static_cast<Result>(
      d.xrGetPlaneDetectionStateEXT(this->get(), state_tmp));

But the dispatcher call here expects a XrPlaneDetectionStateEXT* as it's second argument, not a XrPlaneDetectionStateEXT.

for example, ObjectType::SceneObserverMSFT is protected by XR_MSFT_scene_understanding define.
but in openxr_handles_forward.hpp there is no protect attributes in traits.
it should be like this below.
#if defined(XR_MSFT_scene_understanding)
template <>
struct cpp_type_from_object_type_enumObjectType::SceneObserverMSFT {
using type = SceneObserverMSFT;
};
#endif // defined(XR_MSFT_scene_understanding)

I would like to discuss adding support for designated initializers. It would allow to write code like this:

session.endFrame(xr::FrameEndInfo{
    .displayTime = frame_state.predictedDisplayTime,
    .environmentBlendMode = xr::EnvironmentBlendMode::Opaque,
    .layerCount = static_cast<uint32_t>(layers_pointers.size()),
    .layers = layers_pointers.data() });

I think it's an important feature as it makes code much easier to understand.

It only works on aggregates, so we would need to make some changes to the way structs are generated. The two importants one are:

• Remove the inheritance in the structs (for example remove impl::InputStructBase)
• Option to remove the constructor using a macro OPENXR_HPP_NO_CONSTRUCTOR

I had a working implementation in my fork, but they were too much change in split-headers. I would like to implement it again, but I would like to have support of this directly here.

Would you agree to have changes to the structs in order to support designated initializers?
Can a PR that removes all the inheritances in the structs be accepted? (It would still have proper default value of course)

To conclude, here is what a struct looked like in my fork (before split-headers):

struct FrameEndInfo {
#ifndef OPENXR_HPP_NO_CONSTRUCTOR
  FrameEndInfo(const Time &displayTime_ = {},
               const EnvironmentBlendMode &environmentBlendMode_ = {},
               uint32_t layerCount_ = {},
               const CompositionLayerBaseHeader *const *layers_ = nullptr)
      : displayTime{displayTime_}, environmentBlendMode{environmentBlendMode_},
        layerCount{layerCount_}, layers{layers_} {}
#endif
  operator const XrFrameEndInfo &() const {
    return *reinterpret_cast<const XrFrameEndInfo *>(this);
  }
  operator XrFrameEndInfo &() {
    return *reinterpret_cast<XrFrameEndInfo *>(this);
  }

  StructureType type = StructureType::FrameEndInfo;
  const void *XR_MAY_ALIAS next = nullptr;
  Time displayTime = {};
  EnvironmentBlendMode environmentBlendMode = {};
  uint32_t layerCount = {};
  const CompositionLayerBaseHeader *const *layers = nullptr;
};

Use of strncpy generates warnings

It's present in the originating/upstream vulkan-hpp code some of this is based on. any objections @jherico ?

(We're working on getting that added to all the openxr headers, but I think it can be added here independently.)

    return concat(self.root_render_func(self.new_context(vars)))
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-Hpp\scripts\template_openxr_structs.hpp", line 56, in root
    * but no specific type enum value of their own: these are the "base structs" in OpenXR.
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-Hpp\scripts\struct.hpp", line 316, in root
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-SDK-Source\external\python\jinja2\runtime.py", line 262, in call
    return __obj(*args, **kwargs)
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-SDK-Source\external\python\jinja2\runtime.py", line 570, in __call__
    return self._invoke(arguments, autoescape)
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-SDK-Source\external\python\jinja2\asyncsupport.py", line 110, in _invoke
    return original_invoke(self, arguments, autoescape)
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-SDK-Source\external\python\jinja2\runtime.py", line 574, in _invoke
    rv = self._func(*arguments)
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-Hpp\scripts\struct.hpp", line 126, in macro
    /*{ _makeDefaultConstructor(s) }*/
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-SDK-Source\external\python\jinja2\runtime.py", line 262, in call
    return __obj(*args, **kwargs)
  File "C:\Users\Zeury\Documents\GitHub\OpenXR-Hpp\scripts\cpp_generator.py", line 1002, in _index0_of_first_visible_defaultable_member
    raise RuntimeError("Found a non-defaultable member, errors possible elsewhere due to untested codepath.")
RuntimeError: Found a non-defaultable member, errors possible elsewhere due to untested codepath.
Generation failed while generating openxr_structs.hpp :
At C:\Users\Zeury\Documents\GitHub\OpenXR-Hpp\generate-openxr-hpp.ps1:58 char:9
+         throw "Generation failed while generating ${header} : ${proce ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Generation fail..._structs.hpp : :String) [], RuntimeException
    + FullyQualifiedErrorId : Generation failed while generating openxr_structs.hpp :

Tried a previous commit of OpenXR-SDK-Source (https://github.com/KhronosGroup/OpenXR-SDK-Source/tree/033c76dd7561730de3aee3ef623e9e5be6f551df), works fine. Probably something has broken in the 1.0.27 update?

The current version code is assuming 32 bits for major, then 16 bits for minor and 16 bits for patch. However, this is incorrect... it should be 16 bits for major, 16 bits for minor and 32 bits for patch.

https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#api-version-numbers-and-semantics

I'm trying to use the forward headers to limit the scope of my include of openxr.hpp by only using it in one cpp file.
Normally to do this, you forward declare your classes in the header files and include the full headers in the cpp files.

From the docustring, I would expect to be able to use Unique Handles like a unique ptr.

Template class for holding a handle with unique ownership, much like unique_ptr.

Below is an example, it would work if using an std::unique_ptr because the undefined deleter is referenced in the cpp file and not the header.

A.hpp

#pragma once
#include <openxr/openxr_handles_forward.hpp>
struct A {
    A();
    virtual ~A();
    xr::UniqueInstance m_instance;
};

A.cpp

#include "A.h"
#include <openxr/openxr.hpp>
A::A() = default;
A::~A() = default; // Here the deleter is defined and since it has visibility of openxr.hpp it should be okay

In practice, you get the following errors because the forward header implements functions that need full visibility of the forward declared classes and even holds an instance of the type in question.

openxr/openxr_handles_forward.hpp(140,18): error C2027: use of undefined type 'xr::Instance'
openxr/openxr_handles_forward.hpp(140,32): error C3646: 'getRawHandle': unknown override specifier
openxr/openxr_handles_forward.hpp(151,18): error C2027: use of undefined type 'xr::Instance'
openxr/openxr_handles_forward.hpp(170,8): error C2079: 'xr::UniqueHandle<xr::Instance,xr::DispatchLoaderStatic>::m_value' uses undefined class 'xr::Instance

An awkward workaround is to make m_instance into a std::unique_ptr<xr::UniqueInstance>.

Struct XrCompositionLayerPassthroughHTC provided by XR_HTC_passthrough causes a exception during generation, as it doesn't consider member XrPassthroughColorHTC color as defaultable.

RuntimeError: Found a non-defaultable member, errors possible elsewhere due to untested codepath.

The XrCompositionLayerPassthroughHTC structure is defined as:

// Provided by XR_HTC_passthrough
typedef struct XrCompositionLayerPassthroughHTC {
    XrStructureType            type;
    const void*                next;
    XrCompositionLayerFlags    layerFlags;
    XrSpace                    space;
    XrPassthroughHTC           passthrough;
    XrPassthroughColorHTC      color; // failed to generate
} XrCompositionLayerPassthroughHTC;

The XrPassthroughColorHTC structure is defined as:

// Provided by XR_HTC_passthrough
typedef struct XrPassthroughColorHTC {
    XrStructureType    type;
    const void*        next;
    float              alpha;
} XrPassthroughColorHTC;

[build] ../src/openxr.hpp: In constructor ‘constexpr xr::Version::Version()’:
[build] ../src/openxr.hpp:178:20: warning: ‘xr::Version::major’ will be initialized after [-Wreorder]
[build]    uint64_t major : 16;
[build]                     ^~
[build] ../src/openxr.hpp:177:20: warning:   ‘short unsigned int xr::Version::minor’ [-Wreorder]
[build]    uint64_t minor : 16;
[build]                     ^~
[build] ../src/openxr.hpp:170:24: warning:   when initialized here [-Wreorder]
[build]    OPENXR_HPP_CONSTEXPR Version() : major(0), minor(0), patch(0) {}
[build]                         ^~~~~~~
[build] ../src/openxr.hpp:177:20: warning: ‘xr::Version::minor’ will be initialized after [-Wreorder]
[build]    uint64_t minor : 16;
[build]                     ^~
[build] ../src/openxr.hpp:176:20: warning:   ‘unsigned int xr::Version::patch’ [-Wreorder]
[build]    uint64_t patch : 32;
[build]                     ^~
[build] ../src/openxr.hpp:170:24: warning:   when initialized here [-Wreorder]
[build]    OPENXR_HPP_CONSTEXPR Version() : major(0), minor(0), patch(0) {}
[build]                         ^~~~~~~

presumably due to the bitfieldness. I'll submit a PR with a different impl.

It turns out this might be C++11 compatible, though C++14 optimized: I got this to build in C++11 mode. https://gitlab.freedesktop.org/monado/demos/xr-print-tracker/tree/hpp

cc @jherico

I built the openxr as a static lib, I got openxr_loader.lib in the build file. and I added it into my vs project, but i cannot open the lib. Anyone can give me a hint?

generate-openxr-hpp.ps1 currently expects the Python executable to be named python3. However, that's not always the case. If you install Python via https://www.python.org/downloads/, the executable is called python, even though it's v3 and not v2. Not sure if that has changed with any particular minor version of Python. Maybe the executable downloaded from the Microsoft store is still called python3 (as alluded to in the error message below).

PS C:\dev\OpenXR-1.0.26\OpenXR-Hpp> .\generate-openxr-hpp.ps1
Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases.
Generation failed while generating openxr_atoms.hpp :
At C:\dev\OpenXR-1.0.26\OpenXR-Hpp\generate-openxr-hpp.ps1:58 char:9
+         throw "Generation failed while generating ${header} : ${proce ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Generation fail...xr_atoms.hpp : :String) [], RuntimeException
    + FullyQualifiedErrorId : Generation failed while generating openxr_atoms.hpp :

PS C:\dev\OpenXR-1.0.26\OpenXR-Hpp> python
Python 3.9.6 (tags/v3.9.6:db3ff76, Jun 28 2021, 15:26:21) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

Bottom line is that the script should be more lenient towards the name of the executable and potentially try both?

For convenience, the following code should work.

    xr::CompositionLayerFlags flags =
        xr::CompositionLayerFlagBits::BlendTextureSourceAlpha |
        xr::CompositionLayerFlagBits::CorrectChromaticAberration;

However, it fails to compile on VS 2019 with an error "No operator matches these operands"

if I manually create a freestanding xr::CompositionLayerFlags operator |(xr::CompositionLayerFlagBits a, xr::CompositionLayerFlagBits b) operator, then the code works.

Software used:

• OS: Debian GNU/Linux 10 (docker debian: bullseye-slim image)
• GCC: 10.2 from stable repository
• CMake: 3.18 from there too

Project is built with -fno-exceptions and thus OPENXR_HPP_NO_EXCEPTIONS definition is also set through CMake.

openxr loader library provided by debian and that's where I copied headers from to local directory too.

Part of file where I include headers defined preferred platform/api:

#define XR_USE_PLATFORM_EGL
#define XR_USE_GRAPHICS_API_OPENGL_ES

#include <EGL/egl.h>
#include <GLES2/gl2.h>
#include <EGL/eglplatform.h>

#include <openxr/openxr_platform.h>  // to compare extension  names
#include <openxr/openxr.hpp>

Just to clarify I tried to use openxr.hpp from release page but it didn't work due to errors similar to what I'll show next. It also is quite dated and doesn't have useful *ToVector methods.

Because of that I cloned both OpenXR-SDK-Source and OpenXR-HPP repositories and tried:

• building everything from master and copying results (including fresh openxr*.h files)
• building release-1.0.20 and copying results
• building release-1.0.10 and copying resuls (that is the version Debian has in its repositories)

So, when I build project I'm getting a huge amount of errors related to openxr_*.hpp files.
There are no syntax errors in my code or API misuse as far as I could see and errors mostly about types that I don't use at all.

I am attaching log file with build output:
openxr-hpp.txt

Apparently because Result::SpaceBoundsUnavailable is not treated as an error condition.

This would probably be something that would require some small amount of maintaining a customizer structure in the generation code, but there are a number of places where structures will be initialized to 0 when 1 would be a much better choice. The most apparent I can think of is within the SwapchainCreateInfo, where I can't think of a good reason not to default arraySize, sampleCount and faceCount to 1, since 0 is never a valid value for any of these.

I'm also tempted to suggest that the xr::ExtentXXX structures default to 1 or 1.0f, but I'm less certain if there's ever a legitimate use case for setting those values to 0.