Особенности работы с многофайловыми проектами

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Лабораторная работа №13. Модули. Многофайловые проекты

Цель работы – ознакомиться с возможностью работы с многофайловыми проектами в среде разработки Visual Studio и научиться применять полученные знания при создании собственных модулей.

- ознакомиться с описанием лабораторной работы;

- получить задание у преподавателя, согласно своему варианту;

Особенности работы с многофайловыми проектами

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

Среда разработки Visual Studio 2008, как и подавляющее большинство других, поддерживают создание, компиляцию и сборку многофайловых проектов.

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

Модуль содержит данные и функции для их обработки. Для того чтобы его использовать достаточно знать его интерфейс, а не все детали реализации. Сокрытие деталей реализации называется инкапсуляцией.

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

Исходные тексты совокупности функций для решения какой-либо подзадачи, как правило, размещаются в отдельном модуле (файле). Такой файл называют исходным (sources). Обычно он имеет расширение.c или.cpp Прототипы всех функций исходного файла выносят в отдельный так называемый заголовочный файл (header file), для него принято использовать расширение.h или.hpp.

Таким образом, заголовочный файл xxx.h содержит интерфейс для некоторого набора функций, а исходный файл ххх.срр содержит реализацию этого набора. Если некоторая функция из указанного набора вызывается из какого-то другого исходного модуля ууу.срр, то обязаны включить в этот модуль заголовочный файл xxx.h с помощью директивы #include. Негласное правило стиля программирования на C++ требует включения этого же заголовочного файла (с помощью #include) и в исходный файл ххх.срр.

Хотя использование глобальных переменных считается дурным тоном в программировании, иногда возникают ситуации когда невозможно избежать их использования. В многофайловом проекте возможны два «вида глобальности переменных». Если некоторая глобальная переменная glvar1 объявлена в файле ххх.срр с модификатором static, то она видима от точки определения до конца этого файла, то есть области видимости ограничена файлом. Если же другая глобальная переменная glvar2 объявлена в файле ххх.срр без модификатора static, то она может быть видимой в пределах всего проекта. Правда, для того, чтобы она оказалась видимой в другом файле, необходимо в этом файле ее объявление с модификатором extern (рекомендуется это объявление поместить в файл xxx.h).

- определения типов, задаваемых пользователем, констант, шаблонов;

- объявления внешних глобальных переменных (с модификатором extern);

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

Для решения этой проблемы рекомендуется использовать так называемые стражи включения. Данный способ состоит в следующем: чтобы предотвратить заголовочных файлов, содержимое каждого.h файла должно находиться между директивами условной компиляции #ifndef #endif, а внутри устанавливаться признак включения при помощи директивы #define.