Реферат: Мобильное программирование в среде ОС UNIX - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Мобильное программирование в среде ОС UNIX

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 366 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

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

Мобильное программирование в среде ОС UNIX Содержание Мобильное пр ограммирование в среде ОС UNIX Стандартные библиотеки Библиотека системных вызовов Библиотека ввода /вывода Дополнительные библиотеки Файлы заголовков Мобильность на уровне исходных текстов Особенности мобильного программирования на языке Си Обеспеч ение независимости от особенно стей версии ОС UNIX Бинарная совместимость Возможности достижения бинарной совместимост и Преимущества и ограничения Стандартные би блиотеки Очевидным требован ием к операционной среде , поддерживающей моби льное прикладное п рограммирование , является то , что все функции , предоставляемые ею прикладной программе , должны быть четко специ фицированы и должны точно соответствовать эти м спецификациям в любой реализации операционн ой среды . В UNIX-ориентированных средах это т ребование удовлетворяется за счет нал ичия нескольких стандартизованных библиотек функ ций и соответствующих наборов файлов заголовк ов (header-файлов ). Библиотека систем ных вызовов Базовой библиотеко й любого варианта системы UNIX является библиоте ка системных вызовов . Сейчас невозможно найти два варианта ОС UNIX с разными названия ми , наборы системных вызовов которых полность ю бы совпадали . Однако , любой такой вариан т поддерживает системные вызовы , которые спец ифицированы в стандартах , упоминаемых в разде ле 7.5. К пол н остью стандартным систе мным вызовам относятся системные вызовы для работы с файлами (включая специальные фай лы ), системные вызовы для управления процессам и ( fork и семейство exec ), системные выз овы класса IPC (хотя , как мы упоминали в п . 3.5.4, в UNIX Syst em V механизм программных каналов реализован не в виде набора системных выз овов ядра ОС , а как набор библиотечных функций над пакетом TLI). Приведенное в скобках замечание на самом деле является очень важным . Пользователя , стремящегося создать моби льное п р иложение с использованием системных вызовов , не должны волновать дета ли реализации . Важно , чтобы состав системных вызовов , их интерфейсы и семантика соответс твовали стандартам . Теперь мы можем сформулировать правило прикладного мобильного программирования с использованием системных вызовов : Проектируя и разрабатывая прикладную сист ему , убедитесь , что вы не используете сист емные вызовы , не входящие в стандарт . Придерживаясь этого правила , с большой вероятностью вы не будете иметь проблем с переносом прогр аммы в среду друг ого варианта ОС UNIX по причине несовместимости наборов системных вызовов . Библиотека ввода /вывода Традиционной для ОС UNIX библиотекой функций более высокого у ровня , чем библиотека системных вызовов , являе тся , так называемая , стандартная библиотека ввода /вывода (stdio). Основной набор функций эт ой библиотеки служит для выполнения файловых операций с буферизацией данных в памяти пользовательского процесса . Библиотека ввода /вывода фактически стандартизована очень давно , и ей можно безопасн о пользоватьс я в любой операционной среде . В частности , единообразные библиотеки ввода /вывода подде рживаются во всех современных реализациях сис темы программирования языка Си , выполненных н е в среде ОС UNIX (включая реализации в ср еде MS-DOS). Поэтому можн о сформулировать правило мобильного программирования с использованием библиотеки ввода /вывода : Если для разрабатываемой вами прикладной программы достаточно возможностей библиотеки ввода /вывода , ограничьтесь использованием этой библиотеки . Придерживаясь этого правила , с больш ой вероятностью вы не будете иметь пробле м , связанных с вводом /выводом , при перенос е вашей программы в любую операционную ср еду (не обязательно UNIX-ориентированную ), в которо й поддерживается стандартная библиотека ввода /вывода . Допо лнительны е библиотеки Понятно , что пр и прикладном программировании используются не только библиотеки системных вызовов и ввод а /вывода . Существует масса других библиотечны х функций , предназначенных , например , для разно образных преобразований форматов данных , мат ематических вычислений и т.д . К таким библ иотекам нужно относиться очень осторожно , пос кольку в целях повышения эффективности соотве тствующие функции могут быть машинно-зависимыми и по этой причине обладать специфическими интерфейсами (хотя , скорее в с его , не зависят от особенностей операционной системы ). Сама по себе машинная зависимость библиотечной функции не представляет опасности , поскольку при переносе программы на комп ьютер с другой архитектурой все равно пот ребуется перекомпиляция и перекомпоно в ка прикладной программы , но специфичность интерфейсов может причинить большие неприятн ости . Наиболее безопасным решением на сегодняшн ий день (при программировании на языке Си ) является использование библиотек , специфицирован ных в стандарте языка Си . Навер ное , стандартных библиотек Си окажется недостаточно в случае сложных приложений , но если при указании опции "ANSI" ваша система программиро вания успешно производит сборку выполняемой п рограммы , можно быть почти уверенным , что вы не будете иметь проблем пр и переносе программы на компьютер , на котором установлен компилятор стандартного язы ка Си . Поэтому можно сформулировать правило моби льного программирования с использованием дополни тельных библиотек : Если для разрабатываемой вами прикладной системы оказыва ется достаточным использо вание библиотек , специфицированных в стандарте языка Си , ограничьтесь использованием этих библиотек . Если стандартных библиотек оказывается не достаточно и приходится использовать функцию из некоторой дополнительной библиотеки , под держиваемой в вашей системе , постарайтесь проверить , насколько она стандартна . Если вы не уверены в стандартности используемой функции , то лучше напишите собственную инте рфейсную функцию с известным вам интерфейсом , а при переносе прикладной программы сос т ыкуйте эту функцию (может быть , придется ее переписать ) с подходящей библио течной функцией целевой системы (однако нет гарантии , что вам удастся ее найти ). Файлы заголовков Использование текс товых файлов заголовков (header-файлов ), которые вст авляются в т екст программы на языке Си с помощью директивы include препроцессора Си , является трад иционной техникой программирования на языке С и в среде ОС UNIX, обеспечивающей синтаксическую правильность использования библиотечных функций (в том числе и системных выз овов ) в прикладной программе . Ранее файлы заго ловков , главным образом , содержали определения типов и символических констант (символические константы - это константы , которым сопоставлен ы имена посредством директивы define препроцессора Си ), используемых в интерфейсах соответствующих библиотечных функций . Корректное применение файлов заголовко в позволяло программистам не заботиться о правильности типов данных , используемых при обращении к библиотечным функциям и обрабо тке их результатов . Однако , традиционны е файлы заголовков не гарантировали того , что набор параметр ов вызываемой библиотечной функции соответствова л ее интерфейсу , поскольку объявление функции , содержащее ее интерфейс , в файле компиля ции отсутствовало . В лучшем случае ошибки такого рода устойч и во проявлялись во время выполнения программы , хотя далеко не всегда было просто понять их прир оду . В худшем случае ошибка возникала при переносе программы , поскольку одноименные би блиотечные функции действительно обладали разным и интерфейсами в разных сре д ах , и в исходной операционной среде ошибки в параметрах не было . Эту проблему удалось решить (хотя и не абсолютно ) за счет введения в язык Си понятия прототипа функции . Грубо говоря , прототип функции - это часть ее объявлени я , содержащая только интерфейс (без те ла функции ). Наличие прототипа любой функции допускается в любом файле компиляции , даже не обязательно содержащем вызов этой фун кции . Однако , если вызов функции содержится в файле компиляции , то набор параметров вызова должен точно соответствовать и нтерфейсу вызываемой функции , определенному в ее прототипе . Дальнейший ход рассуждений очевиден . Для группы родственных библиотечных функций дела ется общий файл заголовков , содержащий необхо димые определения типов данных и символически х констант , а также набор прототипов этих библиотечных функций . После включения в файл компиляции такого файла заголовков на стадии компиляции будут обнаружены все синтаксические ошибки обращения к библиотечн ым функциям . В предыдущем параграфе мы отм етили , что это решение не абсолютн о . Это действительно так , поскольку в прин ципе никто не может заставить программиста на языке Си включать в текст программы все требуемые файлы заголовков . Однако , т акова специфика мира программирования : каждый волен усложнять свою жизнь в такой с т епени , в которой ему или ей это нравится . Последнее замечание относительно файлов з аголовков . В последнее время они содержат большое количество операторов условной компиляци и , относящихся большей частью к определению символических констант . Дело в том , чт о в зависимости от версии операционно й системы (мы имеем в виду версии одно й линии ОС UNIX, например , UNIX System V) значения констант , используемых с одним и тем же смыслом , часто меняются . Конечно , прикладная программа не должна зависеть от таких измене н ий . Наличие операторов условной к омпиляции внутри файла заголовков разрешает э ту проблему . Поэтому последнее правило этого раздела можно сформулировать следующим образом : При программировании на языке Си с использованием библиотечных функций используйте все требуемые файлы заголовков . Это по может быстрее найти ошибки и повысит моби льность прикладной программы . Мобильность на уровне исходных текстов Материал , рассмотр енный нами в предыдущем разделе , относится к вопросам мобильного программирования в с вязи с использованием функций операционной среды . Однако , если говорить о переносимо сти программ между компьютерами с разной архитектурой , имея в виду использование языка Си (не слишком высокого уровня ), то ну жно учитывать ряд требований , которым должна удовл е творять программа . Особенности мобил ьного программирования на языке Си Особая роль яз ыка программирования Си состоит в том , что он , с одной стороны , позволяет писать для UNIX-систем практически столь же эффективный код , что и языки ассемблера , а с д ругой, является основным средством переноса программ между UNIX-системами . Можно сказать , что Си является машинно-независимым языком ас семблера для UNIX-систем . Это делает его осно вным средством написания эффективных и перено симых программ для этого класса вычи с лительных систем . Стандартизация языка сн ачала Американским национальным институтом станд артов (ANSI), а затем и Международной организацией по стандартам (ISO) закрепила эту роль , распр остранив ее и на персональные компьютеры . Будем ссылаться на версию яз ы ка Си , определенную стандартом , как на язык ANSI C. Сказанное не означает , что любая прогр амма , написанная на ANSI C и отлаженная в одной вычислительной системе (ВС ), безусловно перено сима на любую другую вычислительную систему , также имеющую компилятор я зыка Си , отвечающий требованиям ANSI. Однако , язык ANSI C определ ен таким образом , чтобы можно было писать программы , подвергающиеся минимальным изменениям при их переносе на другие вычислительные системы . Программа на ANSI C переносима из исходной ВС в ц елевую , если она успешно компилируется в целевой ВС и ее работа функционально эквивалентна работе в исходной ВС . На переносимость программы влияют особенн ости как аппаратного , так и программного о кружения языка в исходной и в целевой ВС . Можно выделить че тыре фактора , в лияющих на переносимость программы : · архитектура вычислительных систем ; · метрические ограничения компиляторов ; · алгоритмы работы ком пиляторов ; · особенности операционных систем . Архитектура сущест венно влияет на семантику языка , а , с ледовательно , и на переносимость программ ных файлов . Во-первых , архитектура определяет м ножества значений арифметических типов , фиксируя тем самым семантику большинства операций языка . Во-вторых , от архитектуры , а именно , от системы команд , зависит интерп р етация операций языка , остающихся недоопр еделенными даже после фиксирования множеств з начений соответствующих типов . В-третьих , от ар хитектуры зависит схема размещения данных тех или иных типов в соответствующих элемент ах памяти . Даже если программа удовл етворяет всем ограничениям ANSI C и прошла стадию компил яции в исходной ВС , может случиться , что в целевой ВС она эту стадию не прой дет из-за того , что некоторые метрические характеристики программы не удовлетворяют ограни чениям , принятым в целевой ВС . Пр и мерами таких характеристик являются : числ о уровней вложенностей составных операторов , операторов цикла и операторов выбора варианта ; число описателей указателя , массива и фу нкции , модифицирующих базовый тип в описании объекта ; число выражений , вложенных д р уг в друга по круглым скобкам и т.п . От алгоритмов работы компилятора зависит , например , порядок вычисления выражений , что влияет как на значения выражений , так и на вырабатываемый ими побочный эффект . Наконец , семантика многих стандартных биб лиотечных ф ункций (например , функций ввода /вывода ) зависит от особенностей операционной системы . Все перечисленные факторы учтены в оп ределении ANSI C путем фиксирования неуточняемого (ста ндартом ) поведения программ , неопределенного повед ения программ и поведения пр ограмм , оп ределяемого реализацией . Неуточняемое поведение (unspecified behavior) - это поведение правильных программ с корректными данными в ситуациях , для которых стандарт не выдви гает никаких требований . Неопределенное поведение (undefined behavior) - поведение (динамически ) ошибочных программ с возможно некорректными данными или объектами с неопред еленными значениями , для которых стандарт не выдвигает никаких требований . Диапазон неопр еделенного поведения может быть очень разнооб разен : от полного игно р ирования си туации с непредсказуемыми результатами до пов едения (во время трансляции или выполнения ) в соответствии с документацией , описывающей характеристики среды (с выдачей диагностических сообщений или без таковой ); возможны случ аи преждевременного за в ершения трансл яции или вычислений (с обязательной выдачей диагностического сообщения ). Поведение , определяемое реализацией (implementation-defined behavior) - поведение правильно написанной программы с пр авильными данными , которое зависит от характе ристик реализации и которое должно быть документировано каждой реализацией . В качестве общей рекомендации по напи санию переносимых программ можно посоветовать , во-первых , безусловно избегать использования в программах языковых конструкций с неопределе нным повед ением , во-вторых , избегать констр укций с неуточняемым поведением в случаях , когда результат ее работы не является однозначным , и , наконец , минимизировать число к онструкций , чье поведение определяется реализацие й и существенно влияет на результат работ ы пр о граммы . Другая общая рекомендация заключается в использовании возможностей препроцессора Си для локализации непереносимых фрагментов програм мы . Это касается использования макроимен вмес то явных констант , зависящих от реализации ; использования условной тра нсляции для включения в окончательный текст программы тог о или иного фрагмента в зависимости от вычислительной системы (особенно это касается конструкций , чье поведение определяется реал изацией и существенно влияет на результат работы программы ) и т.д . Да лее мы перечисляем все случаи неуточняемого , неопределенного и зависящего от реализации поведения программ , а , кроме т ого , в наименее очевидных случаях объясняем их влияние на переносимость . После этого приводятся требования стандарта к метрическим ограни ч ениям компиляторов . Неуточняемое поведение Не уточняются следующие вопросы : · Метод и время инициации статич еских данных . В зависимости от того , вычисляются ли инициирующие констант ные выражения в окружении трансляции или в окружении выполнения програм мы , статиче ские данные могут получать различные начальны е значения . · Ситуация , когда выдается печатный символ , а активная позиция находится в конце строки . · Ситуация , когда выдае тся символ "шаг назад ", а активная позиция находится в начале строки . · С итуация , когда выдается символ "горизонтальная табуляция ", а активная позиция находится "на " или "за " последней определенной позицией горизонтальной табуляции . · Ситуация , когда выдае тся символ "вертикальная табуляция ", а активная позиция находится "на " и ли "за " пос ледней определенной позицией вертикальной табуля ции . Предыдущие четыре ситуации влияют на вывод текста на д исплей . · Представление плавающих типов . Переносимая програ мма не должна использовать информацию о п редставлении (т.е . о битовой структ уре ) плавающих типов , поскольку именно в реализаци и плавающей арифметики существенно различаются разные вычислительные системы . · Порядок вычисления выражений - в любом порядке , учитывающем только правила п редшествования операций и расстановку скобок . · Порядок , в котором возникают побочные эффекты . · Порядок , в котором вычисляются параметры вызова функции и сам о значение этой функции . За исключением тех случаев , когда порядок вычисления выраж ения зафиксирован синтаксическими правилами или указан в стан дарте каким-либо другим образом (для операции вызова функции (), опе раций логического умножения , логического сложения , условной операции и операции перечисления выражений ), порядок вычисления подвыражений и порядок возникновения побочных эффектов не уточн я ется . Выражение , содержащее бо лее , чем одно вхождение одной и той же коммутативной и ассоциативной бинарной опера ции (*, +, &, ^, |), может свободно перегруппировываться , неза висимо от наличия скобок , при условии , что типы операндов или результаты от тако й перегруппировки не изменятся . В переносимой программе следует избегать выражен ий , порядок вычисления которых существенно вл ияет на их значения или вырабатываемые по бочные эффекты . Если же такое выражение во зникает , то содержащий его оператор всегда можно разбить на эквивалентную посл едовательность из нескольких операторов , не с одержащих подобных выражений . Например , оператор x=f()+g(); можно заменить на последовательность опер аторов y=f(); x=y+g(); или y=g(); x=f()+y; в зависимости от нужного поряд ка вызова функций f() и g() . Чтобы зафиксировать некоторое конкретное группирование операций , нужно присвоить значение выражения , которое требуется явно выделить , некоторому объекту данных , либо поставить п еред группирующими скобками унарный оператор плюс . · Отведение памяти под формальные параметры . Переносимая програ мма не должна использовать информацию о р аспределении памяти под формальные параметры , поскольку не только разные компиляторы по-раз ному решают эту задачу , но даже один к омпилятор может раз личным образом отводит ь память под формальные параметры при раз личных режимах своей работы . · Значение индикатора позиции файла после успешного выполнения функции ungetc для текстового потока до тех пор , пока не будут введе ны или уничтожены все запомненны е сим волы . · Подробности о значен ии , запоминаемом в случае успешной работы функции fgetpos . · Подробности о значен ии , вырабатываемом для текстового потока в случае успешной работы функции ftell . · Порядок и взаимное расположение областей памяти , захваты ваемых функциями calloc , malloc и realloc . · Какой из двух эл ементов , оказавшихся равными при сравнении , во звращается функцией bsearch . · Порядок расстановки в отсортированном функцией qsort массиве двух элементов , оказа вшихся равными при сравнении . · С труктура календ арного времени , возвращаемого функцией time . Переносимая програ мма не использует перечисленную информацию , п оскольку она либо различается для разных реализаций языка , либо даже является случайно й в рамках одной реализации . Неопределенное п оведение Поведение не определяется для следующих ситуаций : · В исходной программе обнаружен символ , не входящий в требуемый набор . И сключение делается для препроцессорных лексем , символьных и строковых констант , а также примечаний . · Делается попытка мо дифицировать строковую константу . · Идентификаторы , которые должны обозначать одну и ту же сущно сть , различаются хотя бы одним символом . · В символьной или строковой константе обнаружена неизвестная упр авляющая последовательность . · Лексически первое оп исание функции или объекта данных с внешней связью не имеет файловой области видимости , а последующее описание лексически идентичного идентификатора имеет либо внутренн юю , либо внешнюю связь , что противоречит п ервому описанию . · Арифметическое преобразо ва ние дает результат , который не может быть представлен в отведенном пространстве . · Арифметическая операция неверна (например , деление на 0) или выдает результат , который нельзя представить в о тведенном пространстве (например , переполнение или потеря значи мости ). · Число фактических па раметров вызова не согласуется с числом ф ормальных параметров функции , которая не имее т действующего в данной области видимости прототипа . · Типы фактических пар аметров вызова после расширения не согласуютс я с расширенными т ипами формальных па раметров функции , которая не имеет действующе го в данной области видимости прототипа и не имеет прототипа , действующего в област и видимости , соответствующей области определения функции . · Прототип функции име ется в области видимости , со ответствующей области определения функции , формальный пара метр описан с типом , который изменяется в результате действия расширений типа , проводи мых по умолчанию , а функция вызывается , ко гда в области видимости нет семантически эквивалентного прототипа . · Вызывается функция , о брабатывающая переменное число параметров , но прототип с эллиптической нотацией отсутствует в данной области видимости . · Вызывается функция с прототипом , видимым в данной области , ее формальный параметр описан с типом , котор ый изменя ется в результате действия р асширений типа , проводимых по умолчанию , но в области определения функции не видно семантически эквивалентного прототипа функции . · Встретилась неверная ссылка на массив , ссылка на пустой указ атель или ссылка на объект , размеще нны й в области автоматически распределяемой памя ти завершившегося блока . · Указатель на функцию преобразуется в указатель на функцию дру гого типа и используется для вызова функц ии , тип которой отличается от первоначального . · Указатель на объект , не явля ющийся элементом массива , исп ользуется в операции прибавления или вычитани я константы . · Вычисляется разность указателей , относящихся к разным массивам . · Результат выражения сдвигается на отрицательную величину или на величину , большую или равную (в бит ах ) размеру сдвигаемого результата . · Сравниваются указатели , относящиеся к разным составным объектам . · Значение объекта при сваивается перекрывающемуся по памяти объекту . · Делается попытка изм енить объект , описанный как константа , с п омощью указателя на тип , в котором н ет атрибута const . · Объект , описанный с атрибутом volatile , указывается с помощью указателя на тип , не имеющего такого же атрибута . · Описания объекта , име ющего внешнюю связь , в двух разных файлах или в разных областях видимости одног о файла , дают этому объекту разные типы . · Значение автоматического неинициированного объекта используется до пе рвого присваивания . · Используется результат работы функции , которая , однако , не возвра щает никакого значения . · Функция , обрабатывающая пере менное число параметров , определяетс я без списка типов параметров в эллиптиче ской нотации . · Фактический параметр макровызова не имеет ни одной препроцессор ной лексемы . · Внутри списка параме тров макровызова имеются препроцессорные лексемы , которые могут быть проинтерпретированы как директивы препроцессора . · В результате выполне ния препроцессорной операции слияния лексем (##) получается неверная препроцессорная лексема . · Эффект , возникающий в программе при переопределении зарезервированног о внешнего и дентификатора . · Параметр identifier в макровызове offset соответствует битов ому полю записи . · Фактический параметр библиотечной функции имеет неверное значение , если только поведение этой функции в п одобном случае не описано явно . · Библиотечная функц ия , обрабатывающая переменное число парам етров , не описана . · Для доступа к на стоящей функции assert использована макродиректива # undef . · Фактический параметр функции , обрабатывающей символы , выходит за область определения . · Вызов функции setjmp произ водится в ином контексте , нежели при сравнении с целочисленным выражением из констант в переключателе или в условном операторе . · Значение автоматического объекта , не имеющего атрибута volatile , изменилось между вызо вами setjmp и longjmp . · Функция longj mp вызывается из динамически вложенной программы обработки сигнал а . · Сигнал возникает не в результате работы функций abort или raise , а при обработке сигнала вызывается библиотечная функция , не являющаяся самой функцией signal , или со статическим объекто м проделывается не присваивание ему значения статической переменной с атрибутом volatile типа sig_atomic_t . · Параметр parmN макроопределения va_start описывается в к лассе регистровой памяти . · При вызове макроимен и va_arg очередного фактического парамет ра не оказалось . · Тип фактического пар аметра из списка параметров не согласуется с типом , указанным в макровызове va_arg . · Функция va_end вызывается без предвар ительного обращения к макровызову va_start . · Из функции с пер еменным числом параметров , сп исок которых был проинициирован с помощью макровызова va_start , возврат пр оизводится до вызова va_end . · Формат в функциях fprintf и fscanf не соответствует списку фактических параметров . · В формате функций fprintf или fscanf обнаружена невер ная специфи кация преобразования . · Среди спецификаторов преобразования для спецификации , не входящей в список o, x, X, e, E, f, g и G встретился признак #. · Фактическим параметром функции fprintf , не соответствующим преобразованиям %s и %p, являетс я составной объе кт или указатель на составной объект . · Отдельное преобразование в функции fprintf породило более 509 выходных символов . · Фактическим параметром преобразования %p функции fscanf является значение указателя , выд анное при преобразовании %p функцией fprintf во время предыдущих запусков программы . · Результат преобразования , выполняемого функцией fscanf , не может быть представлен в объеме памяти , отведенной для него , или полученный объект имеет неподходящий тип . · Результат преобразования строки в чи сло с помощью функций atof , atoi или atol не может быть предс тавлен . · Фактический параметр функций free ил и realloc не сов падает с ранее полученными указателями , выраб отанными функциями calloc , malloc или realloс , или ука зывается объект , ранее уничтоженн ый вызов ом функций free или realloc . · Ссылка на память , освобожденную функциями free или realloc . · При вызове из фу нкции exit функция , зарегистрированная обращением к atexit , производит доступ к автоматическому объекту программы . · Результат целочисле нных арифметических функций ( abs , div , labs или ldiv ) не может быть представлен . · Массив , в который идет запись копированием или конкатенацией , слишком мал . · Функции memcpy , strcpy или strncpy копируют объект в перекрывающийся с ним по памяти другой об ъект . · В формате функции strftime обнаружена неверная спецификация преобразования . Все перечисленные ситуации являются ошибочными , однако разные реализации могут по-разному реагировать на них . Может даже случиться , что в некотор ых реализациях программы с неопределенным поведением работают и выдают нужные резуль таты . Однако такие программы , как правило , невозможно перенести на другую вычислительную систему . Например , используя в расчетной программе неверные арифметические операции (деление на ноль или оп ерации , приводящие к п ереполнению или потере значимости ), можно доби ться удовлетворительной , с точки зрения конеч ного результата , работы этой программы за счет использования нюансов обработки таких ис ключительных ситуаций в рамках конкретной выч ислительно й системы . На других же вычислительных системах эта программа либо вообще не будет работать , либо будет вы давать неудовлетворительные результаты . Больше то го , может потребоваться даже изменение алгори тма , реализуемого программой , из-за невозможности воспро и звести использованные нюансы исходной вычислительной системы хотя бы потому , что программист мог и не знать обо всех использованных тонкостях аппаратуры по принципу "есть результат и ладно " (кст ати , техническая документация может и не с одержать описания в с ех тонкостей ). Возникновения ситуаций с неопределенным п оведением можно , а при разработке переносимых программ , безусловно , нужно избегать . Поведение , зависящее от реализац ии Каждая реализация должна описать поведени е во всех ситуациях , перечисленных в этом разделе . Семантика фактических параметров функции main . Для облегчения переноса программы полезно локализовать обработку внешних аргументов . Число значащих начальных символов (сверх 31) в идентификаторе без внешней связи . В переносимой программе н е исполь зуется свыше 31 значащего символа в идентификат орах без внешней связи . Число значащих начальных символов (сверх 6) в идентификаторе с внешней связью . В переносимой программе не используется свыше 6 значащих символов в идентификаторах с внешней св язью . Имеет ли значение регистр символов , вх одящих в идентификаторы с внешней связью . При разработке переносимых программ лучше исходить из того , что регистр символов , входящих в идентификатор с внешней связью , не имеет значения (т.е . не различаются загл авные и прописные буквы ). Символы входного алфавита , кроме явно определенных в стандарте . Это касается , в основном , символов , исп ользуемых в символьных и строковых константах (например , русские буквы ). Символы из набора времени выполнения ( за исключение м пустого символа и (в окружении выполнения ) явно определенных символо в входного символьного набора ) и их коды . В переносимых программах нежелательно исп ользование информации о кодах символов , поско льку они могут различаться в разных реали зациях . Соответ ствие символов входного алфави та (в символьных и строковых константах ) с имволам алфавита времени выполнения . В основном это касается управляющих с имволов . Например , символ "конец строки " (\ n) в разных реализациях может быть представлен в потоках ввода-выв ода различными последов ательностями кодов . Надо стараться писать про грамму так , чтобы ее поведение не зависело от конкретного представления управляющих сим волов в окружении выполнения . Число и порядок символов в целом . Эти различия несущественны в самост оятельных программах , которые не позволяю т себе играть типами (например , преобразуя указатель на целое в указатель на символы и проверяя содержимое памяти по указател ю ), но могут проявиться при обработке данн ых , поступающих извне . Число и порядок следован ия разряд ов в символах из набора символов времени выполнения . Значение символьной константы , состоящей из символа или управляющей последовательности , не представимой в алфавите времени выполне ния . Переносимой программе не следует использо вать информацию этих двух пунктов . Значение символьной константы , состоящей более , чем из одного символа . В переносимой программе не следует ис пользовать символьные константы более , чем из одного символа . Следует ли трактовать "простые " символьные объекты как знаковые или беззнаковые . Переносимая программа не должна зависеть от того , является ли тип char знаковым ил и беззнаковым . Представление и наборы значений различных целочисленных типов . В переносимой программе лучше всего и сходить из минимальных наборов значений , зафиксированных стандартом , а также из той минимальной информации о представлении , кото рая в приводится в стандарте . Результат преобразования целого к более короткому знаковому целому или результат преобразования беззнакового целого к знаковому целому т ой же длины , если значени е не может быть представлено . Переносимая программа не использует эту информацию . Результаты поразрядных операций над знако выми целыми . В переносимой программе следует использов ать только такие поразрядные операции , резуль тат ко торых не зависит от реализации . Знак остатка целочисленного деления . Переносимая программа не использует эту информацию . Является ли сдвиг вправо значения зна кового целочисленного типа логическим или ари фметическим . Переносимая программа не должна зави сеть от вида сдвига вправо знаковых целых . Представление и наборы значений различных типов вещественных чисел . Переносимая программа не зависит от п редставления вещественных чисел . Наборы значений вещественных типов влияют на точность вы числений . Способ округления , когда вещественное число преобразуется к более узкому веществ енному числу . В переносимой программе лучше всего и сходить из того , что способ округления неи звестен . Тип целого , которое может вместить мак симальный размер массива , то есть тип si ze_t - тип результа та операции sizeof . Результат преобразования указателя в цело е и наоборот . Тип целого , которое может вместить раз ность между двумя указателями на один и тот же массив - ptrdiff_t . Переносимая программа не должна использов ать информаци ю предыдущих трех пунктов . Элемент смеси union используется как элемент другого типа . Переносимая программа не должна осуществл ять доступ к элементу смеси после того , как был изменен элемент смеси другого типа , поскольку в этом случае используется информ ация о битовой структуре предста вления значения соответствующего типа . Дополнение пустот и выравнивание элементо в записей . Это обычно не доставляет проблем , если только двоичные данные , записанные одной реализацией , не читаются другой . Конечно же , не сле дует использовать эту информацию в переносимой программе . Считается ли "простое " целое битовое п оле знаковым или беззнаковым . Переходит ли битовое поле , не умещающе еся в одном целом , в следующее . Порядок расположения битовых полей в целом . Может ли бит овое поле пересекать физические границы ячеек памяти . Переносимая программа не должна использов ать всю эту информацию . Максимальное число описателей , которые мо гут модифицировать базовый тип . Переносимой программе нужно исходить из того , что любая реали зация должна допускать использование в модификации базового типа , либо непосредственно , либо через эк вивалентность типов , по крайней мере 12 описател ей указателей , массивов и функций (в любых комбинациях ). Максимальное число вариантов в переключат еле . Пе реносимая программа должна исходить из того , что число вариантов в перекл ючателе не должно превышать 255. Будет ли значение односимвольной символьн ой константы в выражении , управляющем условны м включением фрагментов программ , совпадать с о значением такой же константы в на боре символов окружения выполнения . Может ли такая константа иметь отрицательное значение . Метод связи с входными файлами , подлеж ащими включению в программу . Обработка имен в кавычках , относящихся к включаемым файлам . Поведение каждой д ирективы #pragma . Определение имен __DATE__ и __TIME__, когда , соответстве нно дата и время трансляции не может быть доступно . Константа , получающаяся при подстановке м акроопределения NULL, обозначающая пустой указатель . Предыдущие 6 пунктов описывают за висящ ее от реализации поведение препроцессора . Ост альные пункты описывают определяемое реализацией поведение библиотечных программ . Диагностическое сообщение и способ заверш ения программы , применяемый в функции assert . Наборы символов , проверяемые в функ циях isalnum , isalpha , iscntrl , islower , isprint и isupper . Значения , выдаваемые математическими функциям и при возникновении ошибок области определени я . Устанавливают ли математические функции ц елое выражение errno в положение ERANGE при возникновении по тери значимости . Набор сигналов для функции signal. Семантика каждого сигнала , распознаваемого библиотечной функцией signal . Обработка умолчаний и входов в програ мму для каждого вида сигналов , распознаваемых функцией signal . Восстанавливается ли станда ртная обра ботка , если при обработке сигнала функцией , указанной при вызове функции signal , возникает сигнал SIGILL. Нужно ли заканчивать последнюю строку текстового потока символом "конец строки ". Появятся ли при вводе обычные пробелы , записанные в текст овый поток непосре дственно перед символом конца строки текста . Количество символов NULL, которые дописываются к двоичному потоку . Характеристики буферизации файлов . Существует ли файл нулевой длины . Правила образования правильных имен файло в . Может ли один файл открываться много раз . Результат выполнения функции remove над открытым файлом . Эффект работы функции rename , если файл с новым именем существовал ранее . Выходная строка , получающаяся при работе преобразования %p в функции fprintf . Входная с трока , поступающая для пр еобразования %p в функции fscanf . Интерпретация символа ^, который есть ни первый , ни последний символ в списке ск анирования в преобразовании %[ в функции fscanf . Значение , которое получает errno от функций fgetpos и ftell в случ ае неудачи . Сообщения , выдаваемые функцией perror . Поведение функций calloc , malloc и realloc в случае , если размер запрошенной памяти равен нулю . Поведение функции abort по отношению к открытым и врем енным файлам . Статус , возвращаемый функцией exit , е сли значение фак тического параметра не равно нулю , или зна чениям макроимен EXIT_SUCCESS и EXIT_FAILURE. Набор имен окружения и метод изменени я списка окружения , используемый функцией getenv . Содержание и режим выполнения командной строки функцией system . Знак значения , возвращаемого функцией сра внения ( memcmp , strcmp или strncmp ), если первая пара различающих ся символов разнится в старшем разряде . Содержание строк сообщений об ошибках , возвращаемых функцией strerror . Местный временной пояс и летнее вре мя . Точка отсчета для функции clock . Метрические ограничения переносимой программы Переносимая программа должна удовлетворять следующим метрическим ограничениям : · 15 уровней вложенности составных операторов , операторов цикла и операторов выб ора вариан та . · 6 уровней вложенности условной трансляции . · 12 описателей указателя , массива и функции , модифицирующих базовый тип в описании объекта . · 127 выражений , вложенных друг в друга по круглым скобкам . · 31 значащий символ в начале идентификатора с вну тренней с вязью или имени макроопределения . · 6 значащих символов в начале имен , имеющих внешнюю связь . · 511 внешних имен в одном исходном файле . · 127 имен в одном блоке . · 1024 имени макроопределен ий , одновременно действующих в одном исходном файле . · 31 параметр в вызове или определении функции . · 31 параметр в макров ызове или макроопределении с параметрами . · 509 символов в одной логической исходной строке . · 509 символов в строко вой константе (после конкатенации ). · 32767 байтов для разме щения объекта . · 8 уровней вложенности по включаемым файлам . · 255 меток выбора вари анта в переключателях . Обеспечение незав исимости от особенностей версии ОС UNIX Специфичным видом мобильности приложений на уровне исходных текстов является возможность их вы полн ения с несколькими версиями одного и того же варианта ОС UNIX, включая ранние версии , далекие от современных стандартов . Достаточно часто поздние версии не обеспечивают пол ной совместимости с более ранними версиями , поскольку такая совместимость не да л а бы возможности добиться в поздних версиях соответствия стандартам . По-видимому , единственным на текущий момен т практическим приемом для достижения такого рода мобильности приложений на уровне ис ходных текстов является развитое применение о ператоров усло вной компиляции в текстах программ (условной компиляции на уровне ф айлов включения часто оказывается недостаточно , поскольку в зависимости от версии системы в прикладной системе приходится использовать разные комбинации системных вызовов и др угих библиоте ч ных функций ). Обычно в основных файлах включения поддерживаются с имволические константы , значения которых позволяю т судить об особенностях используемой версии ОС . Опираясь на значения этих констант , можно добиться того , что правильно написанн ая прикладная программа будет правиль но компилироваться (и собираться ) в среде конкретной версии операционной системы . Наличие единого текста облегчает сопровождение приклад ной программы и облегчает достижение его одинаковой функциональности при работе с разн ыми версия м и системы (хотя такие тексты , переполненные операторами условной к омпиляции , обычно очень трудно читаются ; можно только рекомендовать по мере возможности локализовать куски программы , зависящие от версии ОС ). Бинарная совме стимость Если обычно до стижение мобильности прикладных программ яв ляется целью прикладных программистов , то ино гда достижение бинарной совместимости при вып олнении прикладных программ является задачей разработчиков операционных систем . Под бинарной совместимостью операционной системы О 2 с операционной системой О 1 понимается возможность выполнения в среде О 2 без пере компиляции (а , возможно , и без перекомпоновки ) приложений , написанных для выполнения в сре де О 1. Естественно , что бинарная совместимость двух операционных сред теоретически до с тижима только в том случае , к огда обе операционные системы О 1 и О 2 б азируются на некоторой общей аппаратной платф орме (реально , чаще всего приходится слышать о бинарной совместимости разных вариантов ОС UNIX, работающих на платформах Intel). Двоичная совм естимость новой операцио нной системы с некоторой существующей ОС требуется в том случае , когда , во-первых , не обходимо доказать пользователям , что новая си стема не только обладает новыми качествами , но и настолько технологична , что может выполнять существу ю щие приложения даж е без потребности их перекомпиляции . Во-вторых , двоичная совместимость позволяет немедленно сделать доступным в новой операционной среде весь накопленный в старой среде багаж приложений (исходные тексты которых будут , с корее всего , недос т упны ), что может оказаться очень существенным для потенциальн ых конечных пользователей (потребителей приложени й ) новой системы . Возможности дости жения бинарной совместимости Конечно , прежде всего требуется полная аппаратная совместимост ь используемых плат форм (по крайней ме ре , на уровне пользователя ). Далее возможны два варианта . В первом , более простом ва рианте обеспечивается двоичная совместимость в смысле использования в новой операционной среде объектных файлов , откомпилированных в р асчете на прежнюю о перационную сред у . Для получения выполняемой программы в н овой среде требуется перекомпоновка программы (конечно , для этого компоновщик выполняемых программ новой ОС должен понимать структуру объектных модулей старой системы ). Этот в ариант близок к подход у переносимос ти программ на уровне исходных текстов , по скольку старые объектные модули содержат толь ко пользовательский код и вызовы библиотечных функций и , очевидно , будут выполняться в новой среде без проблем . Все , что оста ется сделать (но это очень непр о стая задача ) - это добиться полной совм естимости со старой средой на уровне сист емных библиотек всех уровней . Нужно заметить , что этот вид бинарной совместимости не очень эффектен и не очень практичен , поскольку наборы объектных файлов приложений получить не намного проще , чем их исходные тексты . Обычно доступны выполняемые программы . Во втором варианте в новой операционн ой системе возможно выполнение построенных в старой операционной среде выполняемых файлов . Это уже полностью скомпонованные программы , со держащие , кроме обычных пользовательск их команд , только специальные команды вызова функций ядра операционной системы (обычно , разновидности команды trap ). С одной стороны , для обеспечения эт ого вида бинарной совместимости не требуется воспроизводить весь н абор библиотек старой операционной среды , но , с другой ст ороны , требуется полностью воспроизвести интерфей с с ядром старой операционной системы на самом низком уровне . Понятно , что это выполнимая , но трудная техническая задача (пос кольку детали этого инте р фейса об ычно публично недоступны ). Преимущества и ограничения О преимуществах подхода бинарной совместимости мы уже сказ али в начале этого раздела : привлечение пр икладных программистов возможностью использовать свои старые программы без каких-либо передел ок и привлечение конечных пользователей возможностью использовать все накопленные пр иложения . Ограничением систем , обеспечивающих бинарную совместимость является то , что позволяя и спользовать старые приложения , они тормозят и спользование новых качеств сис темы (а новые системы всегда обладают новыми качества ми , в противном случае их было бы бесс мысленно делать ). Кроме того , в наше время аппаратные архитектуры развиваются так быстр о , что их развитие тормозится требованиями аппаратной совместимости платформ о д ной линии даже на пользовательском уровне . Как кажется (это субъективное мнение автора ), в этих условиях достижение бинарной сов местимости операционных систем на одной аппар атной платформе становится слишком дорогостоящей и неблагодарной задачей.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
На заметку хозяйкам: электрические лампочки малой мощности в квартире не только экономны, но и делают её чистой и уютной, а хозяйку красивой и нарядной.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Мобильное программирование в среде ОС UNIX", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru