[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 at 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 at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>


-- 
Best regards,
Alex Ionescu