Support built-in offsetof macro

[tex3d]

We should consider supporting offsetof in the future. Since this normally requires stddef.h/cstddef, we should consider adding built-in version under hlsl namespace with default/auto using namespace hlsl; when compiling hlsl source.

Separating this issue from the sizeof issue microsoft/DirectXShaderCompiler#1291 to allow independent resolution.

[tristanlabelle]

Offsetof is a macro in C/C++ and it's not expressible as a normal function, so I'm not sure it could even live in a namespace.

[ehsannas]

I'm going to give up ownership of this issue as I'm not actively working on it.

[Jasper-Bekkers]

With the new addition of templated loads in ByteAddressBuffer this would be a huge win 😊

[alextardif-zmi]

Came looking for this so I guess +1 from me, for the same reason Jasper listed.

[curldivergence]

Hi! Are there any news, by any chance? :) I've tried it on a recent build from the main branch, and the error I'm getting from

offsetof(SimpleStruct, uintValue)

says 'SimpleStruct' does not refer to a value, so it looks like the macro itself is recognized by dxc, but still doesn't work?

[jshopf]

+1, would love to have this :)

[Ipotrick]

Is there any update?
In sight of RWStructuredBuffers not beeing supported in array bindings for spirv output, the only real alternative is RWByteAdressBuffer for vulkan users in a bindless model. Without offsetof writing and reading individual fields of a struct becomes very error prone and ugly, as one needs to define the offsets to struct members manually.

[SakibSaikia]

I'll add my voice to this request as well.

+1

[devshgraphicsprogramming]

metoo

[manas-kulkarni]

+1

[mcbouterse]

+1 Would be super helpful when dealing with ByteAddressBuffer

[ajmiles]

+1

[devshgraphicsprogramming]

I'm trying to make my own BDA pointer and reference structs (because I'm impatient) and offsetof is one of the things I'm missing.

#59 (comment)

and one of the things that's blocking me is the lack of decltype and offsetof, but offsetof far more.

btw __builtin_offsetof seems to be a reserved keyword in DXC, so we could have a "compiler instrinsic" like in GCC

[devshgraphicsprogramming]

the SPIR-V support could be limited to only when -fvk-scalar-layout is present to reduce implementation headaches