On Wed, Jul 20, 2022 at 12:03 AM Zebediah Figura zfigura@codeweavers.com wrote:
On 7/19/22 15:21, Francisco Casas wrote:
Hello,
On 19-07-22 05:11, Giovanni Mascellani wrote:
Hi,
Il 15/07/22 03:23, Francisco Casas ha scritto:
+/* Given a type and a component index, retrieves next path index required to reach the component.
- *typep will be set to the subtype within the original type that
contains the component.
- *indexp will be set to the index of the component within *typep.
- */
+static unsigned int subtype_index_from_component_index(struct hlsl_ctx *ctx,
struct hlsl_type **typep, unsigned int *indexp)
I guess that the "p"'s in "typep" and "indexp" are a sort of reverse Hungarian notation. It's a nitpick, but I am not really a fan of that, and I don't think we're using that anywhere in the HLSL compiler.
I didn't think on Hungarian notation, but I indeed added the 'p' to indicate that this is a "pointer to" the actual value.
Because the referenced values (*typep and *indexp) have to be used several times, and typep is a double pointer, I assigned these values to local variables:
struct hlsl_type *type = *typep; unsigned int index = *indexp;
Which is my opinion makes it far more readable that constantly using the dereference operator.
The problem is that I had to pick a different name for the local variables an the function arguments.
But, unless there is another suggestion, in v3 I am renaming the pointers "typep" and "indexp" to "type" and "index" respectively, and the values from "type" and "index" to "type_val" and "index_val" respectively.
Personally I prefer the former, and don't particularly mind the -p suffix. Perhaps "type_ptr" would be more palatable.
From a general naming viewpoint, yes I think it would be. "typep"
looks pretty ugly to me...