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@adsl-64-217-116-74.dsl.hstntx.swbell.net wrote:
Alex Ionescu wrote:
Hey,
Yes I was in a hurry, sorry.
- a. Modifying a well known, Microsoft-documented structure. b. Using structure-based bit logic instead of shifts and masks.
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev