Re: [ros-dev] GDI_TABLE_ENTRY structure

[Alex Ionescu]

I don't know --maybe--, but then you end up with dozens of structure
definitions.
Bitfields are simply a bad idea in this scenario because some of the
code needs to be performant, and you can't trust the compiler to
generate the best possible code to access a member. With a mask/shift,
you can. There's been lots of codegen errors by GCC in the past due to
bitfields. I just talked with someone in my office who agrees on this
issue, having worked with GCC pretty much since day one :)
Also, treating the various GDI objects as unions is also pretty wrong
-- they're not unions anymore, as the structure *changes* depending on
the object. This means you'll be passing around a union, and all the
code will have to check its type. By using separate containers for
each object, you have type-safe code and more efficient design.
On 8/30/07, James Tabor
<jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote:
>   Alex Ionescu wrote:
> >   Hey,
> >  Yes I was in a hurry, sorry.
> >  1) a. Modifying a well known, Microsoft-documented structure.
> >       b. Using structure-based bit logic instead of shifts and masks.
> >  2) a. I think this is clear.
> >       b. I think it makes the code less maintainable, harder to
> >  understand, less clean, and potentially hurts performance. This
> >  becomes a significantly bigger problem when thinking about other
> >  architectures with alignment requirements, or different endianness.
> >  3) Use macros to hide away the mask/offsets, or better yet, inlined functions.
> >  
>  Could we use _X86_ for one structure type and have the other too?
>  Thanks,
>  James
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
--
Best regards,
Alex Ionescu