Daniel Kolesa <[email protected]> writes: > 2014-09-19 9:22 GMT+01:00 Kosyrev Serge <[email protected]>: >> Tom Hacohen <[email protected]> writes: >> > On 19/09/14 05:48, Jaehwan Kim wrote: >> >> #define ELM_RECTS_INTERSECT(x, y, w, h, xx, yy, ww, hh) (((x) < ((xx) >> + (ww))) && ((y) < ((yy) + (hh))) && (((x) + (w)) > (xx)) && (((y) + (h)) > >> (yy))) >> >> #define ELM_PI 3.14159265358979323846 >> >> +#define ELM_SCALE_SIZE(x) x / elm_app_base_scale_get() * >> elm_config_scale_get() >> > >> > >> > This is bad... Very bad... >> > >> > Should be: >> > #define ELM_SCALE_SIZE(x) ((x) / (elm_app_base_scale_get() * >> > elm_config_scale_get())) >> >> Why even allow such complex things to be macros? >> >> Static inlines allow better type checking and are much less of a >> hair-tearing experience in general.. >> > > I second that, however be careful with them as they aren't *guaranteed* to > actually get inlined - it's just a hint and the compiler isn't obliged to > follow it.
At least for gcc we have __attribute__ ((always_inline)): http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html -- respectfully, Серёга Косырев ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
