Создание консольных додатків з допомогою майстра на Visual З++ 6-2

Создание консольных додатків з допомогою майстра раптом у Visual З++ 6 — 2.

Помнится, у минулому статті «Перша програма в Microsoft Visual З++ 6.0» я пообіцяв розповісти, створювати консольні докладання в Visual З++ з допомогою майстра. Обіцянки я звик завжди виконувати. Отже, цим тут і займёмся. Минулого разу ми писали програмний код в текстовому редакторі, середовище само його компилировала, компоновала і запускала на виконання. Так, це її робота, але впевнено ми її ще чимось завантажимо. я вже говорив, що навколишнє середовище того і потрібна, щоб виконувати за нас рутинну роботу. Ви що, зара продемонструємо!

Запускаем велику й могутню Visual З++. Жмём FileNew. Далі, оскільки ми створюватимемо непросто файл вихідного коду в текстовому редакторі, а проект консольного докладання (класно звучить?!), жмём на вкладку Projects, вибираємо Win32 Console Application (консольное додаток для Win32). Жмём Ok. Тепер майстер нас запитує: What Kind of Console Application do you want to create? (Яке консольное додаток треба створити?) й уряд пропонує які варіанти:

An empty project (Порожній проект).

A simple application (Просте додаток).

A «Hello World!» application (Додаток «Hello World!»).

An application that supports MFC (Додаток із підтримкою MFC).

Выбираете необхідне, жмёте Finish, і середовище сама за вас щось робить. Як-от, створює заготівлю консольного докладання. Ось далі будете програмувати самі, оскільки заготівлі, хоча зазвичай і є цілком робітниками додатками, суті нічого роблять. Хіба що інтерфейс, але обробки інформації - ніякої. Це вже буде зовсім наше завдання — напрограммировать мозок програми. Заготівля ж — це, власне, її пика. Так, звісно ж, інтимні місця програми також у української влади (якщо знадобиться) :) Проте він менш, створення умов та організація інтерфейсу може дуже довгим, тоскним і неприємним заняттям. Справді, в консольных додатках це майже відчутно (і який там на фіг інтерфейс??!), тоді як у разі, скажімо, многодокументного докладання створення умов та організація інтерфейсу вручну — справді величезний геморой! Але навіть у цьому завдячую може зробити середовище, суть у тому, що треба робитиме нас самих, вона також може надати хорошу допомогу й підтримку. Оце просто до того що, що навколишнє середовище халяви нам надає незміряно! Проте, многодокументные докладання — справа дуже непросте, й ми будемо створювати й розбирати значно пізніше. Сьогодні ж консоль, консоль і вкотре консоль!

Ну що, давайте перепробуем, розберемо і вивчимо все 4 варіанта, благо їх усього лише 4! По порядку, починаємо з порожнього проекту. Назвемо відповідно Listing1, Listing2, Listing3 і Listing4. Хоча можете, звісно, як сподобається називати.

An empty project

Итак, коли ми вибрали An empty project, те, що само зробить середовище? Та з суті, нічого! Ось зараза, так! :) Ні тобі програмного коду, ані шеляга навіть файл .cpp не створила — нифига… Ну хоч на насправді, щось вона звісно зробила: створила нам файли .dsw (workspace — робоче простір) і .dsp (project — проект) та інших, порожню течку Debug для отладочной версії докладання, або Release для робочої версії.

Кстати! Для вибору активної конфігурації проекту (зазвичай Debug (отладочная версія) чи Release (робоча версія)) заходите в BuildSet Active Configuration і вибирайте. Хто невідомо, це визначає режим компіляції проекту.

В самому середовищі у нашій робочому просторі (вікно workspaces, вкладка FileView) з’явилися порожні течки Source Files, Header Files, Resource Files — для файлів вихідного коду програми, заголовочных файлів і файлів ресурсів відповідно. Але чому нам, а що те з того? І ми могём змусити ледачу середовище, й побільше роботи виконати!

A simple application

Выберем A simple application. Нині вже Visual З++ удосужился-таки зробити нам файл вихідного коду (в мене проект названо Listing2, тому й файл називатиметься Listing2. cpp), причому такого змісту вийшов файл:

.

Ну що саме, то це вже чогось схоже! Давайте розберемо.

Сверху він нам завдає навіть прокоментував зроблене. Далі йде #include «stdafx.h» — це підключається файл stdafx.h. Його на свій чергу належить до створеному все тим самим майстром файлу stdafx.cpp. Файл stdafx. cpp відповідальний створення перекомпилированных заголовків. Що, зовсім мізки запудрив? Нічого, стряхивайте пудру з голови, поясню людською мовою. До нашої програмі може підключатися багато різних файлів заголовків. Це може бути як стандартні файли, які люб’язно подає, приміром, Microsoft, або ж наші власні. Отож, якщо кожне разів у проекті компілювати все файли наново — дуже довго виходить. Але адже ми в усіх файли змінювати будемо! Ті, що ні змінюються чи змінюються дуже рідко — компілюються одного разу за першої компіляції, а наступному будуть оброблятися у вже скомпільованому вигляді. Наново будуть компілюватися лише часто змінювані файли, щоб внесені зміни відбивалися на роботі програми. Це значно скорочує час компіляції проекту. Просекаете логіку? Ото! Так в файлі stdafx. h і буде указуватися (підключатися) ті файли, які змінюються рідко (взагалі змінюються) і який будуть використовувати як вже перекомпилированные.

Теперь ще, напевно, виник ви питання: як у директиві #include використовувати лапки ««, а коли кутові дужки < >, коли вказувати розширення .h чи .hpp, а коли немає? — Для вказівки заголовочных файлів стандартної бібліотеки непотрібен розширення. Вони розпізнаються як заголовкові файли, бо замість синтаксису #include «…» використовується #include <…>. І розширення .h у разі не вказується. До кожного заголовкового файла стандартної бібліотеки мови З існує певний стандартний заголовний файл З++. У першому випадку це завжди буде прописуватися #include <*.h>, у другому #include <*>. Зазвичай, для включення бібліотечних файлів користуйтеся кутовими дужками < >, а власних — лапками ««. Наприклад:

#include <iostream> // з стандартного каталогу які включаємо файлів.

#include «myheader.h» // з поточного каталогу.

Наконец, зауважу з цього приводу, що прогалини всередині < > чи «» мають значення!

#include < iostream > // не знайде <iostream>

Смотрим далі, точніше, нижче. Нижче в нас знайома функція main. «Але що це? Що за фігня в неї в дужках? Які ж нас так обдурили? Ніби ж функція без параметрів була!» — Нічого я нікого не обдурив, вже казав, що в прикладі у минулому статті параметрів в неї був лише простоти. Однак у реалі там найчастіше вказуються аргументи, необхідних доступу до параметрами командної рядки — і їх використання їх у програмі. Ось то вони це і є. Тож нікого не обстебал, навпаки, я попереджав звідси! І пообіцяв у цій статті про неї варто детальніше сказати. Що ж, виконую.

Умная середовище нас у всіх правил і канонам сгенерировала таку сигнатуру для функції main (тим, хто в курсах: сигнатура на людському мові - це функції з переліком її параметрів — привчайтеся до грамотної термінології, потім окупиться!):

int main (int argc, char* argv[]).

Знаете, часто консольні програми організуються так, що опісля, як ми можна здійснити виклик програми з командної рядки, програма видає нам запрошення запровадити необхідні дані. Це дуже незручно для користувача, напружує… Користувачу то полювання швидше результат отримати! Отож, якщо таких даних трохи, було б непогано передати їх програмі ще за її запуску. Творці операционок звідси подбали: більшість операційними системами, самі DOS і UNIX, наприклад, дозволяють передати програмі під час запуску кілька параметрів (чи один) (або ні одного). Консоль, природно, теж таку можливість нам надає. Я вже говорив у статті, ці параметри називаються параметрами командної рядки — і пишуться при виклик програми після імені самої програми через прогалину. Наприклад так:

