Глава 2 введение в "программную среду пакета quick c"


Содержание

Введение в программную среду разработки и отладки CodeComposerStudio. Линкирование. Добавление файлов в проект

Страницы работы

Содержание работы

Лабораторная работа № 1

Введение в программную среду разработки и отладки CodeComposerStudio

Цель работы: изучить программную среду разработки и отладки программ Code Composer Studio для цифрового сигнального процессора TMS320F2812.

Code Composer Studio (CCS) – интегрированная среда цифровых сигнальных процессоров фирмы Texas Instruments семейства С2000. Выполняя редактирование, компиляцию и линкирование CCS комбинирует все составляющие в единый проект, который можно отлаживать. Мы можем использовать CCS, работая на симуляторе или подключив реальный цифровой сигнальный процессор и тестировать проект программно.

Файл управления линкером для создания программы соединяет физическую память сигнального процессора с логическими секторами. Процедура линкирования объединяет один и более объектные файлы (*.obj) в выходной файл (*.out), который состоит не только из машинного кода, но и содержит информацию, используемую при отладке.

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

Порядок выполнения лабораторной работы № 1

1. Создание нового проекта.

Выбираем из главного меню Project → New. В поле Project Name записываем название проекта “Lab1”. В поле Location указываем путь, по которому будет находиться ваш проект. В поле Project Type выбираем Executable (.out), а в поле Target — TMS320C28XX.

2. Написание программ на языке С или Ассемблере.

Напишем простейшую программу обращения к процессору в специальной рабочей области (File → New → Sourse File) и сохраним её в созданной ранее папке (File → Save as: “lab1.c”).

зМБЧБ 2: уТЕДБ VisualWorks

ъБРХУЛ УЙУФЕНЩ VisualWorks

ЗДЕ visual_path — ЬФП ПВЩЮОП ЛБФБМПЗ /opt/visual (/opt/local/visual Ч пФДЕМЕ йОЖПТНБФЙЛЙ Ч ХОЙЧЕТУЙФЕФЕ Clemson). жБКМ image.im ОБЪЩЧБЕФУС ЖБКМПН ПВТБЪБ. пО УПДЕТЦЙФ ОБЮБМШОХА УТЕДХ УЙУФЕНЩ VisualWorks. жБКМ ПВТБЪБ УЙУФЕНЩ РП ХНПМЮБОЙС — ЬФП ПВЩЮОП visual_path /image/visual.im. оБ РМБФЖПТНЕ Sun Solaris Ч Clemson, УТЕДХ VisualWorks У ПВТБЪПН УЙУФЕНЩ РП ХНПМЮБОЙА ЪБРХУЛБЕФ ЛПНБОДБ

юФПВЩ ЪБРХУФЙФШ VisualWorks У ДТХЗЙН ПВТБЪПН, ЙУРПМШЪХЕФУС ЛПНБОДБ

чЧЕДЙФЕ УППФЧЕФУФЧХАЭХА ЛПНБОДХ ДМС ЪБРХУЛБ VisualWorks ОБ ЧБЫЕК УЙУФЕНЕ. чЩ ДПМЦОЩ ХЧЙДЕФШ ДЧБ ПЛОБ, VisualWorks Launcher Й Workspace.

йОУФТХНЕОФ VisualWorks Launcher


Workspace


йУРПМШЪПЧБОЙЕ НЩЫЙ Й ЧУРМЩЧБАЭЙИ НЕОА

еУФШ ДЧБ ФЙРБ ЧУРМЩЧБАЭЙИ НЕОА, УЧСЪБООЩИ У ЛБЦДЩН ПЛОПН Ч VisualWorks. еУФШ НЕОА ПЛОБ (Window-НЕОА), Л ЛПФПТПНХ ПВТБЭБАФУС, ОБЦЙНБС Ч ПЛОЕ ОБ РТБЧХА ЛОПРЛХ НЩЫЙ. Window-НЕОА ЙУРПМШЪХЕФУС ДМС ЪБЛТЩФЙС, РЕТЕНЕЭЕОЙС, Й ЙЪНЕОЕОЙС ТБЪНЕТПЧ ФЕЛХЭЕЗП ПЛОБ. чФПТПК ФЙР ЧУРМЩЧБАЭЕЗП НЕОА — НЕОА ПРЕТБГЙК (Operate-НЕОА), Л ЛПФПТПНХ ПВТБЭБАФУС, ОБЦЙНБС Ч ПЛОЕ УТЕДОАА ЛОПРЛХ НЩЫЙ. ч ПЛОЕ НПЦЕФ ВЩФШ ВПМШЫЕ ПДОПЗП НЕОА ПРЕТБГЙК, ДМС ЧЩЪПЧБ ЛБЦДПЗП ФБЛПЗП НЕОА ВХДЕФ ЪБТБОЕЕ ПРТЕДЕМЕОБ ПВМБУФШ ПЛОБ (РБОЕМШ), Ч ЛПФПТПК ОБДП ОБЦЙНБФШ УТЕДОАА ЛОПРЛХ НЩЫЙ. юФПВЩ ЧЩВТБФШ ЬМЕНЕОФ (ЪБРЙУШ, ПРГЙА) ЙЪ МАВПЗП НЕОА (ПЛОБ ЙМЙ ПРЕТБГЙК) ЛОПРЛБ НЩЫЙ, ДПМЦОБ ЙУРПМШЪПЧБФШУС ФБ ЦЕ ЛОПРЛБ НЩЫЙ, ЛПФПТБС ЙУРПМШЪХЕФУС ДМС ФПЗП, ЮФПВЩ РПМХЮЙФШ ДПУФХР Л УБНПНХ НЕОА.

пВТБФЙФЕ ЧОЙНБОЙЕ: Ч УЙУФЕНЕ ЕУФШ ЧПЪНПЦОПУФЙ ДМС ТБВПФЩ У ПДОП- ЙМЙ ДЧХИ ЛОПРПЮОПК НЩЫША. оБРТЙНЕТ, ДМС ТБВПФЩ У НЩЫША У ДЧХНС ЛОПРЛБНЙ ЙУРПМШЪХАФУС УМЕДХАЭЙЕ УПЗМБЫЕОЙС:

  • МЕЧБС ЛОПРЛБ — Select-ЛОПРЛБ.
  • РТБЧБС ЛОПРЛБ — Operate-ЛОПРЛБ.
  • ДПУФХР Л НЕОА ПЛОБ РТПЙУИПДЙФ РТЙ УПЧНЕУФОПН ОБЦБФЙЙ ЛМБЧЙЫЙ CTRL Й РТБЧПК ЛОПРЛЙ НЩЫЙ (Operate-ЛОПРЛЙ).

ч ПЛОБИ, ЛПФПТЩЕ ЙНЕАФ УФТПЛХ НЕОА, ДПУФХР Л УППФЧЕФУФЧХАЭЕНХ ЧЩРБДБАЭЕНХ НЕОА РТПЙУИПДЙФ РТЙ ОБЦБФЙЙ ОБ ЙНЕОЙ, УЧСЪБООПН У НЕОА. оБРТЙНЕТ, ЮФПВЩ РПМХЮЙФШ ДПУФХР Л ПРХУЛБАЭЕНХУС НЕОА File, ОБДП ОБЦБФШ ОБ ЙНЕОЙ File, ТБЪНЕЭЕООПН Ч УФТПЛЕ НЕОА ПЛОБ Launcher. чЩВПТ ЙЪ ПРХУЛБАЭЕЗПУС НЕОА ВХДЕН ПВПЪОБЮБФШ ЙНЕОЕН НЕОА, УПРТПЧПЦДБЕНЩН УФТЕМЛПК () Й ЧЩВЙТБЕНЩН РХОЛФПН НЕОА. оБРТЙНЕТ, ЪБРЙУШ File->Settings ПЪОБЮБЕФ, ЮФП ЙЪ ПРХУЛБАЭЕЗПУС НЕОА File ПЛОБ VisualWorks Launcher ЧЩВЙТБЕФУС ПРГЙЙ Settings. нОПЗЙЕ ЙЪ ПРГЙК ПРХУЛБАЭЙИУС НЕОА ЙНЕАФ ЛОПРЛЙ ВЩУФТПЗП ДПУФХРБ, ТБУРПМПЦЕООЩЕ Ч УФТПЛЕ ЙОУФТХНЕОФПЧ, УЧСЪБООЩЕ У УППФЧЕФУФЧХАЭЙНЙ ЙЛПОЛБНЙ. оБРТЙНЕТ, ДПУФХР Л Canvas Tool НПЦОП РПМХЮЙФШ, ЙМЙ ЙУРПМШЪХС ПРГЙЙ НЕОА Tools->New Canvas ЙМЙ РПМШЪХСУШ ЛОПРЛПК .

хУФБОПЧЛБ УЙУФЕНЩ VisualWorks

юФПВЩ ТБВПФБМБ ЙОФЕТБЛФЙЧОБС УРТБЧПЮОБС УЙУФЕНБ, ОБЦНЙФЕ ОБ НЕФЛХ Help (рПНПЭШ) УФТБОЙГЩ ЪБРЙУОПК ЛОЙЦЛЙ ПЛОБ ХУФБОПЧПЛ (ОП ОБ ЛОПРЛЕ Help ПЛОБ ХУФБОПЧПЛ). чЩ ДПМЦОЩ ХЧЙДЕФШ УМЕДХАЭЕЕ ПЛОП. хДПУФПЧЕТЙФЕУШ, ЮФП РХФШ Л ЙОФЕТБЛФЙЧОПК ДПЛХНЕОФБГЙЙ ХЛБЪБО РТБЧЙМШОП. оБЦНЙФЕ ЛОПРЛХ Accept, ЕУМЙ УДЕМБМЙ ОЕПВИПДЙНЩЕ ЙЪНЕОЕОЙС.

фЕРЕТШ ЪБЛТПКФЕ ПЛОП ХУФБОПЧПЛ, ЧЩВЙТБС ПРГЙА close ЙЪ НЕОА ПРЕТБГЙК ПЛОБ Settings.

чЙДЦЕФЩ

Action Button
Check Box
Radio Button
Label
Input Field
Text Editor
Menu Button
List
Combo Box
Divider
Group Box
Region
Slider
Table
Data Set
NoteBook
View Holder
Subcanvas
Linked Data
Embedded Data

рПДТПВОБС ЙОЖПТНБГЙС П ЛБЦДПН ЙЪ ЬФЙИ ЧЙДЦЕФПЧ УПДЕТЦЙФУС Ч ЙОФЕТБЛФЙЧОПК ДПЛХНЕОФБГЙЙ , ЛПФПТБС ПРЙУБОБ ОЙЦЕ.

йОУФТХНЕОФЩ Canvas, CanvasTool Й Palette

чЩЧПД ОБ ЬЛТБО ИПМУФБ ДПМЦЕО РТПЙЪЧЕУФЙ Л РПСЧМЕОЙА ОБ ЬЛТБОЕ ФТЕИ ОПЧЩИ ПЛПО, РПДПВОЩИ УМЕДХАЭЙН:

  • The иПМУФ Unlabeled Canvas — ЙУРПМШЪХЕФУС ДМС РПУФТПЕОЙС GUI-ПЛОБ.
  • The Palette — ЙУРПМШЪХЕФУС ДМС ЧЩВПТБ ФЕИ ЧЙДЦЕФПЧ, ЛПФПТЩЕ ВХДХФ ТБЪНЕЭБФШУС ОБ ИПМУФЕ.
  • йОУФТХНЕОФЩ ИПМУФБ (CanvasTool) ЙУРПМШЪХАФУС ДМС ПРТЕДЕМЕОЙС УЧПКУФЧ ЧЙДЦЕФПЧ Й ЙОФЕТЖЕКУБ.

юФПВЩ РПЛБЪЩЧБФШ ЛБЛ ТБВПФБАФ ЬФЙ ЙОУФТХНЕОФЩ, ОБЦНЙФЕ ОБ РБМЙФТЕ ОБ ЧЙДЦЕФЕ БЛФЙЧОПК ЛОПРЛЙ (Action Button) . ч УБНПН ОЙЪХ РБМЙФТЩ ПФПВТБЪЙФШУС ФЕЛУФ «Action Button». рПНЕУФЙФЕ ЛОПРЛХ ОБ ИПМУФЕ, ОБЦЙНБС ОБ ЛОПРЛХ НЩЫЙ Ч ФПН НЕУФЕ ИПМУФБ, ЗДЕ ДПМЦОБ ТБЪНЕЭБФШУС ЛОПРЛБ. лБЛ чЩ НПЦЕФЕ ЧЙДЕФШ, УХЭЕУФЧХАЭЙК Ч УЙУФЕНЕ ОБВПТ ЧЙДЦЕФПЧ ДБЕФ чБН ЧПЪНПЦОПУФШ УПЪДБЧБФШ GUI-ПЛОБ, РПДПВОЩЕ ПЛОХ РБМЙФТЩ. еУМЙ ЕУФШ ЦЕМБОЙЕ, РТПВХКФЕ ТБЪНЕУФЙФШ ОБ ИПМУФЕ ВПМШЫПЕ ЮЙУМП ЧЙДЦЕФПЧ. фЕРЕТШ ЪБЛТПКФЕ ЧУЕ ЬФЙ ПЛОБ, ЧЩВЙТБС ПРГЙА close ЙЪ НЕОА ПРЕТБГЙК ПЛОБ Canvas.

йОФЕТБЛФЙЧОБС ДПЛХНЕОФБГЙС

оБРТЙНЕТ, РТЕДРПМПЦЙН, ЮФП чЩ ОХЦДБМЙУШ Ч ЙОЖПТНБГЙЙ ПФОПУЙФЕМШОП ФПЗП, ЛБЛ УЛПОУФТХЙТПЧБФШ УППВЭЕОЙЕ ОБ СЪЩЛЕ Smalltalk. чЩВЕТЙФЕ ПРГЙА VisualWorks Cookbook, ОБЦЙНБС ОБ ЪБЗПМПЧПЛ ЬФПК ЛОЙЗЙ ЛОПРЛПК НЩЫЙ. фЕРЕТШ, ЧЩВЕТЙФЕ ТБЪДЕМ зМБЧБ 1: пУОПЧЩ СЪЩЛБ Smalltalk Chapter 1: Smalltalk Basics, Б ЪБФЕН ТБЪДЕМ уПЪДБОЙЕ УППВЭЕОЙС (Constructing a Message). уППФЧЕФУФЧХАЭБС ЙОЖПТНБГЙС ВХДЕФ ПФПВТБЦЕОБ Ч ПЛОЕ йОФЕТБЛФЙЧОПК дПЛХНЕОФБГЙЙ. фЕРЕТШ ЪБЛТПКФЕ ЬФП ПЛОП.

пЛОП РТПУНПФТБ уЙУФЕНЩ(System Browser)

юФПВЩ ПФЛТЩЧБФШ пЛОП РТПУНПФТБ уЙУФЕНЩ, ЧЩВЕТЙФЕ ЙЪ ПЛОБ VisualWorks Launcher ПРГЙЙ Browse->All >. пВТБФЙФЕ ЧОЙНБОЙЕ, ЮФП ЧЕТИОСС РПМПЧЙОБ ПЛОБ РТПУНПФТБ уЙУФЕНЩ ТБЪДЕМЕОП ОБ ЮЕФЩТЕ РБОЕМЙ, Б ОЙЦОСС РПМПЧЙОБ ПЛОП УПДЕТЦЙФ ФЕЛУФПЧХА РБОЕМШ. ьФП ПЮЕОШ ЧБЦОЩЕ ПВМБУФЙ, ЙИ РТЕДОБЪОБЮЕОЙЕ УФПЙФ ЪБРПНОЙФШ. рБОЕМЙ ЧЧЕТИХ (УМЕЧБ ОБРТБЧП)- РБОЕМШ лБФЕЗПТЙК, РБОЕМШ лМБУУПЧ, РБОЕМШ рТПФПЛПМПЧ Й РБОЕМШ нЕФПДПЧ. фЕЛУФПЧБС РБОЕМШ, ЪБОЙНБАЭБС ОЙЦОАА РПМПЧЙОХ ПЛОБ РТЕДОБЪОБЮЕОБ ДМС ТБВПФЩ УП Smalltalk-ЛПДПН. ьФЙ РСФШ ТБЪОЩИ РБОЕМЕК ВХДХФ ЮБУФП ХРПНЙОБФШУС Ч ЬФПК ПВХЮБАЭЕК РТПЗТБННЕ РТЙ ПРЙУБОЙЙ ТБЪТБВПФЛЙ РТЙМПЦЕОЙК.

оБРТЙНЕТ, ЧЩВЕТЙФЕ ЛБФЕЗПТЙА «Magnitude-General» («чЕМЙЮЙОБ-ПВЭБС»), Й Ч РБОЕМЙ лМБУУПЧ РПСЧСФУС ЧУЕ ЛМБУУЩ, УЧСЪБООЩЕ У ЬФПК ЛБФЕЗПТЙЕК. чЩВЕТЙФЕ ЛМБУУ Date, Й РТПФПЛПМЩ, УЧСЪБООЩЕ У ЬФЙН ЛМБУУПН, ПФПВТБЪСФУС Ч РБОЕМЙ рТПФПЛПМПЧ. оБЛПОЕГ, ЧЩВЕТЙФЕ РТПФПЛПМ ДПУФХРБ, Й ЧУЕ НЕФПДЩ, УЧСЪБООЩЕ У ЬФЙН РТПФПЛПМПН ПФПВТБЪСФУС Ч РБОЕМЙ нЕФПДПЧ. пЛОП РТПУНПФТБ уЙУФЕНЩ ДПМЦОП ФЕРЕТШ РПИПДЙФШ ОБ ПЛОП, РПЛБЪБООПЕ ОЙЦЕ.

пВТБФЙФЕ ЧОЙНБОЙЕ, ЮФП ФЕЛУФПЧБС РБОЕМШ Ч ОБУФПСЭЕЕ ЧТЕНС УПДЕТЦЙФ ФПМШЛП ЫБВМПО ДМС ЛПДБ НЕФПДБ. чЩВЕТЙФЕ МАВПК НЕФПД, Й чЩ ХЧЙДЙФЕ ЕЗП ЛПД. ъБЛТПКФЕ пЛОП РТПУНПФТБ уЙУФЕНЩ, ЧЩВЙТБС ПРГЙА ЙЪ ПЛПООПЗП НЕОА.

чПЪНПЦОПУФЙ ЪБРЙУЙ Ч ЖБКМ Й ЙЪ ЖБКМБ


ъБРЙУШ ЙЪ ЖБКМБ

чЩВЕТЙФЕ ПРГЙА file in ЙЪ НЕОА ПРЕТБГЙК РБОЕМЙ ЙНЕО (Names View). йУРПМШЪХС ПЛОП РТПУНПФТБ уЙУФЕНЩ, РТПЧЕТШФЕ, ЮФП ЛБФЕЗПТЙС UIExamples-ПВЭЙК ФЕРЕТШ ЕУФШ Ч ПВТБЪЕ. ъБЛТПКФЕ ПЛОП УРЙУЛБ жБКМПЧ.

ъБРЙУШ Ч ЖБКМ


уФБТФ РТЙМПЦЕОЙС

лМБУУ НПЦЕФ ЙНЕФШ ВПМЕЕ ПДОПЗП «ТЕУХТУБ», ЛПФПТЩЕ СЧМСАФУС ЙОФЕТЖЕКУБНЙ РПМШЪПЧБФЕМС. юФПВЩ ЪБРХУФЙФШ РТЙМПЦЕОЙЕ, НЩ ЧЩВЙТБЕН ЛМБУУ Й УППФЧЕФУФЧХАЭЙК ТЕУХТУ ДМС РЕТЧПОБЮБМШОПЗП ПЛОБ РТЙМПЦЕОЙС.

уПИТБОЕОЙЕ cДЕМБООПК ТБВПФЩ

VisualWorks БЧФПНБФЙЮЕУЛЙ УПЪДБЕФ *.cha ЖБКМ Ч ЛБФБМПЗЕ, ЙЪ ЛПФПТПЗП ПО УФБТФПЧБМ, Й РЕТЙПДЙЮЕУЛЙ ВХДЕФ ЪБРЙУЩЧБФШ Ч ОЕЗП ЙЪНЕОЕОЙС, РТПЙУИПДСЭЙЕ Ч ОБЮБМШОПН ПВТБЪЕ. Cha-ЖБКМЩ НПЗХФ ПЛБЪБФШУС РПМЕЪОЩНЙ ДМС ХРТБЧМЕОЙС ЙЪНЕОЕОЙСНЙ, ПОЙ НПЗХФ ЙОПЗДБ ЙУРПМШЪПЧБФШУС ДМС ЧПУУФБОПЧМЕОЙС УЙУФЕНЩ РТЙ ПЫЙВЛБИ (ОБРТЙНЕТ, ЕУМЙ чЩ УМХЮБКОП ХДБМСЕФЕ ОХЦОХА УДЕМБООХА ТБОЕЕ ТБВПФХ, ЙМЙ ОЕ УНПЗМЙ РП ЛБЛЙН-ФП РТЙЮЙОБН УПИТБОЙФШ ЕЕ Ч ЖБКМЕ, ЛПФПТХА УФТЕНЙМЙУШ УПИТБОЙФШ). оП РТЙ ЦЕМБОЙЙ, РПЛБ чЩ ОЕ ЙУРПМШЪХЕФЕ VisualWorks ДМС ТБЪТБВПФЛЙ ВПМШЫПЗП РТПЕЛФБ, чЩ НПЦЕФЕ ХДБМСФШ *.cha ЖБКМЩ.

пвтAфйфе чойнAойе: мАВБС ТБВПФБ, ЧЩРПМОЕООБС ОБ ИПМУФЕ ОЕ ВХДЕФ УПИТБОСФШУС, ЛПЗДБ УПИТБОСЕФУС ПВТБЪ, ЕУМЙ ФПМШЛП ДБООЩК ИПМУФ ОЕ ВЩМ ХУФБОПЧМЕО Ч ЛМБУУЕ.

Глава 2 введение в "программную среду пакета quick c"

Архитектура операционной системы UNIX


Впервые система UNIX была описана в 1974 году в статье Кена Томпсона и Дэнниса Ричи в журнале «Communications of the ACM» [Thompson 74]. С этого времени она получила широкое распространение и завоевала широкую популярность среди производителей ЭВМ, которые все чаще стали оснащать ею свои машины. Особой популярностью она пользуется в университетах, где довольно часто участвует в исследовательском и учебном процессе.

Множество книг и статей посвящено описанию отдельных частей системы; среди них два специальных выпуска «Bell System Technical Journal» за 1978 год [BSTJ 78] и за 1984 год [BSTJ 84]. Во многих книгах описывается пользовательский интерфейс, в частности использование электронной почты, подготовка документации, работа с командным процессором Shell; в некоторых книгах, таких как «The UNIX Programming Environment» [Kernighan 84] и «Advanced UNIX Programming» [Rochkind 85], описывается программный интерфейс. Настоящая книга посвящена описанию внутренних алгоритмов и структур, составляющих основу операционной системы (т. н. «ядро»), и объяснению их взаимосвязи с программным интерфейсом. Таким образом, она будет полезна для работающих в различных операционных средах. Во-первых, она может использоваться в качестве учебного пособия по курсу «Операционные системы» как для студентов последнего курса, так и для аспирантов первого года обучения. При работе с книгой было бы гораздо полезнее обращаться непосредственно к исходному тексту системных программ, но книгу можно читать и независимо от него. Во-вторых, эта книга может служить в качестве справочного руководства для системных программистов, из которого последние могли бы лучше уяснить себе механизм работы ядра операционной системы и сравнить между собой алгоритмы, используемые в UNIX, и алгоритмы, используемые в других операционных системах. Наконец, программисты, работающие в среде UNIX, могут углубить свое понимание механизма взаимодействия программ с операционной системой и посредством этого прийти к написанию более эффективных и совершенных программ.

Содержание и порядок построения материала в книге соответствуют курсу лекций, подготовленному и прочитанному мной для сотрудников фирмы Bell Laboratories, входящей в состав корпорации AT&T, между 1983 и 1984 гг. Несмотря на то, что главное внимание в курсе лекций обращалось на исходный текст системных программ, я обнаружил, что понимание исходного текста облегчается, если пользователь имеет представление о системных алгоритмах. В книге я пытался изложить описание алгоритмов как можно проще, чтобы и в малом отразить простоту и изящество рассматриваемой операционной системы. Таким образом, книга представляет собой не только подробное истолкование особенностей системы на английском языке; это изображение общего механизма работы различных алгоритмов, и что гораздо важнее, это отражение процесса их взаимодействия между собой. Алгоритмы представлены на псевдокоде, похожем на язык Си, поскольку читателю легче воспринимать описание на естественном языке; наименования алгоритмов соответствуют именам процедур, составляющих ядро операционной системы. Рисунки описывают взаимодействие различных информационных структур под управлением операционной системы. В последних главах многие системные понятия иллюстрируются с помощью небольших программ на языке Си. В целях экономии места и обеспечения ясности изложения из этих примеров исключен контроль возникновения ошибок, который обычно предусматривается при написании программ. Эти примеры прогонялись мною под управлением версии V; за исключением программ, иллюстрирующих особенности, присущие версии V, их можно выполнять под управлением других версий операционной системы.

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

Системное описание базируется на особенностях операционной системы UNIX версия V редакция 2, распространением которой занимается корпорация AT&T, с учетом отдельных особенностей редакции 3. Это та система, с которой я наиболее знаком, однако я постарался отразить и интересные детали других разновидностей операционных систем, в частности систем, распространяемых через «Berkeley Software Distribution» (BSD). Я не касался вопросов, связанных с характеристиками отдельных аппаратных средств, стараясь только в общих чертах охватить процесс взаимодействия ядра операционной системы с аппаратными средствами и игнорируя характерные особенности физической конфигурации. Тем не менее, там, где вопросы, связанные с машинными особенностями, представились мне важными с точки зрения понимания механизма функционирования ядра, оказалось уместным и углубление в детали. По крайней мере, беглый просмотр затронутых в книге вопросов ясно указывает те составные части операционной системы, которые являются наиболее машинно-зависимыми.

Общение с книгой предполагает наличие у читателя опыта программирования на одном из языков высокого уровня и желательно на языке ассемблера. Читателю рекомендуется приобрести опыт работы с операционной системой UNIX и познакомиться с языком программирования Си [Kernighan 78]. Тем не менее, я старался изложить материал в книге таким образом, чтобы читатель смог овладеть им даже при отсутствии требуемых навыков. В приложении к книге приведено краткое описание обращений к операционной системе, которого будет достаточно для того, чтобы получить представление о содержании книги, но которое не может служить в качестве полного справочного руководства.

Материал в книге построен следующим образом. Глава 1 служит введением, содержащим краткое, общее описание системных особенностей с точки зрения пользователя и объясняющим структуру системы. В главе 2 дается общее представление об архитектуре ядра и поясняются некоторые основные понятия. В остальной части книги освещаются вопросы, связанные с общей архитектурой системы и описанием ее различных компонент как блоков единой конструкции. В ней можно выделить три раздела: файловая система, управление процессами и вопросы, связанные с развитием. Файловая система представлена первой, поскольку ее понимание легче по сравнению с управлением процессами. Так, глава 3 посвящена описанию механизма функционирования системного буфера сверхоперативной памяти (кеша), составляющего основу файловой системы. Глава 4 описывает информационные структуры и алгоритмы, используемые файловой системой. В этих алгоритмах используются методы, объясняемые в главе 3, для ведения внутренней «бухгалтерии», необходимой для управления пользовательскими файлами. Глава 5 посвящена описанию обращений к операционной системе, обслуживающих интерфейс пользователя с файловой системой; для обеспечения доступа к пользовательским файлам используются алгоритмы главы 4.

Основное внимание в главе 6 уделяется управлению процессами. В ней определяется понятие контекста процесса и исследуются внутренние составляющие ядра операционной системы, управляющие контекстом процесса. В частности, рассматривается обращение к операционной системе, обработка прерываний и переключение контекста. В главе 7 анализируются те системные операции, которые управляют контекстом процесса. Глава 8 касается планирования процессов, глава 9 — распределения памяти, включая системы подкачки и замещения страниц.

В главе 10 дается обзор общих особенностей взаимодействия, которое обеспечивают драйверы устройств, особое внимание уделяется дисковым и терминальным драйверам. Несмотря на то, что устройства логически входят в состав файловой системы, их рассмотрение до этого момента откладывалось в связи с возникновением вопросов, связанных с управлением процессами, при обсуждении терминальных драйверов. Эта глава также служит мостиком к вопросам, связанным с развитием системы, которые рассматриваются в конце книги. Глава 11 касается взаимодействия процессов и организации сетей, в том числе сообщений, используемых в версии V, разделения памяти, семафоров и пакетов BSD. Глава 12 содержит компактное изложение особенностей двухпроцессорной системы UNIX, в главе 13 исследуются двухмашинные распределенные вычислительные системы.

Интегрированные среды программирования

Интегрированная среда разработки (ИСР) – это система программных средств, используемая программистам для разработки программного обеспечения. В английском языке такая среда называется Integrated development environment или сокращённо IDE.

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

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

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

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

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

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

Наиболее распространёнными отладчиками являются:

— GNU Debugger – отладчик программ от проекта GNU;

— IDA – дизассемблер и низкоуровневый отладчик для операционных систем семейства Windows и GNU/Linux;

— Microsoft Visual Studio – среда разработки программного обеспечения, включающая средства отладки от корпорации Microsoft;

— OllyDbg – бесплатный низкоуровневый отладчик для операционных систем семейства Windows;

— SoftICE – низкоуровневый отладчик для операционных систем семейства Windows;

— Dr. Watson – стандартный отладчик Windows, позволяет создавать дампы памяти;

— WinDbg – бесплатный отладчик от корпорации Microsoft.

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

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

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

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

Большинство систем управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, так называемая «рабочая копия». Может быть получена последняя версия или любая из предыдущих, выбранная по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть получена оттуда в любое время. Сервер может использовать дельта-компрессию – способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.

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

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

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

Другие возможности системы управления версиями состоят:

— в создании разных вариантов одного документа-ветки, с общей историей изменений до точки ветвления и с разными – после неё.

— возможности узнать, кто и когда добавил или изменил конкретный набор строк в файле;

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

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

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

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

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

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

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

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

check-in, commit, submit – создание новой версии, публикация изменений. Распространение изменений, сделанных в рабочей копии, на хранилище документов. При этом в хранилище создаётся новая версия изменённых документов.

Check-out, clone – извлечение документа из хранилища и создание рабочей копии.

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

Merge, integration (слияние) — объединение независимых изменений в единую версию документа. Осуществляется, когда два человека изменили один и тот же файл или при переносе изменений из одной ветки в другую.

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

