-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flag enum types and flags typedefs #159
Comments
i.e. #ifdef __cplusplus
WGPUBufferUsage operator|(WGPUBufferUsage a, WGPUBufferUsage b) {
return static_cast<WGPUBufferUsage>(a | b);
} and so on |
FWIW, we copied this pattern from Vulkan: in any case, whatever we do, we need to make sure it works fully in both C and C++. |
Adding operators only in C++ if that's where it causes problems would make sense. We could have something similar to Dawn's
Yeah right now webgpu.h doesn't work in C because of #84 even. |
A Dawn contributor just so happened to find a pattern just like this in mingw's #ifdef __cplusplus
#define DEFINE_ENUM_FLAG_OPERATORS(ENUMTYPE) \
extern "C++" { \
inline ENUMTYPE operator | (ENUMTYPE a, ENUMTYPE b) { return ENUMTYPE(((int)a) | ((int)b)); } \
... |
meeting: agreed to do that, to patch over the difference between C and C++. However I forgot that the original point of this issue was whether we wanted to get rid of the *Flags types, as we don't need this change otherwise (in C++, |
Obsoleted by #273 due to replacing all bitflag enums with uint64_t. |
Originally posted by @mrshannon in #158 (comment):
This is strictly true, but in Dawn's C++ bindings we also have operator overloads, so when you do
wgpu::BufferUsage::CopySrc | wgpu::BufferUsage::CopyDst
you get awgpu::BufferUsage
value. In CWGPUBufferUsage_CopySrc | WGPUBufferUsage_CopyDst
will give you an int of some kind. So this would force callers of the API to cast back to the appropriate type.Apparently, the cast is only needed in C++. C seems happy without a cast. So I guess we could define operator overloads for these types behind
#ifdef __cplusplus
...?The text was updated successfully, but these errors were encountered: