Hi Dominik
> The mask and changemask are used in the style code to access the > whole style structure en-bloc as a character array without knowing > its internal layout. For example, if you say > > Style A Foo, Bar > Style A BarOff, Baz > > The style code takes the logical "and" value of both style masks > to decide which parts of the first line have to be deallocated and > the sets the mask of the merged style to the logical "or" value. > This will be difficult to do when the flag, the mask and the > changemask reside in the same byte, along with other styles that > work differently in the same structure. > Yes this certainly isn't worth it. > > I guess the question really comes down to whether you think the complexity > > in > > building the structures and bitfield addresses outweighs the wasted space > > and > > additional processing of a simpler solution. > > Well, there is another problem. ANSI C doesn't prescribe how > bitfields are to be implemented by the compiler. Theoretically, > there is no guarantee that a single bit switch is really mapped to > a hardware bit or that multi bit fields are placed in the same or > adjacent bytes. The current code already relies on this > assumption. Yes, thats why I was thinking of rewriting the get macros as well as the way the data was stored. It would avoid this problem by hiding the implementation and not trying to use the bitfields. I think that redesigning the data storage is the best approach, and that means removing the bitfields from the existing structures. > > If you really want to go with generating code > > Not really. If something *has* to be generated at all, I'd prefer > a simple table instead of real C code. That indroduces another > source of code inconsistencies, of course. > Sorry, I didn't mean to generate code code, just C code tables as you are thinking. > > to allow referencing the fields directly, heres my thoughts: > > > > Create a C program to generate the structures from a datafile - > > Hm. It should also generate the access macros then. Currently, > the macros assume that the flags structure is part of a style or > window structure, e.g. > > IS_STICKY(fw) > > expands to > > (fw)->flags.common.is_sticky > > This should be separated into several macros: > > #define FW_FLAGS(fw) ((fw)->flags) > #define FW_CFLAGS(fw) FW_FLAGS(fw).common > #define IS_STICKY(cf) (cf).is_sticky > > ==> > > IS_STICKY(FW_CFLAGS(fw)) > Yes I was thinking that this program should generate the macros too. I think that if you remove the bitfields and replace them with a set of longword arrays you can statically assign each bit of the array to a flag. Then you can use the macro to hide the data implementation. To simplify the creation of the flags, you could simply add the arrays to the existing structures using a #define to set the array size. Then from code, generate a .h with the macros that define the size of the arrays, the macros to set and get each flag. The code can assign sequentially the bits in the array and create the appropriate masks or macro to read a specific bit. To really simplify the addition of new flags, a data file containing the flag and symbol names can be used as the source, and all the macros can be created using that symbol name. Then all that ever needs to happen is a new flag name gets added to the data file, and bingo the arrays get bigger if needed, and all the macros to set and get the data are automatically created in the header. It can also create the C table with the long/bit offsets and name to allow bsearch searching as you suggested although a long offset and mask would probably be easier. If you typedef the array type, you can also abstract that so that the tool can in the future change the type of array if necessary. E.G. The tool may at some point become smart enough to figure out if word reads are faster than long reads etc and generate code to optimum performance by generating a different typedef and assigning the flags differently. I'm willing to write this code. What do you think? Cheers Dave -- Dave, Diane & Kringle http://www.geocities.com/SiliconValley/7499 -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
