"Программирование на Visual C++. Архив рассылки" - читать интересную книгу автора (Jenter Алекс)

Программирование на Visual C++ Выпуск №6 от 02/07/2000

Здравствуйте, уважаемые подписчики!

НОВОСТИВышел Service Pack 4

Фирма Microsoft недавно выпустила очередной, четвертый пакет исправлений для Visual Studio 6.0 – Service Pack 4. Он устраняет некоторые ошибки в продуктах VS, а также производит ряд обновлений.

В Visual C++ 6 исправления касаются STL, MFC, CRT, IDE, самого компилятора, отладчика, и многих других частей, т.е. практически всего.

Следует заметить, что среди исправленных ошибок встречаются действительно критические, которые могут помешать работе. Например, частое использование realloc на маленьких блоках памяти вызывало memory access violation (конфликт при попытке доступа к памяти), а DllMain выбрасывала unhandled exception, если в течение DLL_THREAD_DETACH возникала нехватка памяти. MFC AppWizard неправильно связывал данные с программой при использовании OLE DB ODBC provider и Access.

Помимо исправления ошибок, в SP4 включены все предыдущие Service Pack'и, плюс новые версии таких компонентов, как:

• Microsoft Data Access Objects

• Microsoft HTML Help

• Microsoft Data Access Components (MDAC)

• Microsoft Scripting

• Microsoft OLE Automation

Также внесены исправления, необходимые для новых версий Office, SQL Server и Windows, включая Internet Explorer.

К сожалению, SP4 не включает самые последние заголовки и библиотеки для Internet Explorer5 или Windows 2000. Их нужно загружать отдельно в виде SDK.

Visual Studio Service Pack 4 занимает около 130Мб и доступен для свободного скачивания на сайте Microsoft по адресу http://msdn.microsoft.com/vstudio/sp/vs6sp4 (13 файлов, приблизительно по 10 Мб каждый).

Имеется возможность обновить только некоторые продукты, например Visual Basic. Для Visual C++, однако, придется скачивать полную версию. Или подождать, пока она появится на пиратских CD.

ОБРАТНАЯ СВЯЗЬИз входящей почты

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

Здравствуйте, Алекс!

Встретил в Вашей рассылке "Программирование на Visual C++" за No.5 следующее утверждение:

"Кстати, имейте в виду, что описатель PASCAL и pascal – это то же самое, что и WINAPI. Но этот описатель является устаревшим, оставлен лишь для совместимости, и Microsoft рекомендует повсеместно использовать вместо него WINAPI."

Это распространенное мнение, которое вызвано переходом Microsoft с pascal на stdcall при переходе с Win16 на Win32. При этом Microsoft в MSDN утверждает, что: "Use WINAPI where you previously used PASCAL or far pascal." Но это означает всего лишь то, что стандартный способ вызова API функций изменился, а не то, что pascal эквивалентен stdcall. Проиллюстрируем это первоисточниками.

MSDN:

"The stdcall calling convention is used to call Win32 API functions. Argument-passing order Right to left. Argument-passing convention By value, unless a pointer or reference type is passed. Stack-maintenance responsibility Called function pops its own arguments from the stack. "

Borland C++ Builder Help:

"In addition, pascal declares Pascal-style parameter-passing conventions when applied to a function header (parameters pushed left to right; the called function cleans up the stack)."

Справка от Борландовского продукта в последнем случае выбрана потому, что MSDN вообще умалчивает о том, кто такой этот pascal, ограничиваясь тем, что он is now obsolete. Из вышеприведенных выдержек мы можем видеть, что stdcall отличается от pascal порядком передачи параметров. И просто так подменять один способ другим нельзя. Это легко продемонстрировать, попытавшись вызвать функцию с модификатором pascal из Visual Basic. Access Violation Вам гарантирован.

Sergey Shapovalov

Software Security Belarus

Mea culpa. Действительно, иногда не вредно вспоминать, что кроме MSDN существует кое-что еще. Спасибо, Сергей!

Привет

"Использование соглашения сdecl вместо stdcall иногда оправданно, но приводит к увеличению размераgt;исполняемого модуля из-за того, что имя функции декорируется в этих соглашениях по-разному."

Не понял я этой фразы… cdecl делает больше код потому что надо стек чистить каждый раз после вызова рутины, а не изза decoration. Names decoration влияет только на представление имён до линкера, в выходной код они не включаются.

Причём, cdecl – стандартный тип вызова для C/C++ изза возможности использования varargs, в то время как в stdcall вызове такое невозможно. Как правило, stdcall юзают в dll (в Win32API в том числе) и для присобачивания чужих lib, собранных с использованием этого типа вызова.

Ivan Nevraev

В самом деле, декорирование имени функции тут не причем. Благодарю Ивана за помощь. В дальнейшем буду стараться публиковать только перепроверенные данные.

А также напоминаю, что в следующем выпуске вас ожидает вторая часть этой публикации.

[…] Чтобы рассылка действительно не превращалась в дискуссионную группу, можно дать еще пару ссылочек. Вы уже упомянули news-группы. Можно посоветовать также еще один, правда англоязычный ресурс: http://codeguru.developer.com. Это один из (если не самый) крупнейших сайтов для разработчиков на C++ и большей своей частью на Visual C++.

Также там есть discussion board: http://codeguru.developer.com/bbs/wt/wwwthreads.pl, где можно задать любой интересующий вопрос (естественно на английском языке). Обычно ответ приходит довольно быстро. Причем это либо исходный код, либо ссылка на что-либо подобное. Короче очень рекомендую.

Andrew, Gromyko ([email protected])

Андрей, кстати, уже не в первый раз пишет. Ссылки хорошие – сам на CodeGuru захожу очень часто. Так что уверен, многим эта информация придется кстати.

Да, если вы знаете какие-нибудь стоящие внимания ресурсы по VC – присылайте ссылочки!

Большое спасибо за рассылку! Большой ее положительной спирали! ;) (Bill Gates "The Road Ahead") [ Может, "ей"?… – AJ]

Как насчет новости от Microsoft? Я имею в виду http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp.

C# (pronounced "C sharp").

В связи с этим:

а) не переименовать ли рассылку сразу в VisualC# ? :)

б) не объявить ли конкурс на лучшее объяснение значка # в новом названии; какова связь # со словом sharp?

Маленькое пожелание напоследок – не забывать, что "VisualC++" != "MFC"; "VisualC++"gt; "MFC";

Надеюсь еще не раз побеспокоить вас своими письмами.

С уважением,

Александр Тумель.

Ну, первое пожелание я уже выполнил – появилась рубрика "Новости". Она, конечно, будет появляться не в каждом выпуске, но самые важные события в мире VisualC++ будут освещаться именно там.

О VS NextGen я как раз готовлю материал, даже уже был анонс ("Что дядя Билли нам готовит…") – статья выйдет через выпуск, или , в крайнем случае, через два-три.

А вот насчет произношения "C sharp", гадать, увы, не придется ;) Знак "#" в музыке обозначает диез, т.е. повышение звука на полтона (здесь Microsoft, скорее всего, проводит аналогию с операцией инкрементирования "++"). А "диез" по-английски как раз и будет "sharp" (можете посмотреть в словаре). Все-таки 8 лет муз. школы не прошли для меня даром!;) Так что конкурс отменяется.

Про переименование рассылки в Visual C# подумаем, когда a) прочитаем про этот C# – здесь же;) и б) Microsoft выпустит продукт под таким названием.

А по поводу пожелания – так ведь так оно и есть! Рубрика WinAPI на что? А вот ActiveX и СOM действительно рассылкой не освещаются. Про COM/DCOM кажется, есть отдельная рассылка.

На заданные в прошлом выпуске вопросы пришло очень много ответов, так что я, скорее всего, похожие ответы сгруппирую в один, а потом просто укажу, кто такой ответ прислал. Иначе объем выпуска не выдержит ни один почтовый ящик ;) Постараюсь никого не забыть!

Да, и еще. Ради бога, прошу извинить меня тех, кто написал мне и не получил пока ответа. Писем приходит очень много, и я не могу отвечать всем.

На сегодня пока все. Рубрики "WinAPI" и "Вопрос-Ответ" – в следующем выпуске.

Будьте здоровы!

Красноярск, 2000.