On 1/5/21 12:02 PM, Henri Verbeet wrote:
On Tue, 5 Jan 2021 at 18:22, Zebediah Figura (she/her) zfigura@codeweavers.com wrote:
On 1/5/21 11:12 AM, Henri Verbeet wrote:
On Tue, 5 Jan 2021 at 17:17, Zebediah Figura zfigura@codeweavers.com wrote:
@@ -41,6 +47,8 @@ struct preproc_ctx struct vkd3d_string_buffer buffer; struct vkd3d_shader_location location;
- struct list macros;
Does that need to be a list? For the purposes of this series, it seems an array would work at least as well.
It eases removal via #undef. There's also a couple places that store pointers to the macro (I think they're not in this series, but rather relate to expansion) which would complicate using a flat array at least.
Unless we care about the order, removal would essentially be "macros[idx] = macros[--macro_count];"
True; I forgot about that.
Storing pointers to macros would indeed be an issue, although I'd expect that to be an issue regardless of how macros are stored, unless you also e.g. reference count them. Either way, if it's needed for later patches that's fine.
That is true. Of course, using an array makes it worse, because now you're potentially affecting macros other than the one that's being deleted while expanded.
Incidentally, the following shader:
#define FUNC(a,b) a ## b FUNC(a, #undef FUNC b)
yields, with native d3dcompiler_47, the output "FUNC" and an error "not enough actual parameters for macro 'FUNC'".
I don't think it'd be very hard to fix up the code to make sure a macro in use can't be moved, but on the other hand it strikes me as unnecessarily fragile (wrt later reading or modification).
I also don't know how much of a performance concern this actually is.