On Wednesday, October 28, 2015 05:04:07 PM Ian Romanick wrote:
> On 10/28/2015 04:43 PM, Connor Abbott wrote:
> > On Wed, Oct 28, 2015 at 7:06 PM, Ian Romanick <i...@freedesktop.org> wrote:
> >> On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
> >>> ---
> >>> src/glsl/nir/nir.h | 19 +++++++++++++++
> >>> src/glsl/nir/nir_pass.c | 64
> >>> ++++++++++++++++++++++++++++++++++++++++++++++++-
> >>> 2 files changed, 82 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> >>> index e3777f9..069c7c1 100644
> >>> --- a/src/glsl/nir/nir.h
> >>> +++ b/src/glsl/nir/nir.h
> >>> @@ -1582,6 +1582,25 @@ typedef struct nir_shader {
> >>> foreach_list_typed(nir_function_overload, overload, node, \
> >>> &(func)->overload_list)
> >>>
> >>> +typedef struct nir_pass {
> >>
> >> A couple years ago Kristian, with the support of everyone, waged a war
> >> on 'typedef struct foo { ... } foo;' Has this awful idiom really risen
> >> from the dead? Can we please send it back to the grave?
> >
> > (flamewar incoming!)
> >
> > Yes, it has, and no.
> >
> > In case you haven't read any NIR code, NIR uses this all over the
> > place -- all of the core datastructures are typedef'd. The only
> > argument I've heard against this practice, from Linus, is that it
> > makes telling if a value is a lightweight thing, like an integer, or
> > not. But this isn't the kernel; we don't use typedefs for integers at
>
> But that it is the way *this* project has done things. We made a
> conscious decision to do them that way. I don't think you guys had any
> right to unilaterally decide to change that.I don't think it's as clear cut as that. Most of the GLSL compiler was written in C++, and so the compiler code constantly referred to objects without using 'struct' or 'class'. See every piece of code that deals with ir_variable, ir_assignment, and so on. When Connor wrote NIR in C, he chose to make this similar to the existing code. Instead of ir_variable, you have nir_variable - not "struct nir_variable". Yes, it's different than most Mesa C code. But it's more similar to existing Mesa compiler code. If people are that passionate about typedefs being good-or-evil, then we should just make a decision, and write patches to make the style what the majority of people working on the project want. Personally, I think it would be much more interesting and worthwhile to discuss the merits of a pass management infrastructure, and offer feedback about Jason's design and implementation... Let's try to keep it civil...burning bridges with our fellow hackers is another great way to wound a project... --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
