Андроид. Windows. Антивирусы. Гаджеты. Железо. Игры. Интернет. Операционные системы. Программы.

Блочная структура. Процедуры и функции. Блочная структура программы. Параметры. Модульная структура программы

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

Имя в программе может быть простым или составным. К простым именам относятся имена переменных, имена подпрограмм, имена пользовательских типов данных. Составное имя ссылается на элемент некоторой структуры и записывается как простое имя и следующие за ним операции квалификации или индексации имени. Например, выражение 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

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

Внешний блок – это блок, в который вложена подпрограмма. Внутренний блок - сама подпрограмма. Все описания, расположенные во внешних для данной подпрограммы блоках, называются глобальными по отношению к блоку, который образует данная подпрограмма. Все описания, расположенные во внутреннем блоке называются локальными. Можно ввести понятие уровень вложенности. Если в разделе описания процедур и функций описаны две или более подпрограмм, то говорят, что эти подпрограммы одного уровня вложенности. По отношению к внешнему блоку они являются внутренними. По отношению между самими подпрограммами мы не можем использовать термины внешняя или внутренняя, так как они одного уровня вложенности. Если в разделе описания процедур и функций внешнего блока вложена подпрограмма, внутри которой в таком же разделе расположена другая подпрограмма, то мы говорим о разном уровне вложенности этих подпрограмм. Для третьего блока, представляющего собой самую внутреннюю подпрограмму, оба блока, в которые она вложена, будут внешними. Уровень вложенности этой подпрограммы 2. Для второго блока третий блок будет внутренним, а первый - внешним. Уровень вложенности второго блока 1. Для первого блока (самого внешнего) второй и третий блоки будут внутренними. Уровень вложенности первого блока 0, т.е. этот блок является основной программой.

Для примера рассмотрим структуру блоков, предложенную автором языка (рис.16.16). Здесь в седьмой раздел программы A вложены две подпрограммы B и C. В подпрограмму В вложена подпрограмма D. В свою очередь в подпрограмму D вложена подпрограмма G. В подпрограмму С вложены две подпрограммы E и F.

Рис. 16.16. - Пример блочной структуры

Разберемся со сферой действия описаний. Описания меток действуют только внутри раздела операторов блока, в котором они описаны. Все остальные описания действуют не только внутри блока, в котором они описаны, но и во всех внутренних блоках, вложенных в данный блок (вне зависимости от глубины вложенности). При этом казалось, что могут возникнуть конфликты между глобальными и локальными описаниями , так как в разных блоках одинаковыми именами могут быть поименованы разные понятия. Для того чтобы таких конфликтов не возникало, принято следующее правило - все имена, определяемые в локальных описаниях, отменяют действия совпадающих имен, описанных в глобальных описаниях. На рис. 16.17 показано расположение блоков из примера по уровням. Здесь линиями со стрелками показано действие глобальных описаний. Так в блоке G действуют описания внешних блоков D, B, A.

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

Особо рассмотрим доступ к подпрограммам. Любая подпрограмма может быть вызвана:

    из раздела операторов блока, в котором она описана;

    из раздела операторов самой себя (прямая рекурсия);

    из раздела операторов любой внутренней подпрограммы по отношению к данной (косвенная рекурсия);

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

Эти правила можем переформулировать следующим образом – любая подпрограмма может вызывать на исполнение:

    любую подпрограмму, описанную в разделе подпрограмм данной;

    саму себя (прямая рекурсия);

    все внешние подпрограммы по отношению к данной (косвенная рекурсия);

    подпрограммы, описанные ранее на том же уровне вложенности.

Взаимодействие блоков (подпрограмм) из примера показано на рис. 16.18.

Рис. 16.18 - Пример взаимодействия между блоками

Здесь линиями со стрелками показаны возможности вызова подпрограмм на выполнение (стрелки указывают направление вызова). Так, например, из программы А могут быть вызваны только подпрограммы В и С, которые вложены в седьмой раздел. Из подпрограммы F могут быть вызваны сама подпрограмма F (прямая рекурсия), подпрограмма С, в которую она вложена (косвенная рекурсия), и подпрограмма Е (находится на одном уровне и описана ранее). з программы А могут быть вызваны подпрограммы B и С. В таблице 16.9 для перечислены все возможные взаимодействия между блоками. Здесь основной алгоритм – блок, из которого производится вызов подпрограммы, вспомогательный алгоритм – вызываемая подпрограмма.

Таблица 16.9. Пример взаимодействия между блоками

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

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

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

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

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

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

Модульная структура библиотеки представлена в приложении Д на рисунке Д.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.

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

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

Любое ПС имеет свою структуру, которая разрабатывается для удобства:

  • 1. разработки
  • 2. программирования
  • 3. отладки
  • 4. внесения изменений

Также структуризация ПС позволяет:

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

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

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

Типовая структура ПС:

носитель отладка программный модуль

Таблица. Типы модулей

Свойства модуля:

  • 1. один вход и один выход - на входе программный модуль получает определенный набор исходных данных, выполняет обработку данных и возвращает результат
  • 2. функциональная завершенность - модуль выполняет перечень операций для реализации каждой отдельной функции в полном составе.
  • 3. логическая независимость - результат работы модуля зависит только от исходных данных, и не зависит от работы других модулей.
  • 4. слабые информационные связи с другими программными модулями - обмен информации между модулями должен быть по возможности минимизирован.
  • 5. обозримый по размеру и сложности.

Каждый модуль состоит из спецификации и тела модуля.

Спецификация - правила использования модуля.

Тело - способ реализации процесса обработки.

Принцип модульного программирования ПС:

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

При составлении алгоритма необходимо учитывать:

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

Методы разработки структуры программы.

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

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

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

Существуют разные методы разработки структуры программы. Обычно используют 2 метода:

  • 1. Метод восходящей разработки
  • 2. метод нисходящей разработки

Метод восходящей разработки.

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

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

Метод нисходящей разработки.

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

Положительные стороны

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

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

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

Конструктивный подход (Модификация нисходящей разработки)

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

Рис. 7.1

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

Архитектурный подход (модификация восходящей разработки)

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

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

Рис. 7.2

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

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. Бурушаски язык Язык бурушаски (...

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

Похожие публикации