mirror of https://github.com/xzeldon/htop.git
6dae8108f8
With the CLAMP macro replacing the combination of MIN and MAX, we will have at least two advantages: 1. It's more obvious semantically. 2. There are no more mixes of confusing uses like MIN(MAX(a,b),c) and MAX(MIN(a,b),c) and MIN(a,MAX(b,c)) appearing everywhere. We unify the 'clamping' with a single macro. Note that the behavior of this CLAMP macro is different from the combination `MAX(low,MIN(x,high))`. * This CLAMP macro expands to two comparisons instead of three from MAX and MIN combination. In theory, this makes the code slightly smaller, in case that (low) or (high) or both are computed at runtime, so that compilers cannot optimize them. (The third comparison will matter if (low)>(high); see below.) * CLAMP has a side effect, that if (low)>(high) it will produce weird results. Unlike MIN & MAX which will force either (low) or (high) to win. No assertion of ((low)<=(high)) is done in this macro, for now. This CLAMP macro is implemented like described in glib <http://developer.gnome.org/glib/stable/glib-Standard-Macros.html> and does not handle weird uses like CLAMP(a++, low++, high--) . |
||
|---|---|---|
| .. | ||
| Battery.c | ||
| Battery.h | ||
| IOPriority.c | ||
| IOPriority.h | ||
| IOPriorityPanel.c | ||
| IOPriorityPanel.h | ||
| LinuxCRT.c | ||
| LinuxCRT.h | ||
| LinuxProcess.c | ||
| LinuxProcess.h | ||
| LinuxProcessList.c | ||
| LinuxProcessList.h | ||
| Platform.c | ||
| Platform.h | ||