Документация по работе с библиотекой. Структура программы: блочная Блочная структура


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

Имя в программе может быть простым или составным. К простым именам относятся имена переменных, имена подпрограмм, имена пользовательских типов данных. Составное имя ссылается на элемент некоторой структуры и записывается как простое имя и следующие за ним операции квалификации или индексации имени. Например, выражение array1 ссылается на третий элемент массива, а выражение record1.field2 ссылается на значение поля field2 структуры record1 .

Для управления данными конкретные идентификаторы подпрограммы должны быть сопоставлены конкретным объектам данных. Такое сопоставление иногда называется ассоциацией. В момент создания записи активации устанавливается множество ассоциаций, сопоставляющих идентификаторы с текущими объектами данных. Такое множество ассоциаций определяет среду ссылок подпрограммы.

Среда ссылок подпрограммы включает среду глобальных ссылок, среду локальных ссылок, среду нелокальных ссылок и среду предопределенных ссылок.

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

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

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

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

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

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

int1=5*x; int2=8*y;

Значение переменной int1 нигде в программе не используется, то при оптимизации программы первый оператор может быть упразднен. Но если переменная int1 является псевдонимом переменной y , то такая оптимизация приведет к ошибке вычисления, и, следовательно, потребуются дополнительные проверки.

Под статической областью видимости понимается фрагмент кода программы, в котором идентификатор ссылается на конкретный объект .

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

Блочно-структурированные языки программирования

В блочно- структурированных языках программирования программа записывается как множество иерархически вложенных блоков определенной структуры.

Блочно- структурированные языки программирования можно подразделить на строго блочно- структурированные языки и просто блочно- структурированные языки .

В строго блочно- структурированных языках в начале каждого блока располагается область объявлений, а за ней следует фрагмент кода. Иначе говоря, в строго блочно- структурированных языках программирования не допускается объявление переменных в любом месте фрагмента кода.

К строго блочно- структурированным языкам программирования относятся языки ALGOL 60, Pascal , PL/I .

Каждый блок в блочно-структурированном языке программирования вводит новую среду локальных ссылок.

Следующий пример иллюстрирует блочную структуру программы на языке Pascal .

program Project1; procedure P1(); procedure P2(); {Вложенная процедура} var i:Integer; begin end; begin {Код процедуры P1} end; begin {Код главной программы Project1} end.

В языке Object Pascal по умолчанию приложения создаются как набор модулей, подключаемых ключевым словом uses . Следующий пример иллюстрирует блочную структуру программы на языке Object Pascal , представленную в виде одного модуля.

Program Project2; {Начало программы} uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; {$R *.res} {$R *.dfm} {Имя DFM-файла должно совпадать с именем модуля (блока). } {Для получения единого модуля на языке Object Pascal при автоматическом создании приложения в среде Delphi файл Unit1.dfm следует переименовать в Project2.dfm, а код модуля Unit1.pas перенести в модуль Project2.pas} type {Объявление нового типа окна формы TForm1 } TForm1 = class(TForm) Button1: TButton; Button2: TButton; ListBox1: TListBox; Edit1: TEdit; procedure Button1Click(Sender: TObject); procedure Button2Click(Sender: TObject); procedure ListBox1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var {Начало области объявлений } Form1: TForm1; i: Integer; procedure TForm1.Button1Click(Sender: TObject); begin Edit1.Text:="Button1"; end; procedure TForm1.Button2Click(Sender: TObject); var i:Integer; procedure P1(); {Вложенная процедура} var i:Integer; begin i:=5; Edit1.Text:= Edit1.Text+" i= " + IntToStr(i); end; begin Edit1.Text:="Button2"; i:=0; P1 (); end; procedure TForm1.ListBox1Click(Sender: TObject); begin Edit1.Text:="ListBox1"; end; begin {Начало выполнения программы} Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end. Пример 5.1. Блочная структура программы на языке Object Pascal

Модульная структура программы

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

Усиление внутренних связей модулей;

Ослабление взаимосвязи между модулями.

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

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

Модульная структура библиотеки представлена в приложении Д на рисунке Д.1, визуализатора на рисунке Д.2.

Тестирование

Из всех этапов отладки программного обеспечения тестирование является самым трудоемким и дорогим. При создании типичного программного обеспечения на тестирование приходится около 40% общего времени и более 40% общей стоимости программного обеспечения.

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

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

Документирование

Техническое задание

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

6.1.1 Назначение разработки

Программный комплекс предназначен для генерации и отображения ландшафтов.

6.1.2 Требования к программе или программному изделию

Для пользователя приложение должно предоставлять следующие возможности:

1) возможность введения входных данных, таких как минимальная и максимальная высота, размеры карты, крутизны гор;

