On Wed, Feb 22, 2023 at 08:17:09AM +0000, Richard W.M. Jones wrote:
> > We may still want some division of:
> >
> > DEFINE_VECTOR_TYPE (int_vector, int);
> > DEFINE_POINTER_VECTOR_TYPE (string_vector, char *, free);
> >
> > where under the hood, DEFINE_POINTER_VECTOR_TYPE(type, base, fn)
> > invokes both DEFINE_VECTOR_TYPE(type, base) and
> > DEFINE_VECTOR_EMPTY(type, fn), or whatever we name the second
> > function.
I quite like Eric's suggestion, but it's probably too much complexity
for this patch series.
> This is doable, but I hope it's not expected that
> DEFINE_POINTER_VECTOR_TYPE() *enforce* that the element type be a pointer :)
You might ignore this for a first draft, but it is apparently possible
to statically detect this (at least, if using GCC/clang):
https://stackoverflow.com/questions/19255148/check-if-a-macro-argument-is...
That particular question worries about a macro that compiles without
error for both pointer and scalar types as arguments; a simpler macro
compiles correctly for pointers (and perhaps an array that decays to a
pointer, if we want that), while causing compilation error on a
scalar, reinforcing that it is an error to use the macro on a
non-pointer. But ideas about the future don't need to hold up the
present.
> > ADD_VECTOR_EMPTY_METHOD() instead of DEFINE_VECTOR_EMPTY()
works for
> > me.
>
> OK, ADD_VECTOR_EMPTY_METHOD() can work with the above.
This sounds fine for now, and since these are implementation details
we can always revisit them in future.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org