Цитата(Riply @ 23.7.2008, 17:23  ) | Какой из этих двух вариантов (если конечно они не содержат ошибок) предпочтительней для использования ?
(первый в три раза медленнее второго, но второй как-то ненадежно выглядит smile)
|
с т.з. скорости ?
думаю тот, который побыстрей.
если критерий проверки - скорость.
как тут ранее написали, читабельность чуток понижается,
следовательно такой кусок стоит объяснить.
но в принципе он ничего сложного не делает, поэтому такой кусок объяснять - время убивать зря.
| Цитата(Riply @ 23.7.2008, 17:23 ) |
Например, в нем используется выражение " ((_pus)->Length = _cbLen) * 0 "
Всегда ли его левый сомножитель будет "вычисляться" или, при некоторых условиях, может игнорироваться ?
|
множиться будет всегда, но можно сделать и быстрее, если не умножать, а делать побитовый & с нулём.
поэтому, при условии, что длИны - представляются целыми типами, мой вариант таков:
| Код |
#define _Us_SetLength(_pus, _cbLen) (((_pus)->MaximumLength >= (_cbLen)) ? \
(((_pus)->Length = (_cbLen)) & 0) : \
STATUS_NAME_TOO_LONG)
|
_cbLen тут стоит запихать в скобочки, как сказал тов. Alexeis, но не обязательно.
В данном конкретном случае это не страшно: - сравнение вычисляется слева-направо
- сравнение имеет более низкий приоритет, чем сложение.
т.е. в предложенном случае, ваше оригинальное макро:
| Код |
_Us_SetLength(_pus,_cbLen+1)
|
поведёт себя "хорошо", т.е х>y+z будет всегда идентично x>(y+z).
НО, т.к. иногда действия с операндами, которые запихивают в макро дают нежелаемые результаты, не засовывать "операнды" макро в скобочки - плохой вкус.
|
. И я блин вспомнил, читал де, что собственные закрытые функции класса компилер сам делает inline если они работают только с полями класса. Блин... Пришлось немного пошаманить, зато inline стали настоящими подстановками.
"На глазок"?
