Похоже корни двух необычных программных видах строк, приведенных выше лежат где-то в макросах WTL.
 Вот посмотрите на ниже приведенный код макроса из atldef.h

#ifndef ATLVERIFY

#ifdef _DEBUG

#define ATLVERIFY(expr) ATLASSERT(expr)

#else

#define ATLVERIFY(expr) (expr)

#endif // DEBUG

#endif                                  // #ifdef _DEBUG

 ...

  Но макрос то дает код только после компиляции ... 

  В некотрых функциях WTL сразу после декларации функции следуют строки типа:

  (parametr1);
  (parametr2);
  (parametr3);
  (parametr4);
  ....

 Так вот если бы эти строки были записаны так:
  ATLVERIFY(parametr1);
  ATLVERIFY(parametr2);
  ATLVERIFY(parametr3);
  ATLVERIFY(parametr4);
  ....

 то и вопросов бы не было.

 Наверное так оно и было, а затем программист почему то решил строки оставить, но ATLVERIFY в них убрал

 Такое пояснение для самого себя меня  вполне удовлетворяет ... Таких вариаций можно напридумывать много ...

 Еще хотелось бы сказать об   http://lurkmore.ru/Индусский_код

  В этой статье говорится только об одном аспекте индусского кода - программного кода.
  Но есть еще один очень важный и не затронутый вопрос.
  Написание читабельного кода.
  Что-там далеко ходить. Возьмем к примеру atldef.h
  Пример понимаю не убедительный, но для начала ..

// --- Так в atldef.h
//
#ifdef _ATL_DEBUG_INTERFACES
#ifndef _ATL_DEBUG
#define _ATL_DEBUG
#endif // _ATL_DEBUG
#endif // _ATL_DEBUG_INTERFACES

// --- Так после редактирования
//
#ifdef _ATL_DEBUG_INTERFACES

#ifndef _ATL_DEBUG
#define _ATL_DEBUG
#endif

#endif

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

 Например:

// --- Было
//
    info.rate = srate;
    info.bitrate = srate * 16 * channels;
    info.order = __BYTE_ORDER;
    info.format = raw;
    info.annotation = "OSS Soundcard";

// ---Стало
//
    info.rate           =  srate;
    info.bitrate        = srate * 16 * channels;
    info.order          =  __BYTE_ORDER;
    info.format        =  raw;
    info.annotation =  "OSS Soundcard";

 В верхних строках нужно сделать какое-то мысленное усилие, что-бы увидеть значение какой-то переменной.
 В отредактированных строках /на мой взгляд/ проще.

 Эта тема очень обширна она касается и записи комментариев ...

 Когда я беру код какого-то проекта из sourceforge.net и вижу, что он написан вроде бы толково, то первым делом
 редактирую текст и привожу к читабельному виду. А затем уже по мере необходимости начинаю редактировать код классов.
 За частую процентов на 30 люди пишут функции под конкретные нужды конкретного кода. Например вместо того, чтобы обеспечить
 "полный" интерфейс к какому-нибудь API без потери эффективности и читабельности, многие значения заданы константами, хотя
 параметр может принимать много значений ... В результате вместо одной функции плодится две, три. 
 Зачем ? В чем удобство ? Мне так проще пользоваться API к одной универсальной, а не к трем в которые выполняют какое-то
 подмножество одной. Для меня субъективно разница в том, что я концентрирую внимание на одной мнемонике, а не трех

 Конечно написано сумбурно, но было бы не плохо, чтобы в программистских кругах выработался вкус к читабельному коду.
 Это я ни где не наблюдал. 
 Пишут как "курица лапой".

 Ну вcе. Уф ...



Это сообщение отредактировал(а) Vladimiir - 16.8.2010, 00:11

до компиляции, в момент препроцессирования.
тут вот что о них пишут:

 ATLASSERT/ATLVERIFY - These are used to make sure a debug build reports a problem with the expression/invariant
 ATLENSURE - Debug is the same as ATLVERIFY, retail throws a C++ exception

 ^--- все верно как 2 * 2 == 0x04

 Ну конечно. Сначала макросы разворачиваются, а потом уже идет компиляция. Ну да чтобы заглянуть в код после макроподстановок нужно
 в опциях проекта выставить определенную опцию. А вот в listing честно говоря не обращал внимания приводится уже код с макроподстановками
 или "чистый".
 Я использую Visual Studio и по моему там нет нельзя так выставить опции, чтобы можно было получить и листинг с макроподстановками и
 объектный код. То способ которым я использую позволяет получить листинг с макроподстановками. Но продолжить отладку я не могу.
 Нужно поменять а проекте опцию "на обычный" код.
 Да и вообще такая потребность у меня возникает крайне редко.

 Зачем так далеко ходить. Вот WTL: http://sourceforge.net/projects/wtl/

 Вот нашел ...

inline int vsprintf_x( 
 LPTSTR   lpstrBuff, 
 size_t   cchBuff, 
 LPCTSTR  lpstrFormat, 
 va_list  args 
) {

#if _SECURE_ATL && !defined(_ATL_MIN_CRT) && !defined(_WIN32_WCE)

 return _vstprintf_s(lpstrBuff, cchBuff, lpstrFormat, args);

#else

 cchBuff;                               // Avoid unused argument warning


Это сообщение отредактировал(а) Vladimiir - 16.8.2010, 23:07

 Вот что ответил мне Bjarke Viksoe.


Hi,
 
 In older versions of the Microsoft C++ compiler, it would emit a warning "Member pT declared but never used" -- even if the pT member 
 is clearly used in the code. This dummy assignment removes that compiler warning. In your example with iVp1, the member does not seem to 
 be used anywhere and the compiler also emits the same compiler warning when you compile with Level 4 Warning Level. 
 Again, the dummy assignment removes the compiler warning.
 
 regards
 bjarke

Не знаю зачем такой код могут писать профессионалы, знаю что такой код получается (не специально) писать у меня. Причина лежит в том что мало опыта, а практики еще меньше, поэтому когда пишется та или иная функция она пишется приблизительно под ограниченное количество задач которые на данном этапе очевидны. Но как правило спустя некоторое время находится еще какая нибудь задача которая похожа, но о которой я еще даже не думал, и стоит два варианта:
1) Переделать функцию как более обобщенную и все места ее вызова
2) написать ниже новую похожую.

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

Сложно когда нет опыта построения проектов. Когда удается в самом начале разложить все по полочкам и предусмотреть хотя бы всю высшую абстракцию.

значит все таки для ворнингов ))   

Просто жесть.