2) генерация ландшафтов;

3) сохранение ландшафта для использования его в сторонних программах;

4) демонстрация получившегося результата, путем вывода картинки на экран.

6.1.3 Требования к надежности

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

6.1.4 Требования к составу и параметрам технических средств

Для минимального функционирования программы требуется: персональный компьютер, 2 ГБ оперативной памяти, 50 Мб свободного места на жестком диске; клавиатура, мышь.

Для оптимальной работы приложения необходимо оперативной памяти не менее 3ГБ оперативной памяти.

6.1.5 Требования к информационной и программной совместимости

Программа должна функционировать под управлением ОС семейства Windows 7 и выше; DirectX 11; Visual c++2015; .Net Framework 4.5 и выше.

6.1.6 Требования к программной документации

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

Руководство пользователя

Запуск программы производится запуском файла shell.exe, после запуска вы увидите окно, представленное на рисунке 6.1.

Вызвать меню «файл», можно с помощью кнопки «очистить» сбросить данные до стандартных значений. С помощью кнопки «Сохранить как bmp» сохранить карту высот в формате bmp. С помощью кнопки «Сохранить как obj» можно сохранить ландшафт в формате obj. Нажав на кнопку «Просмотр» запуститься визуализатор, в котором можно будет увидеть в трехмерном виде, представлен на рисунке 6.2.

Рисунок 6.1 - Окно программы


Рисунок 6.2 - Окно программы

Вызвать меню «настройки», можно с помощью кнопки «настройки программы» настроить программу для визуализации. С помощью кнопки «настройки визуализации» можно настроить визуализатор.

Движение в визуализаторе осуществляется кнопками на клавиатуре w, a, s, d, которые соответствуют направлениям вперед, влево, вправо, назад.

Управление камерой осуществляется мышкой.

Документация по работе с библиотекой

Для работой с библиотекой необходимо подключить файл LandscapeGenerator.dll к вашему проекту. В проекте необходимо объявить экземпляр класса LandscapeGenerator. Класс содержит следующие методы для изменения параметров ландшафта, такие как ширина, длина, минимальная и максимальная высота, гористость, генерации ландшафта, возврат ландшафта как bitmap, сохранение ландшафта в формате obj и bmp.

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

С помощью модулей можно создавать библиотеки подпрограмм, которые могут храниться как в виде исходного, так и в виде объектного кода (кода, уже готового к совместной компиляции и объединению с другими модулями). В Delphi откомпилированный объектный код модуля хранится в файлах с расширением «.dpu».

Структура модуля аналогична структуре программы на языке Паскаль. Заголовок для модуля обязателен и начинается со слова UNIT (вместо PROGRAM как в обычной программе):

Unit <имя модуля>;

Имя модуля должно совпадать с именем файла на языке Pascal. Когда Delphi автоматически генерирует различные модули, он делает так, чтобы имя модуля совпадало с именем файла.

В отличие от программы, тело модуля (раздел операторов) может отсутствовать. Оно используется для инициализации переменных модуля и производится перед выполнением операторов основной программы. Модуль содержит две обязательные части: интерфейсную и исполнительную.

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

Интерфейсная часть начинается со слова Interface. Через интерфейс осуществляется связь основной программы с модулем или модуля с другими модулями. В интерфейсной части указываются объекты (процедуры, функции, переменные, константы, типы), доступные любым пользователям этого модуля.

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

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

Uses M1 , М2 ...;

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

