Siarhei Siamashka <siarhei.siamas...@gmail.com> writes: > This is not intended to be immediately pushed to pixman git repository. > At least not until it proves to have some real practical use. Except > maybe for the 'xor'->'filler' variable rename patch, which clearly > should not cause any regressions or inconveniences.
There is a number of things in this series that look like good changes regardless of moving to C++ or not. Some I noticed: The SIZE_MAX change was requested here: http://lists.freedesktop.org/archives/pixman/2012-August/002196.html and someone recently mailed me privately and pointed out that Solaris 9 doesn't have it either. The xor->filler change should be harmless as you point out, and 'filler' probably is a better name than 'xor'. The uint32->pixman_format_t in pixman-glyph.c looks good. Regarding the malloc() changes, it might be worthwhile to add some macros that take a typename as a parameter, along the lines of #define pixman_new(type, n) \ ((type *)pixman_malloc_ab (sizeof (type), n)) so that we get warnings if we try to assign the result to an incorrect pointer type. Although for a lot of code in pixman, we do actually rely on the ability to do type aliasing of malloc()ed memory, so maybe the usefulness of such macros is limited. > Any comments or ideas? Hopefully not a C vs. C++ flamewar :) Every once in a while I let myself be convinced me that C++ can be used as a better C, but whenever I have tried it, it has somehow always ended up driving me crazy with longer compile times and casts all over the place. I guess I could see the potential for better debug builds that you mention in the first commit message, but I'd definitely like to see some concrete benefits before committing to keep all pixman code compilable as C++. Søren _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman