[PATCH v3 1/3] drm/xe: Add helpers for manipulating macro arguments
Andy Shevchenko
andriy.shevchenko at linux.intel.com
Mon May 6 13:59:43 UTC 2024
On Mon, May 06, 2024 at 03:17:32PM +0200, Michal Wajdeczko wrote:
> On 03.05.2024 17:59, Andy Shevchenko wrote:
> > On Fri, May 03, 2024 at 12:33:11AM +0200, Michal Wajdeczko wrote:
...
> >> +#define DROP_FIRST(args...) __DROP_FIRST(args)
> >> +#define __DROP_FIRST(a, b...) b
> >
> >> +#define PICK_FIRST(args...) __PICK_FIRST(args)
> >> +#define __PICK_FIRST(a, b...) a
> >
> >> +#define PICK_LAST(args...) __PICK_ARG(COUNT_ARGS(args), args)
> >
> > All but these have ARG(S) in the name, I would add it.
>
> but then final names will be IMO little too long
>
> DROP_FIRST_ARG
> PICK_FIRST_ARG
> PICK_LAST_ARG
>
> maybe
> FIRST_ARG and LAST_ARG
>
> would work still have no idea for the replacement for DROP_FIRST
> (and likely DROP/PICK FIRST will be more frequently used than LAST)
Works for me.
> besides, CONCATENATE also doesn't have ARGS in it's name
Yes, but it's not a good argument (pun is accidental).
> >> +#define __PICK_ARG(n, args...) CALL_ARGS(CONCATENATE(PICK_ARG, n), args)
> >
> > Interesting, why FIRST and LAST are not symmetrical. Maybe the first
> > counterpart can use the __PICK_ARG()?
>
> the PICK_FIRST could be defined without introducing PICK_LAST combo
>
> and PICK_LAST was initially considered less important (but still serves
> as a part of the complete solution) and it is implemented based on
> simpler (and more likely accepted) PICK_FIRST and DROP_FIRST macros
>
> since series is now already merged to Xe,
How comes? I have not being notified. I assume we are still in the settling
down phase.
> I guess we can return to this
> discussion when we will be promoting these macros to linux/args.h
I would fix the namings right away, it will really help to avoid possible
and unneeded collisions.
--
With Best Regards,
Andy Shevchenko
More information about the Intel-xe
mailing list