C:>Stebatrix.exe steb 34.

Итак, функція main, зазвичай, має дві параметра: цілий argc і масив рядків argv. Хоча можуть називатися тож інакше, зазвичай вони називаються у такий спосіб. Між іншим, оскільки argv ми є масивом рядків, може бути оголошено по-різному, наприклад:

char* argv[] чи char** argv — псуватися з мови можна скільки завгодно (у межах стандарту мови З++ природно). Хто не зрозумів, дивіться розділ «Мова програмування З++», постараюся там звідси (масивах і рядках) написати.

Первый параметр argc (argument counter — лічильник аргументів (параметрів)) містить у собі кількість параметрів командної рядки.

Второй argv (argument vector — вектор (масив) аргументів) містить у собі масив параметрів командної рядки. Оскільки параметри є символьними рядками, це завжди буде масив рядків, причому сенс тут такий: argv має тип char* [argc+1] (не забули про нульової елемент масиву?). Нульовим елементом масиву argv буде ім'я програми. Список аргументів обмежений нулем, то бути argv[argc] == 0. Що стосується, коли командна рядок така:

C:>Stebatrix.exe steb 34.

запустив програму ось, що ми матимемо:

.

Теперь про параметри командної рядки, гадаю, все зрозуміло. Проте, полювання либонь програмку зробити? Давайте зробимо. Корисно буде. Тепер і подивіться, як і найпростішому разі можна параметри командної рядки використовувати. Отже, заготівля вихідного файла в нас є (Listing2.cpp), доповните його, що він був такий:

.

Сразу хочу звернути вашу увагу, що підключення iostream і cstdlib можна (мабуть, вже не треба) оголосити над файлі Listing2. cpp, а stdafx.h. Ці файли ми змінювати думати, отже, маємо право. Тоді проект компілюватися буде швидше, хоча у разі нашого проекта-малютки і буде помітно. У разі приберіть ці два рядки.

#include <iostream>

#include <cstdlib>

из Listing2. cpp і вставте в stdafx. h ось у це місце:

.

Эти два рядки мають бути лише щодо одного файлі: чи Listing2. cpp, чи stdafx. h — двічі один і той ж підключати зайве!

Пока не компілюйте і запускайте. Давайте зараз розберемося, що ж напрограммировали. Наша програма буде «просунутої версією» програми із минулого статті, теж рядок тексту виводити буде, лише дещо інакше :) При виклик з консолі програма прийматиме два параметра: перший — це рядок тексту, і треба буде вивести, а другий — скільки ж разів треба буде її вивести.

Про iostream ви вже знаєте, тоді як cstdlib підключається у тому, щоб скористатися функцією atoi. Ця функція має у яку сигнатуру (див. також файл stdlib. h):

int atoi (const char* p);

Она перетворює рядок p, яка була чисельна значення (тільки з цифирей що складається) у саму чисельна значення. Те бути рядок ‘12 345' буде перетворять на 12 345. Дуже корисна функція. Є ще дві: atof і atol, змінюють рядок в double і long відповідно. Якщо ж рядок технічно нескладне собою число (наприклад ‘123g4a') він возвращён 0. Ось саме з допомогою функції atoi ми перетворимо символьну рядок argv[2] аж в av2. Адже інакше не пройде! Отож, перетворимо, а потім циклом for виводимо av2 раз рядок argv[1]. Хто не знає цикли — по-перше час вже знати, тоді як у других — подавайтеся у розділ «Мова програмування З++», постараюся знайти час і ви-рішив написати про неї. Тепер спробуйте скомпілювати і запустити виконання програму. — Що таке? Начебто все скомпилировалось, скомпоновалось, а коли почала запускатися програма нам раптом повідомляють про помилці і пропонують відправити звіт до якоїсь там матері… Невже Matrix has us?! — Спокуха! Давайте розберемося. Програма повинна мати два параметра, а звідки вона візьме, ми запускаємо її з середовища Visual З++, ніяких параметрів не вказуючи? Отут і саме, що нізвідки. Звідси й лажа. Нині ми ось що зробимо: зайдём в консоль і запустимо нашу прогу звідти. Хто не знає, як і консолі працювати (в MS-DOS), тут пояснювати не ес-сно, почитайте там Фигурнова якогось… Отже давайте запустимо тепер прогу з консолі, що називається, вручну, і з параметрами. Командна рядок цьому буде мати, до прикладу, такий її різновид:

D:Program FilesMicrosoft Visual StudioMyProjectsListing2Release>listing2 We_have_Matrix! 3.

Только зверніть увагу, що We_have_Matrix! пишемо не через прогалину, а ще через символ подчёркивания, т.к. прогалинами поділяються параметри і прога так і не зрозуміє (зрозуміє неправильно). Запускаємо і тішимося тожеством черговий маленькій перемоги над Матрицею! На самому то ділі це ще не перемога, бою то ніякого майже було: так, тричі на паркані написали щось, та й усе. До бою ще підготовлятися і підготовлятися треба! І тому вантажу далі. Отже, програма чудово працює з консолі. Звичайно бути з VC++? Так, мав можливість (і був), звісно, включити до програмі можливість отримання як двох параметрів командної рядки, а й іншого їхньої кількості. Але не зробив цього свідомо. Щоб простіше. Якщо ж усерйоз, то враховувати такі нюанси необхідно. Адже й з консолі ми можемо програму викликати, не вказавши параметри чи вказавши непередбачене число параметрів. Тому потрібно в програмі цю відповідальну справу обслужити: просто умовним оператором чи через винятку організувати вихід проги з такої незручного становища. Та цим зупинятися думати: нам ще 2 варіанта заготовок консольных додатків треба розглянути, і розібрати.

A «Hello World!» application

Этот варіант, відразу скажу, практично непотрібний — суто демонстраційна річ (показуха одна!). Ця заготівля така ж сама, як і попередня (A simple application), з тією різницею, що вона й і виводить з допомогою функції printf рядок «Hello World!» на екран. Цю відмінність можна полягає лише у рядку коду:

printf («Hello World! n »);

Мы це із Вами вже вміємо, лише за допомогою не printf, а використовуючи cout. Давайте, чи що, про функцію printf трішечки й поговоримо. Щоб її використовувати, потрібно підключити. Не тривожтеся звідси: подивіться файл stdafx. h — середовище вже зробила за нас! Ну ще б монітор ганчіркою протирала і взагалі ціни їй був! :) Функція printf не змінилася з мови З. Проте, її часто-густо можна зустріти. Тим більше що, як я говорив, хороший код на З буде чудово компілюватися і у компіляторі для З++. Навіть разом із кодом на З++ (щоправда у разі проблема сумісності усе ж таки раз у раз виникає, але він легко вирішувана). З цього всього слід, що тільки загалом розглянути функцію printf потрібно. Сигнатура в неї така:

int printf (const char*, …).

Возвращает вона нам кількість виведених символів. У разі рядки «Hello World!» їх 13 (не забуваємо про NULL наприкінці рядки). Як параметра вона бере рядок у стилі З (масив символів) (або ж безпосередньо рядок у лапках), причому їх може бути кілька, тоді просто через кому перелічимо:

printf («Hello», «World!», «n »);

Это як і в cout можете кілька разів використовувати <<, а cin >>.

Кстати, хтось ще невідомо, для входження у мові З++ використовується така хреновина: std: cin >> і далі ім'я перемінної, в яку записано те, що ми вводимо. У З цією займається функція gets () і ін.

Также в printf можуть указуватися специфікатори перетворення (це наприклад ми значення який-небудь перемінної хочемо вивести), але докладно балачки про функції printf і потоках введення виведення піде розділ «Мова програмування З++», там цій вічній темі буде присвячено окрема стаття. Але тут зауважу ще, що використання функції printf небажано. Хоча, можливе з з нею й простіше звертатися, ніж із cout і cin, але вона має великий недолік: поганий контроль типів даних (при неявних перетвореннях типів, наприклад), що навіть в досвідчених програмістів стає іноді причиною прикрих помилок. Тому вчена рада: користуйтеся для ввода/вывода засобами З++!

Переходим до останнього варіанту: консольное додаток із підтримкою MFC.

An application that supports MFC

Для непосвячених: MFC — Microsoft Foundation Class (базові класи Microsoft). І більше нічого про MFC писати нині різноманітні буду, т.к. MFC ми присвятимо непросто статтю, а цілий розділ! Гаразд, гаразд — напишу однієї фразою: пакет MFC дає можливість розробляти GUI-приложения (GUI — Graphic User Interface — графічний користувальницький інтерфейс) для Windows мовою З++ з використанням багатого набору бібліотечних класів, причому ці бібліотеки є объектно-ориентированными (крім инкапсуляции підтримують запозичення ро-сійських та поліморфізм). Проте, оскільки MFC значною мірою орієнтована працювати з вікнами, документами, поглядами й т.д., велика її частка залишається незатребуваною консольным додатком. Проте, вона усе одно може дуже корисною!

Итак, вибираємо тепер четвертий варіант і дивимося, що нам створила середовище Visual З++. Так! Цього разу видно, що попрацювала маленька! Багато чого незрозумілого (і, сподіваюся, зрозумілого теж) написала! Давайте розбиратися…

Во-первых, нові файли з’явилися: Listing4. h, Listing4. rc, Resource.h.

Listing4.h — файл заголовка до нашого исходника. Поки що маємо тут що: два сморжі та остання — попередження повторного підключення, це не вийшло отже, ми б включили двічі цей файл до будь-якого іншого (можете почитати розділ «Мова програмування З++» про варти включення). Далі три рядки — перевірка версії MFC. І, нарешті, підключення файла Resource.h.

Практически кожне додаток, розроблювальне в Visual З++, містить один файл ресурсів, одноимённый із самою додатком і має розширення .rc. У нашому випадку це Listing4.rc. У ньому перебувають описи всіх ресурсів нашого докладання. В Україні тут лише таблиця строковых ресурсів. У цьому є високе призначення нашої заготівлі - вона виводить на екран рядок «Hello from MFC!», оформлену як строковый ресурс. Середовище на насправді може сама (з нашої допомогою звісно) оголосити все необхідні ресурси, обрати ідентифікатори (унікальні імена), зв’язати ідентифікатори з конкретними числовими значеннями тощо. Насправді це зручне, наприклад, для русифікації докладання не знадобитися шукати в програмному коді місця де виводяться рядки, а й просто в таблиці взяти й поміняти текст з англійської російською, зберігши у своїй все ідентифікатори і чисельні значення. У програмному коде-то ми прописані ідентифікатори. Так що розумна середовище, забезпечивши нам таку політику, може врятувати нас від значного геморою. І це один приклад халяви, яку дарує нам Visual З++. При спробі відкрити файл Listing4. rc ми відкривається віконце ResourceView. Тут ми й є таблиця рядків. У ньому ми можемо змінити рядок яка відповідає певному ідентифікатору, або створити новий строковый ресурс, поставивши то відповідність новий ідентифікатор. Просекаете логіку? Ото!

В файлі Resource. h просто, використовуючи директиву #define, кожному ідентифікатору ставлять у відповідність чисельна значення. Але тут ми можемо його поміняти чи вказати її нового ресурсу.

Попробуйте запустити програму, привітайтеся з MFC і переконаєтеся, що додаток працює. Якщо привіталися, отже працює. Між тим, у нашому робочому просторі з’явилася татусю «External Dependencies» з файлом basetsd. h всередині. У ньому, якщо хочете знати, нам показують визначення базових типів даних. Це у разі, якщо заманеться (чи доведеться) використовувати 64-битные типи даних.

Между тим гаслам і у вже відомих нам файлах сталися значних змін. Давайте почнемо тепер із файла StdAfx.h. На початку все ті ж, що у Listing4. h варти включення, далі все той самий перевірка версії MFC, далі йде рядок:

#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers.

— для прискорення процесу компіляції (рахунок відмовитися від деяких можливостей).

далее йдуть рядки із залученням основних MFC-шных файлів: afx. h, afxwin. h, afxext. h, afxdtctl. h, afxcmn.h.

Кстати, якщо будете програмувати, використовуючи MFC, дуже раджу подивитися ці заголовкові файли. Якщо ви знаєте мову З++, то повинні побачити там не дулю, а корисну інформацію з MFC-классам і функцій і т.д. Буває нітрохи буде не гірший довідників. На ролі довідника дуже раджу MSDN Library.

Ниже розміщено місце, куди ми підключаємо заголовкові файли, які вкрай рідко змінюються і використовуватимуться як перекомпилированные (повідомляв звідси вище, на початку статті). Zabot’ливая середовище Visual З++ 6.0 вже підключила там <iostream>.

А тепер давайте дивитися найцікавіше — скінчено ж Listing4.cpp. Тут ми ось чого вже готове:

.

Разбираем усе своєю чергою. Як завжди, підключаємо stdafx. h, а разом із і Listing4.h. Він підключається тут, а чи не в файлі stdafx. h, оскільки очікується, що цей файл (Listing4.h) будемо досить часто колупати. Наступний блок з п’яти рядків може бути малозрозумілим. Пошкодую би і буду зараз мізки пудрити, докладно роз’яснюючи цю запис, просто скажу, що вона, можна сказати, канонічна, і міняти її, зазвичай, не стоїть. Застосовується переважно у отладочных мету і щоб уникнути деяких труднощів із ключовими словами і іменами. Далі саме цікаве і починається!

Итак, далі в нас йде оголошення об'єкта класу нашого докладання. Як-от оголошення об'єкта theApp класу CWinApp. Клас CWinApp є похідною CWinThread. Тому клас CWinApp представляє і основний потік виконання програми, і саме додаток. Отже, в будь-якому MFC-приложении є тільки об'єкта класу CWinApp. Нас звідси у коментарі вже попередили.

Строчка.

using namespace std;

говорит нам у тому, що в блоці програми буде використовуватися стандартне простір імен std. Пояснюю. У конкурсній програмі може підключатися дуже великий число різних файлів заголовків. У кожному файлі заголовка використовується багато різноманітних імен: перемінні, функції, класи, структури та т.д. Різні бібліотеки розробляють різні люди, і, ясна річ, виходить отож у різних бібліотеках можна використовувати однакові імена. Якщо ми користуватися відразу кількома бібліотеками, вона може скластися що ситуація, коли за спробі використовувати ім'я, яке дублюється в іншому подключаемом файлі, компоновщик видасть повідомлення про помилці: «Identifier multiply defined» (Ідентифікатор визначено кілька разів", де ідентифікатор — це будь-якого елемента). Така ситуація називається конфліктом імен. А, щоб уникнути таких труднощів і придумали простору імен. Простору імен йдуть на поділу глобального простору імен, що дозволяє нехай і завжди усунути, але, по крайньої мері, зменшити кількість конфліктів імен.

Пространство імен (namespace) власне представляє собою логічний групу імен, не більше якої імена не дублюються. Наприклад, простір імен стандартної бібліотеки std. При зверненні до ідентифікатору (імені), що входить до якесь простір імен треба явно вказувати цей простір. Тому, звертаючись до cout простору імен std, ми і пишемо std: cout. Те бути, пишеться назва простору імен (std) і крізь два двокрапки саме ім'я (cout). Саме тому, користуючись іменами з заголовочных файлів стандартної бібліотеки (<iostream>, <string>, <list> і ін.) ми повинні вказувати, що усе це належить простору імен std. Ви можете створювати й свої простору імен (коли й вам, наприклад, знадобиться назвати своє завдання ім'ям cout), але ці розмова окремої розмови.

Запись using namespace std; свідчить, що у межах поточної області дії (зазвичай, у межах фігурних скобок) буде по вмовчанням використовуватися простір імен std (зайве буде перед кожним ім'ям писати std:, коли вона належить до цього простору). Проте після цієї штукою треба користуватися дуже обережно — лише коли ви впевнені, що використовувати лише імена зазначеного простору, інакше можуть виникнути труднощі. Не впевнені - кращим лінуйтеся та вочевидь вказуйте, до якому простору імен належить дане ім'я.

Дальше в нас функція _tmain. Чому ж _tmain? І чому там тип TCHAR*, а чи не char*? І що ще за параметр TCHAR* envp[] ?

Ну що саме, для цікавляться розтлумачу. Функція називається _tmain і тип параметрів TCHAR* оскільки середовище генерує нам такий код, щоб забезпечити сумісність з різними кодуваннями тексту, різних типів char — те й многобайтных тощо. тощо. Не вдаватимуся в усі подробиці, та й що мені сіло: main чи _tmain, char чи TCHAR? Нам зараз, загалом, сенс не змінюється: _tmain — головна функція у програмі, TCHAR* - рядок тексту. Про всі ці проблеми до стандартів вже поZabot’илась середовище. І це щодо envp ?

Как бачите, TCHAR* envp[] - теж масив рядків. Він необхідний роботи зі змінними оточення. Хто невідомо про перемінні оточення — читайте щось про MS-DOS (напр., Фигурнов «IBM PC для користувача»). Оскільки роботу з перемінними оточення і процесами в консолі (яке часто того і треба) негаразд проста, не надто часто використовується, то докладніше у цій статті я роз’ясняти про них буду. Вистачить із нас аргументів командної рядки.

Ниже йде оголошення перемінної nRetCode — вона повертатися функцією _tmain як код помилки. Нагадую, якщо 0 — виконання програми завершилося успішно, а то й 0 — то неуспішно :).

Затем слід власне ініціалізація MFC. Зазвичай (в GUI-приложениях) це відбувається так: при ініціалізації об'єкта класу CWinApp (чи похідного від цього) функцією WinMain, що є частиною бібліотеки MFC, викликається функція AfxWinInit та перевіряється яке нею значення. Але, оскільки консольні докладання не використовують функцію WinMain, нам доводиться викликати функцію AfxWinInit безпосередньо. А вона в нашій цьому випадку просить чотири параметра:

HINSTANCE hInstance.

— дескриптор поточного модуля;

HINSTANCE hPrevInstance.

— дескриптор попередньої копії докладання; для Win32-приложений цей параметр завжди NULL;

LPTSTR lpCmdLine.

— покажчик на командний рядок поточного процесу;

int nCmdShow.

— визначає, як має бути основне вікно GUI-приложения (оскільки не GUI-приложение, цей параметр теж 0);

Что, типи даних дивні? Та, дивні… Не буду я вам сьогодні про них розповідати — занадто багато буде. Пошкодую вас — не зараз мізки вам цим пудрити. Все що у цей час вам треба зазначити, я пояснив.

Значит так, другого продажу та четвертий параметр ми нуль, я сказав, тоді як звідки ми беремо не перший і третій. Як першого параметра ми використовуємо функцію GetModuleHandle. Вона якраз і повертає нам дескриптор модуля (файла .dll чи .exe), ім'я якого вказується як параметра. Коли це параметр нульовий (як ми), повертається дескриптор файла, використаного до створення поточного процесу. Що занадто круто звучить? Не зрозуміло, почитайте щось за архітектурою і основним концепціям Windows… Почитайте про процеси, дескриптори тощо. Хоча, можливо, і так разберётесь? Гаразд. Як третього параметра ми використовуємо функцію GetCommandLine, возвращающую покажчик на командний рядок (формату Unicode) поточного процесу. Хто невідомо, два двокрапки перед ім'ям функції ставиться, оскільки це — глобальна функція Windows.

Что ми далі йде? О, згадав, після перевірки умови, якщо функція AfxWinInit вернёт не 0 (пам'ятаєте, адже в нас записано «а то й» if (!AfxWinInit …), він передано повідомлення про помилку з допомогою стандартного небуферизованного потоку діагностики помилок cerr. В нього синтаксис той самий, як і в cout. Кому цікаво, макрос _T використовується на вирішення все тієї ж труднощів із кодуваннями (Unicode, ANSI …) Нагадую, про потоках читайте незабаром розділ «Мова програмування З++». І ясна річ, нашому «сторожу» nRetCode присвоюється значення 1. Інакше (якщо ініціалізація MFC пройшла успішно) виконуватиметься код нашої програми. Саме сюди ми й писати свій програмний код. Що стосується нашої заготівлі це просто висновок на екран строкового ресурсу. Оголошуємо strHello типу CString. Далі рядком.

strHello.LoadString (IDS_HELLO);

мы, використовуючи функцію LoadString, що є членом класу CString, завантажуємо строковый ресурс Windows, має ідентифікатор IDS_HELLO в існуючий об'єкт strHello. Далі ця об'єкт виводиться на екран з допомогою стандартного потоку виведення cout. Кому цікаво, (LPCTSTR) — знов-таки на вирішення труднощів із кодуваннями.

Ну і, нарешті, повертається наш «сторож» nRetCode.

Вот, власне, і! Ви що, завантажив за повною? Нічого, розбирайтеся, книжки читайте, MSDN читайте, «медитируйте» :).

Хотелось б ще сказати, що саме усе ж таке MSDN. MSDN — це здоровенний довідник для програмування в Visual Studio .NETy. Там є все: і за мовою З++, і з програмування в Microsoft Visual З++ і ще дуже багато чого корисного. Усе це принадність розміщається у трьох CD, і за установці на жорсткий диск важить порядку 2Гб. Так, на англійському. Але розібратися можна. Одне слово, рекомендую.

Что ж ви тепер знаєте і вмієте? Ви знаєте, як зробити так і використовувати усі 4 типу заготовок консольных додатків, знаєте майже переважають у всіх деталях, що у цих заготовках й навіщо потрібно, отже, можете і самі такі речі творити. Понад те, розібравшись у цих заготовках, ви тепер знаєте, як найкраще з їхньої основі розпочати створювати свій робочий додаток. Але саме робоче додаток ми не створювали. Я вас лише «наносив», натренував маненько для війни з Матрицею і її отродьями, бою ще був. Але він! Попереду нас чекає перший, хай і невеликий, але реальний в бій із Матрицею. Як-от, ми із Вами у наступному статті зробимо наше перше реально КОРИСНЕ консольное додаток. Сьогодні ми із Вами підготувалися. Битва попереду!

Список литературы

Н.Секунов «Самовчитель Visual З++ 6»;

Бьерн Страуструп «Мова програмування З++»;

Джесс Ліберті «Освой З++ самостійно за 21 день»;

MSDN for Visual Studio .NETy;

Содержимое заголовочных файлів (.h) середовища Visual З++;

Юджин Олафсен, Кенн Скрайбер, Девід Вайт «MFC і Visual З++ 6»;

В.Э. Фигурнов «IBM PC для користувача».

Zabot 2004.

Список литературы

Для підготовки даної праці були використані матеріали із російського сайту internet.