Revision (версия документа). Системы управления версиями различают версии по номерам, которые назначаются автоматически.

Tag, label (метка) – которую можно присвоить определённой версии документа. Метка представляет собой символическое имя для группы документов, причём описывает она не только набор имён файлов, но и ревизию каждого файла. Ревизии включённых в метку документов могут принадлежать разным моментам времени.

Trunk, mainline (ствол) – основная ветвь разработки проекта. Политика работы со стволом может отличаться от проекта к проекту, но в целом она такова: большинство изменений вносится в ствол; если требуется серьёзное изменение, способное привести к нестабильности, создаётся ветвь, которая сливается со стволом, когда нововведение будет в достаточной мере испытано; перед выпуском очередной версии создаётся «релизная» ветвь, в которую вносятся только исправления.

Update, sync (обновление, синхронизация) – синхронизация рабочей копии до некоторого заданного состояния хранилища. Чаще всего это действие означает обновление рабочей копии до самого свежего состояния хранилища. Однако при необходимости можно синхронизировать рабочую копию и к более старому состоянию, чем текущее.


Working copy (рабочая копия) – рабочая (локальная) копия документов.

Рассмотрим возможности ИСР на примере наиболее доступных и популярных версий.

Eclipse (от англ. затмение) – свободная интегрированная среда разработки модульных кроссплатформенных приложений (рисунок 69). Развивается и поддерживается некоммерческой организацией Eclipse Foundation (http://www.eclipse.org/).

Первоначально Eclipse разрабатывалась фирмой «IBM» в качестве корпоративного стандарта ИСР для разработки на разных языках под платформы от данной компании. По сведениям «IBM», проектирование и разработка стоили 40 млн. долл. Исходный код был полностью открыт и сделан доступным после того, как Eclipse был передан для дальнейшего развития независимому от «IBM» сообществу.

В основе Эклипс лежат фреймворк OSGi и SWT/JFace, на основе которых разработан следующий слой – RCP (Rich Client Platform, платформа для разработки полноценных клиентских приложений). RCP служит основой не только для Эклипс, но и для других RCP-приложений, например, Azureus и File Arranger. Следующий слой – сам Эклипс, представляющий собой набор расширений RCP: редакторы, панели, перспективы, модуль CVS и модуль Java Development Tools (JDT).

Эклипс – в первую очередь, полноценная Java ИСР, нацеленная на групповую разработку: поддержка CVS входит в поставку Эклипс, активно развиваются несколько вариантов SVN-модулей, существует поддержка VSS и других. В силу бесплатности и высокого качества, Эклипс во многих организациях является корпоративным стандартом для разработки приложений.

Второе назначение Эклипс – служить платформой для разработки новых расширений, чем он и завоевал популярность: любой разработчик может расширить Эклипс своими модулями. Уже существуют C/C++ Development Tools (CDT), разрабатываемые инженерами QNX совместно с «IBM», и средства для языков COBOL, FORTRAN, PHP и прочие от различных разработчиков. Множество расширений дополняет среду Эклипс менеджерами для работы с базами данных, серверами приложений и др.

Рисунок 69. Интерфейс главного окна Эклипс

Эклипс написана на Java, потому является платформо-независимым продуктом, за исключением библиотеки SWT, которая разрабатывается для всех распространённых платформ. Библиотека SWT используется вместо стандартной для Java библиотеки Swing. Она полностью опирается на нижележащую платформу (операционную систему), что обеспечивает быстроту и натуральный внешний вид пользовательского интерфейса, но иногда вызывает на разных платформах проблемы совместимости и устойчивости приложений.

Основой Eclipse является платформа расширенного клиента (RCP — от англ. rich client platform). Её компоненты:

— ядро платформы (загрузка Eclipse, запуск модулей);

— OSGi (стандартная среда поставки комплектов (англ. bundles));

— SWT (портируемый инструментарий виджетов);

— JFace (файловые буферы, работа с текстом, текстовые редакторы);

— рабочая среда Эклипс (панели, редакторы, проекции, мастеры).

Другой популярной свободной ИСР является КДевелоп (http://www.kdevelop.org, рис. 70). КДевелоп (англ. KDevelop) — свободная среда разработки программного обеспечения для UNIX-подобных операционных систем. Проект стартовал в 1998 году. КДевелоп распространяется согласно лицензии GNU (General Public License).

Рисунок 70. Интерфейс KDevelop

KDevelop не включает в свой состав компилятор, вместо этого он использует любой компилятор для создания исполняемого кода.

Текущая стабильная версия поддерживает большое количество языков программирования, таких как Ада, Bash, C, C++, Фортран, Java, Pascal, Perl, PHP, Python, Ruby и SQL.

КДевелоп использует встроенный компонент – текстовый редактор – через технологию KParts. Основным редактором является Kate.

— подсветка исходного кода с учетом синтаксиса используемого языка программирования, который определяется автоматически;

— менеджер проектов для проектов разного типа, таких как Automake, qmake для проектов базирующихся на технологиях Qt и Ant для проектов, базирующихся на Java;

— навигатор классов (Class Browser);

— Front-end для GNU Compiler Collection;

— Front-end для GNU Debugger;

— помощников для генерации и обновления определения классов и платформы (framework);

— автоматическая система завершения кода (Си/C++);

— встроенная поддержка системы документирования исходных кодов (Doxygen);

— одна из систем контроля версий: SCM, CVS, Subversion, Perforce и ClearCase;

— функция Quick Open позволяющая быстро перемещаться по файлам.

KDevelop представляет собой «подключаемую» архитектуру. Когда разработчик делает изменения, он должен лишь скомпилировать плагин. Предусмотрена возможность сохранения профилей, указывающих какие плагины должны быть загружены.KDevelop не поставляется со встроенным текстовым редактором, он подключается как плагин. KDevelop не зависит от языка программирования и от платформы, на которой он запускается, поддерживая KDE, GNOME и много других технологий (например, Qt, GTK+ и wxWidgets).

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

На данный момент существует примерно от 50 до 100 плагинов для данной IDE. Среди наиболее полезных – persistent project-wide code bookmarks, Code abbreviations, позволяющие быстро разворачивать текст, Source formatter, который переформатирует текст для style guide до сохранения, поиск по регулярным выражениям и project-wide поиск/замена.

Последней рассматриваемой ИСР является Microsoft Visual Studio (Microsoft Visual Studio, рис. 71). По сути, Microsoft Visual Studio является линейкой продуктов компании «Майкрософт», включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.

Рисунок 71. Интерфейс Microsoft Visual Studio

Microsoft Visual Studio включает один или несколько компонентов из следующих: Visual Basic.NET, Visual C++, Visual C#, Visual F#, Microsoft SQL Server, Visual InterDev, Visual J++, Visual J#, Visual FoxPro, Visual Source Safe.

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

Также компания «Майкрософт» предлагает бесплатный аналог продукта Visual Studio Express.

Не нашли то, что искали? Воспользуйтесь поиском:

Создание гибридного Qt Quick и C++ приложения

Добрый день, %username%!

Небольшая предыстория:

Некоторое время назад делал знакомому лабораторную, тематика которой – код Хэмминга. Программа представляла собой обыкновенное Qt приложение с минимальным набором контролов. Сдача прошла успешно, прошло некоторое время, и его теперь другу необходимо тоже сдать лабораторную на эту же тематику. Ту же программу, очевидно, сдавать нельзя. Тут возникает вопрос – как сделать программу с тремя кнопками и двумя текстбоксами непохожей на предыдущую? Мне в голову пришла мысль переписать интерфейс с помощью Qt Quick, а логику и расчеты программы оставить в С++, а заодно и рассказать интересующимся людям, как я обычно делаю подобные вещи. По Qt Quick не так много литературы, тем более на русском, так что очень надеюсь, что данная статья будет полезна и интересна. Уточню – основное внимание уделено способам взаимодействия Qt Quick и C++, в меньшей мере основам Qt и QML, но никак не подсчету кодов Хэмминга.

Создание каркаса

Итак, идут последние секунды установки Qt Sdk у меня на работе, мы начинаем.
Открываем QtCreator, создаем новый проект типа «GUI приложение Qt». Выбираем директорию, название, затем вот в это окошке мастера:

убираем галку «Создать форму». Она нам не понадобится, весь интерфейс будем писать ручками.
В сгенерированном файле mainwindow.h включите следующие заголовочные файлы:

#include #include
#include

В конструкторе класса MainWindow внесем следующие изменения:

MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent)
<
QDeclarativeView* dv = new QDeclarativeView();
dv->setSource(QUrl(«qrc:/main.qml»));
QDeclarativeContext* cntx = dv->rootContext();
cntx->setContextProperty(«window»,this);

Немного поясню – мы создаем виджет типа QDeclarativeView – это элемент, способный отображать QML. Затем задаем имя корневого QML элемента — main.qml, который берется из ресурсов, которые добавим позже. Затем получаем контекст виджета, чтобы добавить в нем новое свойство «window”. Теперь из QML можно будет обращаться к объекту под названием window — это есть наша форма. Зачем это нужно станет ясно чуть позже. Ниже задается режим изменения размера – теперь корневой QML элемент будет изменять размер в соответствии с окном, а не наоборот. Метод setCentralWidget устанавливает для QMainWindow центральный виджет. Все, кто сталкивался с Qt, несомненно знакомы с ним.

Наш проект нуждается в QML файле, котором говорилось выше. Добавим его:

Теперь похожим образом добавляем файл ресурсов:

Он автоматически открывается, внизу жнем «Добавить» -> «Добавить префикс», появляется «/new/prefix1». Стираем и оставляем только «/» для простоты. Теперь добавляем туда файл main.qml ( “Добавить” -> «Добавить файл» ). Еще одна маленькая вещь – в файл *.pro нужно внести одно изменение
QT += core declarative
Таким нехитрым образом мы выставляем проекту зависимость от библиотеки QtDeclarative4


Теперь можно смело запускать проект и видеть … Белый квадрат 100 на 62 :) Но внешность обманчива – на самом деле это куда больше, чем белый квадрат, это приложение, интерфейс которого написан на QML, а логика на C++.
Примерно так начинается создание любого приложения, которое будет гибридом Qt Quick и C++. Основной момент — получение корневого контекста виджета QDeclarativeView, добавление нового свойства для доступа к объекту C++. Это свойство станет своего рода мостом между QML и С++.

Создание интерфейса и логики

Итак, этап создания базиса пройден, теперь логика работы.
В файле mainwindow.h в описание класса добавляем
public slots:
QString slotEncode(QString sIn);
QString slotDecode(QString sIn);
bool slotCheck(int val);

По названию ясно, что первые два слота будут заниматься кодированием и декодированием. Принимать на вход оба будут строку, которую пользователь введет в QML, а возвращать, соответственно, кодированный или декодированный вариант. Почему слоты вместо обыкновенных функций? Потому что именно слоты, а так же функции, объявленные с помощью макроса Q_INVOKABLE (подробнее см. документацию ) могут быть вызваны из QML посредством обращения к объекту, сделанному видимым с помощью setContextProperty(). Проще говоря, можно будет написать window.slotEncode() в QML :) Так же из QML кода доступны все свойства, объявленные с помощью макроса Q_PROPERTY — к ним можно обращаться прям по имени.

Реализацию данных слотов я возьму из старого проекта, и не приведу их тут в полном виде, можете скачать архив по ссылке ниже. Есть так же небольшая оговорка – в процессе кодирования и декодирования строится таблица, которую мне совсем не хотелось переписывать, поэтому она останется в первоначальном виде и просто будет показана в отдельном окне. Так же был добавлен слот slotCheck(int v) для служебных целей, использующийся только в процессе подсчета кода, и конечно, его нужно добавить, однако совсем не стоит задумываться, для чего он – ибо не относится к уроку!

Теперь осталось только сделать интерфейс программы :)
Пожалуй, я выдам ту версию интерфейса, которая делается минут за 15, обыкновенным программистом без творческого взгляда на мир (хотя обычно мне помогает моя девушка-художник делать делать подобные вещи):
import QtQuick 1.0

Rectangle <
width: 365
height: 200
gradient: Gradient <
GradientStop <
position: 0
color: «#696363»
>

GradientStop <
position: 1
color: «#000000»
>
>

Text <
id: text1
x: 37
y: 27
color: «#fbfbfb»
text: «Исходное слово»
style: Text.Raised
font.pixelSize: 12
>

Text <
id: text2
x: 198
y: 27
color: «#ffffff»
text: «Код Хэмминга»
style: Text.Raised
font.pixelSize: 12
>

// Поле ввода прямого кода.
Rectangle <
color: «#4de013»
radius: 6
border.width: 5
border.color: «#f5f9f4»
x: 36
y: 66
width: 133
height: 20
TextInput <
id: text_input1
width: parent.width — 20
height: parent.height — 5
anchors.horizontalCenter: parent.horizontalCenter
anchors.verticalCenter: parent.verticalCenter
text: «»

// Поле для кода Хэмминга.
Rectangle <
color: «#48c819»
radius: 6
border.width: 5
border.color: «#f5f9f4»
width: 133
height: 20
x: 201
y: 66
TextInput <
id: text_input2
width: parent.width — 20
height: parent.height — 5
anchors.horizontalCenter: parent.horizontalCenter
anchors.verticalCenter: parent.verticalCenter
text: «»
font.pixelSize: 12
>
>

// Кнопки кодирования.
Rectangle <
id: bEncode
property alias text: label.text

width: 135
height: 60
radius: 20
border.width: 2
border.color: «#090606»

gradient: Gradient <
GradientStop <
id: gradientstop1
position: 0.01
color: «#ffffff»
>

GradientStop <
id: gradientstop2
position: 0.28
color: «#867d7d»
>

GradientStop <
id: gradientstop3
position: 1
color: «#000000»
>
>

signal clicked()
x: 36
y: 110

Text <
id: label
color: «#ffffff»
text: «Кодировать»
font.strikeout: false
font.pointSize: 10
horizontalAlignment: Text.AlignHCenter
anchors.centerIn: parent
>

MouseArea <
id: mouseArea
anchors.fill: parent
hoverEnabled: true
onClicked: <
text_input2.text = window.slotEncode(text_input1.text)
>
onEntered: <
bEncode.state = «green»
>
onExited: <
bEncode.state = «gray»
>
>
states: [
State <
name: «gray»
>,
State <
name: «green»

PropertyChanges <
target: gradientstop1
color: «#ffffff»
>

PropertyChanges <
target: gradientstop2
color: «#34c22a»
>

PropertyChanges <
target: gradientstop3
color: «#000000»
>
>
]

// Кнопка декодирования.
Rectangle <
id: bDecode
property alias text: label.text

width: 136
height: 60
radius: 20
border.width: 2
border.color: «#090606»

gradient: Gradient <
GradientStop <
id: gradientstop21
position: 0.01
color: «#ffffff»
>

GradientStop <
id: gradientstop22
position: 0.28
color: «#867d7d»
>

GradientStop <
id: gradientstop23
position: 1
color: «#000000»
>
>

signal clicked()
x: 200
y: 110

Text <
id: label2
text: «Декодировать»
color: «#ffffff»
font.strikeout: false
font.pointSize: 10
horizontalAlignment: Text.AlignHCenter
anchors.centerIn: parent
>

MouseArea <
id: mouseArea2
anchors.fill: parent
hoverEnabled: true
onClicked: <
text_input1.text = window.slotDecode(text_input2.text)
>
onEntered: <
bDecode.state = «green»
>
onExited: <
bDecode.state = «gray»
>
>
states: [
State <
name: «gray»
>,
State <
name: «green»

PropertyChanges <
target: gradientstop21
color: «#ffffff»
>

PropertyChanges <
target: gradientstop22
color: «#34c22a»
>

PropertyChanges <
target: gradientstop23
color: «#000000»
>
>
]

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

Ссылка на исходники — Тык!

Небольшой итог

Результатом нашей работы стало гибридное приложение. В перспективе создание подобных приложений позволяет совместить нестандартный интерфейс QtQuick с высокопроизводительным С++ кодом. Надеюсь, статья будет полезной интересующимся данными технологиями, ибо вопросы «Дайте литературу по Qt Quick» встречаются все чаще. Спасибо за внимание!

Введение в среду Google C++ Testing Framework

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

Для чего нужна Google C++ Testing Framework?

Существует множество причин использовать эту платформу. В этом разделе будут рассмотрены некоторые из них.

Некоторые категории тестов сталкиваются с проблемами памяти, проявляющимися только при определенных условиях. Среда тестирования от Google имеет отличную поддержку для обработки таких ситуаций. С помощью платформы от Google вы можете выполнять один и тот же тест тысячи раз. При первом обнаружении проблемы автоматически вызывается отладчик. Все это может быть проделано с помощью всего лишь двух опций командной строки: —gtest_repeat=1000 —gtest_break_on_failure .

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

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

Вы можете легко создать отчет в формате XML (Extensible Markup Language) с помощью опции —gtest_output=»xml: » . Для вывода XML-отчета в таких системах, как CppUnit и CppTest, вам необходимо написать существенно больший объем кода.

Создание базового теста

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

Листинг 1. Макет функции вычисления квадратного корня

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

Листинг 2. Модульный тест для функции вычисления квадратного корня

В листинге 2 создается иерархия тестов с именем SquareRootTest , а затем к ней добавляются два модульных теста с именами PositiveNos и ZeroAndNegativeNos . TEST – это встроенный макрос, определенный в модуле gtest.h (доступен с загружаемым исходным кодом) и помогающий создать иерархию. EXPECT_EQ и ASSERT_EQ также являются макросами — в первом случае контрольного примера выполнение теста продолжается даже при возникновении ошибки, в то время как во втором случае в этой ситуации выполнение теста прекращается. Безусловно, если квадратный корень из 0 отнюдь не 0, то в любом случае, тестировать особо нечего. Вот почему в тесте ZeroAndNegativeNos используется макрос ASSERT_EQ , тогда как в тесте PositiveNos используется макрос EXPECT_EQ , показывающий, сколько было случаев, когда функция вычисления квадратного корня завершалась с ошибкой, но выполнение теста не прекращалось.

Запуск первого теста

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

Листинг 3. Запуск теста функции вычисления квадратного корня


Метод ::testing::InitGoogleTest работает в соответствии со своим названием – он инициализирует платформу, и его необходимо вызвать перед функцией RUN_ALL_TESTS . Функцию RUN_ALL_TESTS необходимо вызвать всего один раз, так как множественные вызовы этой функции не поддерживаются, поскольку конфликтуют с некоторыми расширенными возможностями платформы. Обратите внимание на то, что функция RUN_ALL_TESTS автоматически определяет и запускает все тесты, определенные с помощью макроса TEST . По умолчанию результат выводится на устройство стандартного вывода. В листинге 4 показан результат выполнения теста.

Листинг 4. Вывод теста функции вычисления квадратного корня

Дополнительные опции Google C++ Testing Framework

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

Вы можете выгрузить вывод в файл формата XML, указав в командной строке опцию —gtest_output=»xml:report.xml» . Конечно, вы можете заменить имя report.xml любым другим на свое усмотрение.

Существуют определенные тесты, которые иногда завершаются с ошибкой, но в большинстве случаев выполняются успешно. Это присуще проблемам, связанным с ошибкой в памяти. В таких случаях возможность выявить ошибку будет выше, если тесты выполняются множество раз. Если вы укажете в командной строке опции —gtest_repeat=2 —gtest_break_on_failure , то один и тот же тест будет выполнен дважды. Если тест завершается с ошибкой, автоматически вызывается отладчик.

Не все тесты бывает необходимо запускать каждый раз, особенно если вы вносите изменения в код только определенных модулей. Для этого система тестирования от Google предоставляет в ваше распоряжение опцию —gtest_filter= . Маска представляет собой набор регулярных выражений, разделенных двоеточиями (:). Например, опция —gtest_filter=* запускает все тесты, а опция —gtest_filter=SquareRoot* запускает только тесты группы SquareRootTest . Если вы хотите запустить тесты группы SquareRootTest только для положительных значений, используйте опцию —gtest_filter=SquareRootTest.*-SquareRootTest.Zero* . Обратите внимание на то, что маска SquareRootTest.* включает выполнение всех тестов группы SquareRootTest , а маска -SquareRootTest.Zero* исключает выполнение тестов, имена которых начинаются с Zero.

В листинге 5 приведен пример запуска группы тестов SquareRootTest с использованием опций gtest_output , gtest_repeat и gtest_filter .

Листинг 5. Запуск тестов SquareRootTest с опциями gtest_output , gtest_repeat и gtest_filter

Временное отключение тестов

Предположим, вы приостановили выполнение определенной части кода. Можно ли временно отключить тест? Да, просто добавьте префикс DISABLE_ к логическому имени теста или к имени отдельного его модуля, и он перестанет выполняться. В листинге 6 показано, что вам необходимо сделать для того, чтобы отключить выполнение теста PositiveNos , приведенного ранее в листинге 2.

Листинг 6. Временное отключение тестов

Обратите внимание на то, что по окончании выполнения тестов среда тестирования Google выводит предупреждение о том, что имеются отдельные отключенные тесты. Это показано в листинге 7.

Листинг 7. Предупреждение среды Google об отключенных тестах

Если вы хотите продолжить выполнение отключенных тестов, укажите в командной строке опцию -gtest_also_run_disabled_tests . В листинге 8 показан результат работы программы, когда запускается тест DISABLE_PositiveNos .

Листинг 8. Google позволяет запускать отключенные тесты

Все о правилах

Платформа тестирования компании Google содержит в себе множество предопределенных правил. Существует два типа правил – правила, имена которых начинаются с ASSERT_ , и правила, имена которых начинаются с EXPECT_ . Правила ASSERT_* прерывают выполнение программы при нарушении условия, тогда как в случае правил EXPECT_* выполнение программы продолжается. В обоих случаях при нарушении условий система выводит имя файла, номер строки и сообщение, которое вы можете определить самостоятельно. Одними из несложных правил являются ASSERT_TRUE (условие) и ASSERT_NE (значение1, значение2) . Первое из них предполагает, что указанное условие всегда должно выполняться, а второе – что два значения не должны совпадать. Эти правила также работают с определенными пользователями типами данных, но при этом вы должны выполнить перегрузку соответствующего оператора сравнения (==, !=,

Почему нужны отдельные макросы для сравнения чисел с плавающей запятой? Разве не будет работать правило ASSERT_EQ ? Ответ заключается в том, что ASSERT_EQ и связанные с ним макросы могут работать, а могут и не работать, и поэтому лучше использовать макросы, специально предназначенные для сравнения чисел с плавающей запятой. Обычно различные центральные процессоры и рабочие окружения хранят числа с плавающей запятой по-разному, и простые сравнения ожидаемых и фактических значений не работают. Например, правило ASSERT_FLOAT_EQ (2.00001, 2.000011) сработает – Google не возвращает ошибок, если значения совпадают с точностью до четырех десятичных знаков. Если вам необходима более высокая точность, используйте правило ASSERT_NEAR (2.00001, 2.000011, 0.0000001) , и тогда вы получите ошибку, показанную в листинге 10.

Листинг 10. Сообщение об ошибке, выводимое правилом ASSERT_NEAR

«Смертельные» тесты

В системе Google C++ Testing Framework имеется интересная категория правил ( ASSERT_DEATH , ASSERT_EXIT и т. д.), называющихся «смертельными» правилами. Эти правила используются для проверки того, было ли какое-либо сообщение об ошибке получено в результате передачи на вход функции некорректных данных, или же работа этой функции была завершена в соответствии с заранее определенным кодом завершения. Например, возвращаясь к листингу 3, неплохо было бы получить сообщение об ошибке при выполнении функции square-root (-22.0) и выйти из программы со статусом -1 вместо получения значения -1.0 . В листинге 11 для такого сценария используется правило ASSERT_EXIT .

Листинг 11. Выполнение «смертельного» теста платформы Google

Правило ASSERT_EXIT проверяет, была ли функция завершена в соответствии с заданным кодом завершения (т. е. аргументом функций exit или _exit ), и сравнивает заключенную в кавычки строку с тем, что выводит функция на стандартное устройство сообщений об ошибках. Обратите внимание на то, что сообщения об ошибках должны выводиться на устройство std::cerr , а не на std::cout . В листинге 12 представлены макеты для правил ASSERT_DEATH и ASSERT_EXIT .

Листинг 12. Макеты для «смертельных» правил

Google предоставляет в ваше распоряжение встроенный предикат ::testing::ExitedWithCode(код_завершения) . Результат этого предиката будет истинным только в том случае, если программа завершается с тем же кодом завершения, что и аргумент код_завершения этого предиката. Правило ASSERT_DEATH проще, чем правило ASSERT_EXIT – оно просто сравнивает сообщение об ошибке, выводимое на стандартное устройство, с ожидаемым сообщением, заданным пользователем.

Понимание тестовых фикстур

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

Листинг 13. Класс тестовой фикстуры

Класс фикстуры является производным от класса ::testing::test , объявленного в модуле gtest.h . В листинге 14 приведен пример, в котором используется класс фикстуры. Обратите внимание на то, что в данном примере вместо макроса TEST используется макрос TEST_F .

Листинг 14. Пример использования фикстуры

Ниже перечислены несколько условий, которые необходимо учитывать при использовании фикстур:

  • Вы можете выполнить инициализацию или распределение ресурсов как с помощью конструктора, так и с помощью метода SetUp – выбор остается за вами.
  • Вы можете освобождать ресурсы с помощью метода TearDown или с помощью функции деструктора. Однако если вы хотите использовать обработку исключений, вы должны делать это только через метод TearDown , поскольку вызов исключения в деструкторе может привести к непредсказуемым результатам.
  • Макросы правил Google могут вызывать исключения на тех платформах, для которых они доступны в будущих версиях. Поэтому для лучшего сопровождения программ хорошо использовать макросы правил в коде метода TearDown .
  • Одни и те же фикстуры не используются в различных тестах. Для каждого нового модульного теста система создает новую тестовую фикстуру. Так что в листинге 14 метод SetUp (пожалуйста, используйте здесь правильную орфографию) вызывается дважды, потому что создаются два объекта myFixture1 .

Заключение

В этой статье мы лишь поверхностно рассмотрели платформу Google C++ Testing Framework. Подробная документация по этой платформе доступна на сайте компании Google. Для профессиональных разработчиков я рекомендую ознакомиться с дополнительными материалами об открытых платформах регрессионного тестирования, таких как Boost unit test framework и CppUnit. Для получения дополнительной информации обратитесь к разделу Ресурсы.

Введение в QUIK (Квик) и LUA

В этой части мы будем с вами говорить о таком направлении как программирование на языке QLUA. Что же это за язык такой? — Обыкновенный язык программирования, каких существует множество, но с небольшой оговоркой. Вообще говоря существует язык программирования LUA, а первая буква Q в названии, говорит нам о том, что мы применяем данный язык программирования в платформе QUIK (Квик). Ещё этот язык иногда называют QuikLua, что в принципе тоже верно. Ну да ладно, как бы его не называли суть остается неизменной.

Если вы начинаете с самого начала и ещё ни разу не слышали о том как писать индикаторы или скрипты в платформе QUIK, то этот сайт как раз то что вам нужно.

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

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

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

Где писать код?

Индикатор или скрипт это обыкновенный текстовый документ который имеет специальное расширение. Поэтому писать мы можем используя любой текстовый редактор, даже самый простой блокнот встроенный в операционную систему Windows. Открываем блокнот, пишем необходимый код сохраняем и всё наш индикатор или скрипт готов, можем использовать его в платформе QUIK, всё просто. Просто, да неудобно. Вы видели как выглядит текст в блокноте? Сплошной черный текст на белом фоне, писать можно, читать тоже можно, но программировать просто ужасно трудно. Поэтому я вам предлагаю использовать расширенную версию блокнота, называется эта программа notepad++. Я никоим образом ни кого не заставляю использовать именно ее, можете использовать любую другую программу. Я же предпочитаю пользоваться именно notepad++.

Если Вы решили как и я использовать для написания кода программу notepad++, то рекомендую перейти в раздел «QLUA (Квик) -> Рабочее Место» изучить все статьи начиниая с первой «Редактор кода notepad++» и настроить свое рабочее место.

Индикатор или скрипт? Что выбрать?

Теперь ответим на второй главный вопрос — Что мы будем писать? Выбор у нас конечно невелик, либо это будет индикатор, либо это будет скрипт. Настало время разобраться чем же отличается скрипт от индикатора. Для простоты понимания и чтобы не загружать вас огромным количеством всякой разной информации на начальном этапе, определимся со следующим. Если то что мы задумали сделать, необходимо отображать на графике, в этом случае выбираем для написания индикатор. В остальных случаях можно выбирать скрипт. Конечно же это очень грубое разграничение, но для начала будет достаточным. Когда вы в процессе изучения получите больше информации, что пишется в индикаторах, а что пишется в скриптах, вы сможете сами определить где вам лучше реализовать то что вы задумали.

в заключении

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

Если у вас всё готово, а главное вы сами готовы, то переходим к следующему шагу.

Введение в понимание программирования ;)

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

Если будет непонятно – не расстраивайтесь. Очень многие профессиональные программисты так же ничего в этом не понимают (что не мешает им эффективно работать).


Итак, КО мог бы сказать, что язык программирования — формальная знаковая система, предназначенная для записи компьютерных программ. Для того чтобы понять что такое язык программирования нужно понять, что такое… Инструкция.

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

Рассмотрим простую инструкцию – она написана на каком-либо языке, содержит разделы, приложения и имеет определенную структуру и стиль.

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

Разделы инструкции в программировании называют функциями.

Язык инструкции – язык программирования.

Основные парадигмы программирования:

Класс декларативного программирования – это класс парадигм которые вместо алгоритма описывают результат который требуется получить. Представители класса:

Чисто декларативное программирование, кстати, не всеми программистами считается программированием. Это такие языки как SQL, HTML. Кто видел код тот поймет почему программисты так считают. «Код» не обладает всеми возможностями языка программирования и является простым описанием требуемого результата.

Логическое программирование – программирование на основе фактов и моделей связи между фактами. Единственный вменяемый представитель: Prolog

Функциональное программирование – для использования программирования используется стиль математических операций. Если не знакомы с дискретной математикой, то ничего не понятно от слова совсем. Представители этой парадигмы: LISP, Erlang, Scala, Miranda, Haskell.

Пример программы (Hello World) на LISP:

(format t «Hello, world!

Пример чуть сложнее:

(defun fibonacci (n)

for a = 0 then b

and for b = 1 then (+ a b)

finally (return b)))

Класс императивного программирования – программирование которое заключается в написании однозначной инструкции для компьютера на выполнение порядка действий. В этот класс входят:

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

Пример программы (С++):

.» ПОЛОЖИТЕЛЬНОЕ ЧИСЛО» ELSE

.» ОТРИЦАТЕЛЬНОЕ ЧИСЛО» THEN

