One reason even on modern compilers to use U32 for the color is so that images can be packed arrays of color objects. I believe on some 64 bit compilers it will not make structures be less than 8 bytes. If this is true then an implicit conversion from U32 to color is needed anyway.
I think g++ can be convinced to make the object 4 bytes in size and allocated on 4 byte boundaries but I am unsure about others. In general I agree it would be better to use a structure, so using your idea is good as long as we have proof that an array of them can be made equivalent to an ARGB image array. If it has to be an integer, you can sill write fltk::Color(r,g,b) type "constructors" though they return a U32. On 08/21/2011 12:23 PM, Evan Laforge wrote: >> Generally I feel that a typedef is sufficient. It does not prevent >> misuse, but it makes the function prototypes clear. It also means that >> the user can type 0xaarrggbb directly into the code and it works. Qt is >> really annoying that I always have to look up the converter function. > > I disagree. I use Color, Point, Rect, etc. types extensively and > they're so much more pleasant to work with that I convert to and from > the low level fltk (x, y, w, h) stuff at the boundaries and use them > exclusively in my code. The benefit is even greater with complex > types like Rect which have canonical forms, invariants, etc. > > I wouldn't want to type a hex value directly in the code and have it > implicitly converted into a color, I like the clarity of e.g. > Color.rgb(uchar, uchar, uchar) and Color.rgb(double, double, double), > Color.rgba(...), or even 'c2 = Color.rgb(..); c2 = c1.a(0.5)'. When I > print them out for debugging, I would rather see 'Color.rgb(1, 2, 3)' > than some giant decimal number, and the benefit is multiplied when > printing out complex types with color components. And of course the > convenience of c.brightness(1.2) or c.is_opaque() or whatever else. > Trading all that and type safety for the ability to use hex literals > seems like, well, not a very good trade. > > And it's not even a trade, you can get the hex literal to color > conversion and back by adding a implicit conversion constructors, but > there's a reason those are pretty much universally discouraged: they > have all the implicit conversion disadvantages of a typedef. > _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
