On Wed, Apr 13, 2016 at 11:53 AM, Jose Fonseca <[email protected]> wrote:
> On 13/04/16 19:35, Jason Ekstrand wrote: > >> >> >> On Wed, Apr 13, 2016 at 10:19 AM, Emil Velikov <[email protected] >> <mailto:[email protected]>> wrote: >> >> From: Jose Fonseca <[email protected] <mailto:[email protected]>> >> >> Not supported by MSVC, and completely unnecessary -- inline functions >> work just as well. >> >> NIR_SRC_INIT/NIR_DEST_INIT could and probably should be replaced by >> the >> inline functions. >> >> Cc: Jason Ekstrand <[email protected] <mailto:[email protected] >> >> >> >> >> --- >> >> Jason, I believe you (used to) have an alternative in the vulkan >> branch. >> This approach looks more reasonable imho, although I don't feel >> strongly >> either way. >> >> -Emil >> --- >> src/compiler/nir/nir.h | 18 ++++++++++++++++-- >> 1 file changed, 16 insertions(+), 2 deletions(-) >> >> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h >> index ebac750..0adadc2 100644 >> --- a/src/compiler/nir/nir.h >> +++ b/src/compiler/nir/nir.h >> @@ -503,7 +503,14 @@ typedef struct nir_src { >> bool is_ssa; >> } nir_src; >> >> -#define NIR_SRC_INIT (nir_src) { { NULL } } >> +static inline nir_src >> +nir_src_init(void) >> +{ >> + nir_src src = { { NULL } }; >> + return src; >> +} >> + >> +#define NIR_SRC_INIT nir_src_init() >> >> >> Is this a problem in C or only in C++? >> > > IIRC, the problem was with C. > > If it's only a problem in C++, >> another option (and I've written this patch before) is to do >> >> #ifdef _cplusplus >> #define NIR_SRC_INIT nir_src() >> #else >> #define NIR_SRC_INIT { { NULL } } >> #endif >> >> and the same for NIR_ALU_SRC_INIT, NIR_DST_INIT, etc. >> > > But is there any thing to be gained by using { { NULL } } as opposed to > the inline? Is the generated code better, or error messages cleaner or > something like that? > I don't know. What I'd really prefer is #define NIR_SRC_INIT ((nir_src) { { NULL } }) which is type-safe but doesn't work in C++. > Generally speaking inlines tend to have much better characteristics that > macros (e.g, in this case, type safety). > I guess I'm ok with the inline. I think it's ugly and nasty but the compiler should get rid of it just fine.
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
