Использовать define для этого точно не нужно, эта замена функции и в этом случае только усложнит сопровождение и отладку.
Хотя бы вот такой код, уже приведет к неправельным действиям :


Использование inline - это лишь подсказка компилятору о том, что эту функцию стоит сделать inline, и совершенно не факт, что он это сделает.



Каким профайлером производились замеры ?

Не поняла, почему и что имеется ввиду под nLength+1 ? Может аLength+1 ?
Это не страшно: изменим имя параметра.   
Меня больше волновало _Us_SetLength(pUnicodeString, pUnicodeString->Length + 1),
но вроде все нормально. 





Да простым QueryPerformanceCounter - ом

Лучше профайлером, тогда более менее точно станет понятно, на что именно больше всего тратится ресурсов.



Ну, тогда продолжайте использовать. Мое дело предупредить ^_^

  Дело не в имени, а в выражении. Насколько я знаю макрос может взять не все выражение, чтобы он взял все там нужно в выражении скобки поставить каждому параметру.

с т.з. скорости ?
думаю тот, который побыстрей.
если критерий проверки - скорость.
как тут ранее написали, читабельность чуток понижается, 
следовательно такой кусок стоит объяснить.
но в принципе он ничего сложного не делает, поэтому такой кусок объяснять - время убивать зря.

множиться будет всегда, но можно сделать и быстрее, если не умножать, а делать побитовый & с нулём.
поэтому,  при условии, что длИны - представляются целыми типами,  мой вариант таков:

_cbLen тут стоит запихать в скобочки, как сказал тов. Alexeis, но не обязательно.
В данном конкретном случае это не страшно: 

• сравнение вычисляется слева-направо
• сравнение имеет более низкий приоритет, чем сложение.

т.е. в предложенном случае, ваше оригинальное макро:

поведёт себя "хорошо", т.е х>y+z будет всегда идентично x>(y+z). 
НО, т.к. иногда действия с операндами, которые запихивают в макро дают нежелаемые результаты,  не засовывать "операнды" макро в скобочки - плохой вкус.

не стоит использовать define, нервные клетки не восстанавливаются...
Обычная функция делающая то-же самое будет не медленнее.
Компилятор в состоянии разобраться, в каком контексте вызывается функция, если она вызывается один раз, то встраивание ничего не даст кроме увеличения объема кода.
Если функция вызывается в цикле, то даст, и скорее всего она будет встроена. Так зачем брать на себя работу компилятора?

Это как???   "На глазок"?


 Нет, он не всегда, причем далеко не всегда в состоянии разобраться...

нет  


с тем примером в 2 строчки он пожалуй сможет разобраться.
вообще чем меньше функция, тем больше шансов что она будет заинлайнена, если функция большая и выполняется долго, то стоимость ее вызова, по сравнению с выполнением самой функциии незначительна и встраивать смысла нет...
Но все эти аспекты анализировать самостоятельно - занятие неблагодарное, так что лучше доверить это компилятору.
Плюс функции в том, что в одном случае она будет встроена, в другом нет. Если она вызывается из 100 разных мест, то реально встраивать нужно в одном - двух, там где она часто вызывается и стоимость вызова большая. В остальных случаях проще вызвать... Ну а макрос на 100% разменяет объем на скорость, при этом разницы в скорости не будет, так как там где нужно функция будет то-же встроена...

Вот выдержка из справки по билдеру


Ни каких ограничений на то что функция не может возвращать значения или создавать локальные переменные. Это могут быть только ограничения отдельно взятого хилого компилятора.

Первый
Нормальный компилятор должен сделать не медленнее
Рекомендую заменить это 'выражение' на (((_pus)->Length = (_cbLen)) , 0) Хотя нормальный компилятор сделает практически тоже самое

Проверил - сделал вызовы обоих версих функции, скормил все это Intel компилятору (на Linux) - код АБСОЛЮТНО одинаковый! (см атач)

Кроме того, у define'а есть еще один ОГРОМНЫЙ подводный камень:
Это нормально откомпилится и будет работать (С++ допускает функции с одинаковыми именами но разными параметрами). Если бы у вас был #define вместо первой функции - вы получили бы маловразумительные сообщения о массе ошибок на месте определения второй функции.


Присоединённый файл ( Кол-во скачиваний: 4 )
 tst.zip 1,35 Kb

а как?

да, вобщем-то верно. За тем исключением, что "вобщем-то". Иногда нужно четко что-то встроить. И очень не хочется "балансировать" на грани встроенного в компилятор автомата, который решает - встраивать или нет. 

Ни каких ограничений на то что функция не может возвращать значения или создавать локальные переменные. Это могут быть только ограничения отдельно взятого хилого компилятора.
Это перечислены пункты когда функция точно не станет inline. И не факт, что в остальных случаях станет. Неплохо бы все-таки вспомнить как будет работать функция и на чем попытается сэкономить компилер. Врать не буду с борландом йа не работаю и не намереваюсь. Очень возможно, что он, например, преобразует внутри себя локальные переменные в глобалные и работает с их адресами и т.д...

Я же свои злоключения высказал, они могут пригодиЦЦо и другим идущим по этому пути.   

Вообще было бы очень клево, если бы кто-то не поленился, посидел с дизассемблером и несколькими компиляторами и накатал статейку "о том, как не надо применять inline"   

ЭТо кто вам такую ерунду сказал?1  


Ничего подобного. 100% на всех компиляторах - инлайна никогда не будет. Есть всякие форсирующие директивы, есть ключевое слово inline - хинт компилеру, есть оптимизатор.


Ничего подобного. Простые рекурсии (читай - рекурсии, которые были не в тему) - любой хороший комплер в состоянии развернуть.

а стек для чего?


вот xvr написал исчерпывающий пост, что еще нужно?
сидеть с дизассемблером не нужно, достаточно в release версии программы поставить брэйкпоинт в место вызова функции, например в цикле и когда он сработает клацнуть Show Disassembly, бегая отладчиком по рилиз версии, очень хорошо видно что и когда оптимизатор встраивает даже без дизассемблера, так как отладчик в заинлайненые функции не заходит. 

Effective C++, Глава 1:
Правило 1:

Суровая правда жизни  ...

А это тут то причем???   вон, смотрите, даже борланд по определению не сделает inline рекурсивную функцию. Отекда у нас уже пошла речь о разложении простой рекурсии?

А подстановкой мы что экономим!!!???  

угу... А еще надо хорошо учиться и слушать папу и маму...