Dimitrie O. Paun wrote:
Most of the case can be transformed to debugrect(), but that requires some infrastructure work, so it belongs in a separate patch.
I assume you're referring to the routine in listview.c: static inline char* debugrect(const RECT *rect)
While that works, it also seems worth considering a macro-based approach. For instance:
#define _RECT_FMT "(%ld,%ld)-(%ld,%ld)" #define _RECT_ARG(r) (r).left, (r).top, (r).right, (r).bottom ...
Example use: TRACE("Combo client " _RECT_FMT ", setting Edit to " _RECT_FMT "\n", _RECT_ARG(rect), x, y, x + w, y + h);
(FWIW, the Linux kernel uses a similar macro, NIPQUAD, to display IP addresses.)
Although this doesn't hide things as well as the inline function, it might have some advantage in size and runtime, since it does more of its work at compile time.
Either way, having a standard way of inserting values of Windows structures into TRACE statements would probably be nice to have. - Dan
On December 26, 2002 12:14 am, Dan Kegel wrote:
Example use: TRACE("Combo client " _RECT_FMT ", setting Edit to " _RECT_FMT "\n", _RECT_ARG(rect), x, y, x + w, y + h);
Oh no! It's not too pretty, isn't it? :)
Although this doesn't hide things as well as the inline function, it might have some advantage in size and runtime, since it does more of its work at compile time.
I'll bet you a dollar in small change you can not measure a 1% speed difference. This code executes in trace mode only, where you don't care about the speed anyhow. Also, the since difference must be minute anyhow since the macro approach actually enlarges the strings where it's used. Not to speak of the aesthetic side of things... :)
Dimitrie O. Paun wrote:
On December 26, 2002 12:14 am, Dan Kegel wrote:
Example use: TRACE("Combo client " _RECT_FMT ", setting Edit to " _RECT_FMT "\n", _RECT_ARG(rect), x, y, x + w, y + h);
Oh no! It's not too pretty, isn't it? :)
No, it's pretty ugly :-)
Although this doesn't hide things as well as the inline function, it might have some advantage in size and runtime, since it does more of its work at compile time.
I'll bet you a dollar in small change you can not measure a 1% speed difference. This code executes in trace mode only, where you don't care about the speed anyhow. Also, the since difference must be minute anyhow since the macro approach actually enlarges the strings where it's used.
I thought everyone always left NO_TRACE_MSGS undefined, so the rect2a function you favor gets called unconditionally, and its output filtered out. The macro doesn't enlarge the strings over current practice; it merely codifies existing usage. There would be no net change in string size or code size with the macro approach.
Alternately, we could skip the macros, and just standardize the format strings. Would that be more acceptable?
- Dan
-
Dan Kegel -
Dimitrie O. Paun