1. Спецификация const для данных. Назначение.

Квалификатор const позволяет создавать типизированные константы, с ограниченной областью видимости в отличие от констант, определенных #define. Задать значение константе можно только при создании.

const int size=100;

int a[size];

const double pi=3.14159265358979323846;

Также этот квалификатор используется для указания, что параметр не меняется внутри функции.

char *strcpy(char *dst, const char *src);

Самый простой случай — константные данные. Возможно несколько вариантов записи: const int i(1);

int const j(1);

int const k=1;

Все они правильные и делают одно и тоже — создают переменную, значение которой изменить нельзя.

При использовании const с указателями, действие модификатора может распространяться либо на значение указателя, либо на данные на которые указывает указатель. Работает (const относится к данным): const char * a = "a";

a="b";

Тоже самое и тоже работает: char const * a = "a";

a="b";

Существует мнемоническое правило, позволяющее легко запомнить, к чему относится const. Надо провести черту через "*", если const слева, то оно относится к значению данных; если справа — к значению указателя. Ну и конечно, const можно написать дважды: const char * const s = "data"

2. Спецификация inline для функций. Назначение.

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

inline int max(int x, int y)

{ return x>y?x:y;

}

Макроопределение #define max(x,y) ((x)>(y)?(x):(y)) работает для любых типов данных. Чтобы функция max работала так же, её нужно определить как шаблон:

template <typename T>

inline T max(T x, T y)

{ return x>y?x:y;

}

3. Модульность в С++. Что пишется в файле .h, что в файле .cpp? Как использовать модуль, разбитый на эти 2 файла, в своих программах?

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

Файл module1.h:

struct point {

double x,y;

double len();

};

extern point p1;

Файл module1.cpp:

#include "module1.h"

#include <math.h>

double point::len()

{ return sqrt(x*x+y*y);

}

point p1;

Файл module2.cpp:

#include "module1.h"

...

int main()

{ point a=p1;

cout<<a.len()<<"\n";

...

}

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

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

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