Интерфейсная часть заканчивается с началом исполнительной части. Исполнительная часть начинается с ключевого слова Implementation. Она содержит тела всех процедур и функций, описанных в интерфейсной части. Она может включать локальные метки функций и разделов операторов. После слова Implementation также может следовать слово Uses со списком модулей, которые используются в исполнительной части. Далее указываются метки, типы, константы, переменные, процедуры и (Ьункпии модуля.

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

В конце модуля может идти необязательная часть завершения, начинающаяся с ключевого слова Finalization, в которой размещаются операторы, выполняемые при любом завершении работы модуля. Завершается модуль ключевым словом «end.» с обязательной точкой в конце.

Кратко синтаксис описания модуля выглядит так:

Если в разных модулях используются одноименные переменные, то для доступа к переменной модуля следует использовать префикс:

<имя модуля>. <имя переменной>.

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

пометка">тесная взаимосвязь между модулями (или высокая степень сцепления модулей), и в таком случае становится невозможно использовать их по отдельности, что нарушает принципы модульного программирования.

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

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

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

Около вершин графа прописываются интерфейсные элементы: имена процедур, функций, констант, переменных, объявленных в открытой части модуля, которые далее более подробно описываются в комментариях к модулю в виде полного описания интерфейсной части. Над дугами прописываются те имена, которые используются в связанном (обычно родительском) модуле. При этом связь может быть перекрестной, т.е. модуль А использует интерфейсные элементы модуля В и. наоборот, модуль В использует интерфейсные элементы модуля А. Как уже говорилось, такое проектирование нежелательно, но возможно. В этом случае используемые интерфейсные элементы прописываются над и под дугой, соединяющей модули. Приведем пример такого графа (рис. 10.1
).

Здесь основная программа Р разбивается на три основных модуля М1, М2, МЗ. Из этих модулей в программе используются интерфейсные элементы А, В, С (из первого модуля), D (из второго модуля), F, G, К, L (из третьего модуля). Каждый из этих модулей разбивается на более мелкие, например, М2 разбивается на М2.1, М2.2, М2.3 и т.д. Из этой схемы, например, видны перекрестные ссылки между модулями М2 и М3, а также между М2.2 и М2.3.

После завершения модуляризации каждый модуль распределятся для кодирования между программистами с целью независимого написания кода и отладки. Однако в таких случаях часто возникает ситуация, когда в родительском модуле предполагается использование процедур и функций дочерних модулей, но дочерние модули еще не закодированы другими программистами. Например, в модуле МЗ используются элементы К, L из дочерних модулей, но эти модули пока не готовы. Как быть программисту, реализующему код модуля МЗ? Выход из этой ситуации осуществляется посредством написания в родительском модуле процедур (или функций) «заглушек», которые по имени и параметрам полностью совпадают с элементами К, L. Заглушки позволяют компилировать и выполнять программу в отладочном режиме.

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

формула" src="http://hi-edu.ru/e-books/xbook691/files/ris-page173.gif" border="0" align="absmiddle" alt="

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

Связность модуля определяется как мера независимости составляющих частей модуля. Чем выше связность модуля, тем лучше результат проектирования. Типы связности (в скобках указан коэффициент силы связности):

  • функциональный (сильная связность) - 10;
  • последовательная - 9;
  • коммуникативная - 7;
  • процедурная - 5;
  • временная - 3;
  • логическая - 1;
  • по совпадению (слабая связность) - 0.

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

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

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

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

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

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

Если операторы модуля объединяются произвольным образом, например, когда нужно указать их размещение в области памяти, такой модуль имеет связность по совпадению.

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

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

4.8. Блочная структура.

Язык “C” не является языком с блочной структурой в смыс-

ле PL/1 или алгола; в нем нельзя описывать одни функции

внутри других.

Переменные же, с другой стороны, могут определяться по

методу блочного структурирования. Описания переменных (вклю-

чая инициализацию) могут следовать за левой фигурной скоб-

кой,открывающей любой оператор, а не только за той, с кото-

рой начинается тело функции. Переменные, описанные таким об-

разом, вытесняют любые переменные из внешних блоков, имеющие

такие же имена, и остаются определенными до соответствующей

правой фигурной скобки. Например в

INT I; /* DECLARE A NEW I */

FOR (I = 0; I < N; I++)

Областью действия переменной I является “истинная” ветвь

IF; это I никак не связано ни с какими другими I в програм-

Блочная структура влияет и на область действия внешних

переменных. Если даны описания

То появление X внутри функции F относится к внутренней пере-

менной типа DOUBLE, а вне F - к внешней целой переменной.

это же справедливо в отношении имен формальных параметров:

Внутри функции F имя X относится к формальному параметру, а

не к внешней переменной.

4.9. Инициализация.

Мы до сих пор уже много раз упоминали инициализацию, но

всегда мимоходом, среди других вопросов. Теперь, после того

как мы обсудили различные классы памяти, мы в этом разделе

просуммируем некоторые правила, относящиеся к инициализации.

Если явная инициализация отсутствует, то внешним и ста-

тическим переменным присваивается значение нуль; автомати-

ческие и регистровые переменные имеют в этом случае неопре-

деленные значения (мусор).

Простые переменные (не массивы или структуры) можно ини-

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

равенства и константное выражение:

CHAR SQUOTE = "\”;

LONG DAY = 60 * 24; /* MINUTES IN A DAY */

Для внешних и статических переменных инициализация выполня-

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

регистровые переменные инициализируются каждый раз при входе

в функцию или блок.

В случае автоматических и регистровых переменных инициализа-

тор не обязан быть константой: на самом деле он может быть

любым значимым выражением, которое может включать определен-

ные ранее величины и даже обращения к функциям. Например,

инициализация в программе бинарного поиска из главы 3 могла

бы быть записана в виде

INT HIGH = N - 1;

INT LOW, HIGH, MID;

По своему результату, инициализации автоматических перемен-

ных являются сокращенной записью операторов присваивания.

Какую форму предпочесть - в основном дело вкуса. мы обычно

используем явные присваивания, потому что инициализация в

описаниях менее заметна.

Автоматические массивы не могут быть инициализированы. Внеш-

ние и статические массивы можно инициализировать, помещая

вслед за описанием заключенный в фигурные скобки список на-

чальных значений, разделенных запятыми. Например программа

подсчета символов из главы 1, которая начиналась с

INT C, I, NWHITE, NOTHER;

NWHITE = NOTHER = 0;

FOR (I = 0; I < 10; I++)

Ожет быть переписана в виде

INT NDIGIT = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };

MAIN() /* COUNT DIGITS, WHITE SPACE, OTHERS */

Эти инициализации фактически не нужны, так как все присваи-

ваемые значения равны нулю, но хороший стиль - сделать их

явными. Если количество начальных значений меньше, чем ука-

занный размер массива, то остальные элементы заполняются ну-

лями. Перечисление слишком большого числа начальных значений

является ошибкой. К сожалению, не предусмотрена возможность

указания, что некоторое начальное значение повторяется, и

нельзя инициализировать элемент в середине массива без пере-

числения всех предыдущих.

Для символьных массивов существует специальный способ

инициализации; вместо фигурных скобок и запятых можно ис-

пользовать строку:

CHAR PATTERN = “THE”;

Это сокращение более длинной, но эквивалентной записи:

CHAR PATTERN = { "T", "H", "E", "\0" };

Если размер массива любого типа опущен, то компилятор опре-

деляет его длину, подсчитывая число начальных значений. В

этом конкретном случае размер равен четырем (три символа

плюс конечное \0).


Основаниям. При этом философская абстракция языка оказывается неразрывно связана с основными темами и движениями философии в целом. Более конкретно, на ранние стадии традиционно рассматриваемого в рамках АФ анализа обыденного языка глубокое влияние оказала философия Дж. Э. Мура, особенно его учение о здравом смысле, согласно которому такие понятия, как «человек», «мир», «я», «внешний мир», « ...

И других странах СНГ, а также облегчение доступа к русской и мировой культуре и науке. Таким образом, судя по данным наших исследований, востребованность русского языка осталась в республике достаточно высокой. Многие представители современной молдавской молодежи продолжают, как их отцы и деды, тянуться к русской культуре, научным и техническим достижениям России. Русский язык остается языком...

Рисуночное словесно-слоговое письмо). Памятники среднеэламского периода (14-12 вв. до н.э.) выполнены аккадской клинописью. Памятники новоэламского периода относятся к 8-6 вв. до н.э. Был официальным языком в персидском государстве Ахеменидов в 6-4 вв. предполагается, что он, подвергшись влиянию древнеперсидского, сохранился до раннего средневековья. 7. Бурушаски язык Язык бурушаски (...

... /диалект), скифский, согдийский, среднеперсидский, таджикский, таджриши (язык/диалект), талышский, татский, хорезмийский, хотаносакский, шугнано-рушанская группа языков, ягнобский, язгулямский и др. Они относятся к индоиранской ветви индоевропейских языков. Области распространения: Иран, Афганистан, Таджикистан, некоторые районы Ирака, Турции, Пакистана, Индии, Грузии, Российской Федерации. Общее...

Раньше на просторах Интернета был широко распространён табличный тип вёрстки, которому посвящена . Однако со временем этот подход к созданию структуры сайта устарел, и на смену ему пришла блочная вёрстка.

Отличия блочной вёрстки от табличной

Если табличная вёрстка подразумевает, что содержимое страницы находятся внутри тега

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

Блочная вёрстка лишена недостатков табличной - поисковыми системами она индексируется лучше, её код не такой развесистый, да и блоки

, которые так любят называть «слоями», изначально задумывались универсальными, то есть «для всего», тогда как
- это таблица, которую нужно использовать для отображения табличных данных и не более того.

Единственный ощутимый минус блочной вёрстки - сделанные на ней сайты могут по-разному отображаться в обозревателях. Чтобы этого избежать, нужно делать вёрстку «кроссбраузерной», то есть одинаково отображаемой любым обозревателем.

Суть блочной вёрстки

В графическом редакторе создаётся макет сайта: размечается, где какая область страницы (шапка, низ, боковая панель, основной контент) будет находиться и сколько места занимать, готовятся картинки, фоны.

Каждая часть страницы помещается в свой блок

: верх сайта - в первый, меню - во второй, контент - в третий и т. д. Каждый блок наполняется содержимым средствами HTML, а также позиционируется и оформляется с помощью CSS-разметки.

Конечный HTML-документ представляет собой набор блоков

с контентом внутри. Оформление зачастую находится в отдельном CSS-файле, подключенном к странице тегом , или как минимум в контейнере