Объектно-ориентированное программирование (ООП) – как следует из названия программирование на основе объектов которые являются экземплярами классов. Является важной опцией языков программирвоания.

В ООП производятся операции со свойствами экземпляров классов путем выполнения методов. Методы – набор инструкций по изменению классов.

Основной концепцией ООП является система ООП на классах:

Чтобы понятно перевести это на русский давайте посмотрим на домашних животных. Возьмем кота Ваську и собаку Жучку.

У всех животных есть общие черты, значит корневой класс будет «животные», кошка и собака относятся к млекопитающим, подкласс «млекопитающие», Васька – кот, а Жучка — собака, но они не являются «родственниками». Поэтому у нас будут 2 подкласса «Собаки» и «Коты». Итоговая структура классов:

Класс Млекопитающие, наследует класс Животные

Свойство: кормит молоком детенышей

Класс Собака, наследует класс Млекопитающие

Класс Кот, наследует класс Млекопитающие

И теперь пример

Васька – экземпляр класса Кот

Жучка – экземпляр класса Собака

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

Но Жучка может лаять и не может мурчать, а Васька может мурчать, но не может лаять поскольку их «фирменные» классы не содержат соответствующих свойств.

Помимо классов есть программирование основанное на прототипах. В этом случае отсутствует описание класса, оно выводится в момент написания программы. Язык программирования для примера: JavaScript.

Является парадигмой программирования, но не является определяющим для языка программирования:

Структурное программирование – оформление программы так чтобы она легко читалась и понималась другими программистами. То есть это простой и понятный стиль написание программы. Язык, который частично заставляет это делать, Python.

«Чистых» языков программирования (которые бы использовали только одну парадигму) не существует, каждый язык отражает в себе одну или несколько парадигм.

Если тема будет интересна то напишу обзоры для Perl, Python, C++, JavaScript, Prolog, SQL, HTML+CSS.

Всех с наступающим праздником! Счастья, здоровья, удачи!

7.3.3. Квотирование

Что такое квотирование. Особенности квотирования в Linux

Квотирование — мощный механизм ограничения использования дискового пространства, применявшийся еще в самых ранних версиях UNIX, тогда как в состав ОС семейства Windows компания Microsoft включила их только в Windows 2000, естественно, гордо заявив об этом. Этот материал настолько объемен, что ему можно было бы смело посвятить целую главу.

При помощи квот системный администратор принуждает пользователя не расходовать неограниченный объем дискового пространства. Существует два типа ограничений: ограничение на количество файлов (inodes) и ограничение на размер дискового пространства в килобайтах (blocks). Если установлены оба ограничения, то они будут применяться одновременно.

Ограничения на inodes и на blocks могут быть установлены как для пользователя, так и для группы. Если вы входите в группу, которая превысила наложенное на нее ограничение, то вы не сможете использовать дисковое пространство, даже если вы не превысили квоту как пользователь.

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

1. Текущее значение ограничения;

2. «Мягкое» ограничение (softlimit);

3. «Жесткое» ограничение (hardlimit);

4. Период отсрочки: время, по истечении которого «мягкое» ограничение будет интерпретироваться как «жесткое».


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

Ядро и поддержка квотирования

В ядро ОС Linux поддержка квотирования встроена (по некоторым сведениям, она появилась в ядре, начиная с версии 1.3.8), осталось убедиться, что она у вас включена. Если это не так, то ядро придется перекомпилировать.

После установки дистрибутива исходные тексты модулей ядра обычно находятся в каталоге /lib/modules/ /build .

Привыкайте к возможностям подстановки аргументов командной оболочкой bash: перейти в этот каталог можно командой

$ cd /lib/mod*/`uname -r`/build

Там лежит файл .config , хранящий текущие настройки ядра (имя файла начинается с точки, поэтому он считается скрытым: чтобы увидеть его по команде ls, пользуйтесь ключом ). Найдите в нем строку СОNFIG_QUOTA и убедитесь, что значение этого параметра равно «y». Далее обратите внимание на формат квот, строки CONFIG_QFMT_V , где x = 1 или 2. Версия 1 — это старый формат, использовавшийся в ядрах до версии 2.6. Если ваш дистрибутив основан на ядре 2.4, должен быть включен старый формат. Он отличается именами файлов квот.

Ту же самую проверку (при необходимости — настройку) можно выполнить и с помощью диалогового конфигуратора. Чтобы запустить его, выполните одну из следующих команд:

? make menuconfig: работает в консоли, предлагает текстовые меню и кнопки;

? make config: работает в консоли, задает вопросы;

? make xconfig: работает в графическом режиме при запущенной системе X Window;

? make gconfig: то же самое, только для оконной среды GNOME.

На рис. 7.2 показано окно конфигуратора ядра для оконной среды GNOME. Обратите внимание, что квоты поддерживаются только для файловых систем ext2, ext3 и ReiserFS.

Проверьте, установлены ли у вас утилиты квотирования, командой

Скачать пакет этих утилит можно из репозитория Сизиф, поддерживаемого командой разработчиков ALT Linux: http://alt.linux.kiev.ua/srpm/quota/get .

Рис. 7.2. Графический конфигуратор ядра, меню Filesystems

Назначение и активация квот

Теперь нужно определить, использование какой файловой системы вы хотите ограничить. Обычно это /home (домашние каталоги пользователей), /usr (пользователи имеют право записывать информацию в этот каталог) и, возможно, /var . Чтобы включить квотирование файловой системы, отредактируйте файл /etc/fstab , добавив ключ usrquota (и/или grpquota для групп) в поле, содержащее слово defaults

/dev/hda1 / ext2 defaults

/dev/hda4 /home ext3 defaults,usrquota=/путь/к/файлу/квот

/dev/hda5 /usr ext3 defaults,usrquota,grpquota

Если путь к файлу квот не указан, то используется файл в корневом каталоге квотируемой файловой системы. В версии 2 (ядро 2.6) он называется aquota.user ( aquota.group для групп), в версии 1 — quota.user и quota.group .

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

Если программа quotacheck не находит файлов ограничений, то создает их.

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

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

Команда quota | позволяет просмотреть ограничения дискового пространства, наложенные системным администратором на данного пользователя или группу, а команда repquota — сводку ограничений и фактически занятого дискового пространства для всех пользователей данной файловой системы (с ключом — всех файловых систем).

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

Рис. 7.3. Результат выполнения команды quotacheck -avug

Рис. 7.4. Результат выполнения команды repquota -um

Для задания ограничении предназначена команда edquota. Файлы ограничений при этом должны уже существовать. Создайте их и включите режим подсчета квот командами:

# quotacheck -u # для групп нужно

# выполнить то же

# quotaon -u # самое с ключом -g

Команда edquota -u создает временный текстовый файл, представляющий собой выдержку из двоичного файла квот, запускает ASCII- редактор, указанный в переменной окружения $EDITOR (по умолчанию это редактор vi), в котором вы можете отредактировать ограничения для данного пользователя, и записывает сохраненный текстовый файл обратно в файл квот.

Текущие показатели занятого дискового пространства приводятся только для справки, редактировать нужно только число, которое следует за словом hard или soft (рис. 7.5). Значение «0» указывает на отсутствие ограничений.

Рис. 7.5. Результат выполнения команды edquota -u den

Чтобы изменить период отсрочки, пользуйтесь ключом -t :

Time units may be: days, hours, minutes, or seconds

Grace period before enforcing soft limits for users:

/dev/hda4: block grace period: 50 minutes,

file grace period: 50 minutes

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

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

можно определить ограничения прототипа, а затем с помощью команды:

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

Для активации/деактивации подсчета квот на файловой системе, для которой заказано квотирование, предназначены команды quotaon и quotaoff. Команду quotaon нужно включить в сценарий загрузки системы, как и команду quotacheck:

# Смонтированы все файловые системы из /etc/fstab

# Проверка и активация квот

echo «Checking quotas. This may take some time.»

Глава 2
Введение

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

В главе имеются следующие разделы:


Архитектура Приложений JavaScript

Как уже говорилось, приложения JavaScript имею части, работающие на стороне клиента и на сервере. Кроме того, многие приложения JavaScript используют LiveWire Database Service для соединения приложения с реляционной базой данных. Исходя из этого, Вы можете представить приложения JavaScript как имеющие трёхслойную клиент-серверную архитектуру, как показано на Рисунке 2.1.

Рисунок 2.1 Архитектура среды клиент-серверного приложения на языке JavaScript
  • WWW-клиенты (такие как Netscape Navigator-клиенты): Этот слой предоставляет приложению межплатформенный интерфейс конечного пользователя. Этот слой может также содержать некоторую логику приложения, такую как правила проверки данных, реализованные в клиентском JavaScript. Клиенты могут находиться внутри или за пределами прокси-сервера корпоративной сети.
  • Netscape WWW-сервер/БД клиент: Этот слой состоит из Netscape-сервера с включённым JavaScript. Он содержит логику приложения, обслуживает безопасность и контролирует доступ к приложению нескольких пользователей, используя серверный JavaScript. Этот слой позволяет клиентам как в пределах действия, так и за пределами прокси-сервера иметь доступ к приложению. WWW -сервер также работает как клиент с любым установленным сервером БД.
  • Серверы баз данных: Этот слой состоит из SQL-серверов БД, работающих обычно на высокопроизводительных рабочих станциях. Он содержит все данные БД, метаданные и правила ссылочной целостности/referential integrity, необходимые для работы приложения. Этот слой обычно находится в зоне действия прокси-сервера корпоративной сети и может предоставлять слой безопасности дополнительно к слою безопасности WWW -сервера. Netscape Enterprise Server поддерживает использование серверов БД: ODBC, DB2, Informix, Oracle и Sybase. Netscape FastTrack Server поддерживает только ODBC. Дополнительно о LiveWire Database Service см. Часть 3, «Служба LiveWire Database Service.»

Клиентская среда JavaScript работает как часть WWW -клиентов, а серверная среда JavaScript работает как часть Netscape web-сервера с доступом к одному или более серверов БД. Рисунок 2.2 показывает более детально, как серверная среда JavaScript и приложения, созданные для неё, встраиваются в Netscape web-сервер.

Верхняя часть Рисунка 2.2 демонстрирует то, как серверный JavaScript встраивается в Netscape web-сервер. Внутри web-сервера среда работы серверного JavaScript состоит из трёх основных компонентов, перечисленных ниже. JavaScript Application Manager работает поверх серверного JavaScript, как это делается в образце приложения, предоставленном Netscape (таком как приложение videoapp ), и в любом приложении, созданном Вами.

Рисунок 2.2 Серверный JavaScript в среде Netscape-сервера

Имеются три главных компонента среды работы JavaScript:

  • Библиотека времени выполнения JavaScript: этот компонент предоставляет базовую функциональность JavaScript. Примером может служить Session Management Service, которая предоставляет предопределённые объекты для помощи в обслуживании Вашего приложения и совместного использования информации клиентом и сервером и несколькими приложениями. Служба Session Management Service описана в Главе 6, «Служба Session Management Service».
  • Библиотека LiveWire доступа к БД: Этот компонент расширяет базовую функциональность серверного JavaScript классами и объектами, которые предоставляют аналогичный доступ к внешним серверам БД. Это описано в Части 3, «Служба LiveWire Database Service.»
  • Виртуальная машина Java (ВМ): В отличие от других компонентов, ВМ Java используется не только в JavaScript; любое Java-приложение, запущенное на сервере, использует эту ВМ. ВМ Java была доработана для того, чтобы дать приложениям JavaScript возможность получать доступ к Java-классам через использование LiveConnect -функциональности JavaScript. LiveConnect описана в Главе 14, «LiveConnect. Обзор.»

В целом приложение на JavaScript может содержать операторы, интерпретируемые клиентом (интерпретатором JavaScript, предоставляемым Netscape Navigator’ом или некоторыми другими web-браузерами) и сервером (машиной выполнения JavaScript, уже рассмотренной).

Когда вы запускаете приложение JavaScript, происходят различные действия: некоторые на сервере, и некоторые — на клиенте. Хотя конечному пользователю не обязательно знать все детали, Вам как разработчику приложения необходимо понимать, что происходит «под капотом.»

При создании приложения Вы пишете HTML-страницы, которые могут содержать операторы серверного и клиентского JavaScript. В исходном коде HTML клиентский JavaScript находится в тэгах SCRIPT , а серверный JavaScript — в тэгах SERVER .

Вы можете также писать файлы, содержащие только операторы JavaScript без тэгов HTML. Такой JavaScript-файл может содержать либо клиентский, либо серверный JavaScript; один файл не может содержать и клиентские, и серверные объекты или функции.

JavaScript VM (Виртуальная Машина), используемая в Netscape Enterprise Server 4.0, реализует значительные улучшения для обработки локальных переменных (то есть переменных, которые объявлены внутри функции), по сравнению с NES 3.6. Соответственно, рекомендуется минимизировать использование глобальных переменных (переменных между тэгами и ) и переписать приложения для использования функций там, где это возможно. Это значительно повысит производительность приложения.

Если файлы HTML и JavaScript содержат серверный JavaScript, Вы затем компилируете их в единый исполняемый файл приложения JavaScript. Этот файл называется web-файлом и имеет расширение .web . Компилятор приложений JavaScript развёртывает HTML-код в платформонезависимые байт-коды, разбирая и компилируя операторы серверного JavaScript.

Наконец, Вы публикуете Ваше приложение на Вашем web-сервере и используете JavaScript Application Manager для инсталяции и запуска приложения, чтобы пользователи могли получить к нему доступ.

На этапе прогона, когда клиент запрашивает страницу приложения серверного JavaScript, машина выполнения локализует представление этого файла в web-файле приложения. Она запускает весь найденный серверный код и создаёт HTML-страницу для отправки клиенту. Эта страница может содержать как обычные тэги HTML, так и операторы клиентского JavaScript. Весь серверный код запускается на сервере до отправки страницы клиенту и до выполнения любого HTML или клиентского JavaScript. Соответственно, Ваш серверный код не может использовать клиентские объекты, так же как и клиентский код не может использовать серверные объекты.

Системные Требования

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

Среда разработки JavaScript состоит из:

  • Утилит для авторизации и компиляции приложений JavaScript. Эти утилиты обычно находятся на машине разработчика.
  • Машины разработчика с web-сервером для запуска приложений JavaScript, находящихся в стадии разработки.
  • Машины публикации с web-сервером для публикации разработанных приложений. Конечные пользователи осуществляют доступ к приложениям, находящимся на этом сервере.
  • Браузер с возможностью выполнения JavaScript, такой как Netscape Navigator, входящий в состав Netscape Communicator.
  • Компилятор приложений JavaScript, такой как компилятор web-серверов Netscape.
  • Редактор, такой как Emacs или Notepad.

Публикация и машины публикации требуют наличия следующего программного обеспечения:

  • Web-сервера;
  • Машины выполнения JavaScript, такой как машина web-серверов Netscape.
  • Возможности конфигурирования Вашего сервера для работы приложений JavaScript, как это сделано в JavaScript Application Manager, поставляемом вместе с web-серверами Netscape.

Кроме того, если ваше приложение использует JavaScript-службу LiveWire Database Service, Вам понадобится:

  • Программа — сервер реляционных БД на Вашей машине-сервере БД. См. документацию вашего сервера БД. В некоторых случаях Вам понадобится установить web-сервер и сервер БД на одной машине. О специфических требованиях серверного JavaScript см. Главу 10, «Конфигурирование Базы Данных.»
  • Клиент БД и сетевое программное обеспечение на машине Вашего web-сервера. Если Вы используете одну машину и как сервер БД, и как web-сервер, типичное клиентское обеспечение БД как правило уже установлено при установке сервера БД. В противном случае Вам нужно удостовериться, что клиент БД установлен на той же машине, что и web-сервер, чтобы можно было иметь доступ к БД как клиент. О требованиях к клиентскому программному обеспечению см. дополнительно документацию поставщика БД.

Информация Конфигурации

В этом разделе рассматривается информация конфигурации для использования серверного JavaScript. Дополнительно о настройке БД для работы с сервисом LiveWire Database Service см. Главу 10, «Конфигурирование Базы Данных.»

Подключение Серверного JavaScript

Чтобы запускать приложения JavaScript на Вашем сервере, Вы обязаны подключить машину выполнения JavaScript в вашем Server Manager, щёлкнув Programs, а затем выбрав серверный JavaScript. После появления промпта «Activate the JavaScript application environment/Активизировать среду приложений JavaScript ?» выберите Yes и щёлкните OK. У Вас спросят также об ограничении доступа к Application Manager. Дополнительно см. «Защита Application Manager’а.»

ПРИМЕЧАНИЕ: Если Вы не подключите машину выполнения JavaScript, приложения JavaScript не смогут запускаться на этом сервере.

Чтобы использовать и сервлеты, и LiveWire, Вам необходимо подключить серверный JavaScript до подключения Java. Оба могут быть подключены через использование меню программ Administration Server’а. Если Вы модифицируете путь к классам/classpath в obj.conf , Ваши изменения будут утеряны, если Вы подключите/отключите серверный JavaScript или Java из программного меню Administration Server’а. Альтернативой редактирования директивы classpath в obj.conf является установка переменной окружения CLASSPATH в Unix или установка переменной CLASSPATH в установках System в Windows NT. Если Вам нужно редактировать obj.conf непосредственно, сохраните первоначальный файл на всякий случай. В Enterprise Server 4.0 Вы должны добавить CLASSPATH info в файлы конфигурации JVM ( jvm12.conf для Solaris и NT) через интерфейс Enterprise Administration Server.

Как только Вы активируете среду приложений JavaScript, Вы обязаны остановить и рестартовать Ваш web-сервер, чтобы ассоциированные переменные окружения начали действовать. Если этого не сделать, приложения JavaScript, использующие службу LiveWire Database Service, работать не будут.

Защита Application Manager’а

Application Manager предоставляет контроль над приложениями JavaScript. В связи с его особыми возможностями Вы должны защитить его от неавторизованного доступа. Если Вы не ограничиваете доступ к Application Manager’у, любой может добавлять, удалять, изменять, стартовать и останавливать приложения на Вашем сервере. Это, естественно, может привести к нежелательным последствиям.

Вы (разработчик приложений на JavaScript) должны иметь права доступа для использования Application Manager’а на сервере разработчика, так как Вы используете его для работы с приложением при разработке. Администратор Вашего web-сервера, однако, может не предоставить Вам таких прав на сервере разработчика.

Если Вы подключите машину выполнения JavaScript в Server Manager’е, промпт спросит Вас, ограничивать ли доступ к Application Manager’у. Выберите Yes и щёлкните OK. (Yes — по умолчанию.) После этого любой, кто попытается получить доступ к Application Manager’у, обязан будет ввести имя пользователя и пароль Server Manager’а, чтобы получить возможность использовать Application Manager и приложение-образец dbadmin . Дополнительно см. руководство администратора для Вашего web-сервера.

Если Ваш сервер не использует Secure Sockets Layer (SSL), имя пользователя и пароль для Application Manager’а передаются по сети в некодированном виде. Перехватив эти данные, можно получить доступ к Application Manager’у. Если Вы используете тот же самый пароль для Вашего сервера администратора, хакер получит также контроль и над этим сервером. Следовательно, можно рекомендовать не использовать Application Manager вне прокси-сервера, если Вы не используете SSL. О том, как подключить SSL к серверу, см. справочник администратора Вашего web-сервера.

Установки для LiveConnect

Чтобы использовать Java-классы в LiveConnect, Вам нужно установить CLASSPATH сервера. Полное описание этой процедуры дано в Programmer’s Guide to Servlets и в Netscape Enterprise Server Administrator’s Guide.

Локализация Компилятора

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

В системах Unix у Вас есть выбор способов изменения переменной окружения PATH . Можно добавить $NSHOME/bin/https/lib , где $NSHOME это директория, в которой установлен Ваш сервер. Поговорите с Вашим системным администратором о том, как это сделать.

Чтобы изменить системный путь NT, запустите Control Panel, найдите диалоговое окно System и установите переменную PATH в разделе Environment settings, включив в неё %NSHOME%\bin\https\bin , где NSHOME это директория, в которой установлен Ваш сервер.

Если вы переместили компилятор JavaScript-приложений в другое место, Вы обязаны добавить эту новую директорию в переменную PATH .

Оглавление | Назад | Вперёд | Индекс

Дата последнего обновления: 29 сентября 1999 г.

© Copyright ╘ 1999 Sun Microsystems, Inc. Некоторая часть Copyright ╘ 1999 Netscape Communications Corp. Все Права Зарезервированы.

Илон Маск рекомендует:  Нейрокомпьютерная техника персептронная представляемость
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL