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

Помнится, в прошлой статье «Первая программа в Microsoft Visual C++ 6.0» я пообещал рассказать, как создавать консольные приложения в Visual C++ с помощью мастера. Обещания я привык всегда выполнять. Значит, этим сейчас и займёмся. В прошлый раз мы сами писали программный код в текстовом редакторе, среда же нам его компилировала, компоновала и запускала на выполнение. Да, это её работа, но мы её ещё кое-чем загрузим. Я уже говорил, что среда для того и нужна, чтобы выполнять за нас рутинную работу. Ну что, ща продемонстрируем!

Запускаем великий и могучий Visual C++. Жмём 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 C++ удосужился-таки сделать нам файл исходного кода (у меня проект назван 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

Рекомендуем скачать другие рефераты по теме: особенности реферата, реферат скачать без регистрации.



1  2  3  4  5 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки