Особенности программирования BeOS API Часть 3


Замечание мимоходом — снова об инструментах разработки

Во-первых, если у кого вдруг на системе еще нет ни BeIDE, ни BeBook ни компилятора С++ — все это можно сгрузить с bebits.com, из раздела «BeOS Personal Edition«, пакет называется BeOS R5 Development Tools(17.9 MB). Если сей линк не сработал, посмотрите внимательней, там довольно большой список зеркал. Архив надо распаковать в /boot/

Теперь про BeIDE. Это не компилятор, а интергрированная среда разработки, способная работать практически с любым компилятором (например с Java и Pascal). По умолчанию она заточена на компилятор gcc (всякие другие имена компиляторов, типа cc или g++, тоже работают, но представляют собой или линки или скрипты, исользующие gcc). Упоминавшийся в одном из комментариев компилятор от Metrowerk (mwcc) ныне присутствует только в версии для PowerPC, но не для x86.

Библиотеки располагаются в двух местах:

/boot/beos/system/lib/ (основные системные)

и

/boot/home/config/lib/ (дополнительные)

а в /boot/develop/lib/x86/

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

Заголовочные файлы располагаются в

/boot/develop/headers/

и

/boot/home/config/include/

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

set
или 
set | more
которая, среди прочего, выдаст вам значения
таких переменных, как: BEINCLUDES BELIBRARIES BE_CPLUS_COMPILER BE_C_COMPILER CPLUS_INCLUDE_PATH C_INCLUDE_PATH LIBRARY_PATH

впрочем, на начальном этапе, возможно, не все из них будут присутствовать в вашем списке.
BeBook после правильной распаковки пакета разработчика будет располагаться по адресу «/boot/beos/documentation/Be Book/index.html».

Считаем, что эту вашу проблему мы решили, теперь упомяну о моей — нынешний движок qube.ru не слишком приспособлен для ввода-вывода хорошо форматированного кода в статьях, так что с красивыми отступами у нас могут быть проблемы, так же, как может быть, и с прямым копирование кода из браузера в BeIDE.


Итак, в предыдущей части введения мы, наконец, успели сказать, что настоящая BeOS-программа должна содержать объект класса BApplication, а запускаться все это должно вызовом метода Run() класса BApplication.

Ну что ж, самое время для небольшого обещанного базара о классах и всем таком прочем. Знатоки ООП эту часть смело могут пропустить, хотя бы для того чтобы уберечь челюсть от повреждений в результате ухмылок. Единственно, что стоит для них упомянуть, так же как и для новичков — никакой другой возможности (эффективно) программировать в BeOS, кроме C++ OOП API на данный момент нету. Поскольку просто не существует другого API, кроме полноценного объектного под C++. Есть правда компилятор Basic, который транслирует Basic-код в C++, а последний потом компилируется нормальным образом, но такому способу недостает ни полноты, ни гибкости. Так же не хватает полноты и гибкости и для существующей версии Pascal (с до сих пор не законченной библиотекой оберток вокруг нативных вызовов Be C++ API).

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

Так что рекомендация писать на C++ в BeOS — это не дурная шутка, вроде MFC, и не удачный прикол, вроде OWL и VCL — а это то, из чего BeOS сама сделана, снизу доверху, за исключением (частей)ядра и (частей) драйверов.

Впрочем, те, кто не специалист в ООП, тоже могут пропустить это сжатое и слегка сумбурное изложение, а вместо этого в спокойной обстановке просмотреть Обзор Объектно-Ориентированного Программирования..

Классы и объекты, отступление первое

    Хаотичное программирование a-la GOTO/BASIC и даже классическое структурное-процедурное программирование сильно напоминают один анекдот, про технологическую карту на советском авиазаводе, где пораженному новичку в сборочном цехе неожиданно предстало нечто, гораздо более напоминающее паравоз, а не истребитель.

    В ответ ветеран производства ткнул его носом в последнюю инструкцию на карте: «До окончательного вида изделие довести рашпилем».

    Объектное же программирование больше напоминает ситуацию в западном автомобильно производстве, когда многочисленные модели Seat, Skoda, VW — всего лишь вариации на тему относительно небольшой линейки шасси и прочих компонент.

    Что же такое класс? Это упакованная в одно целое коллекция процедур, функций и (структур) данных.
    Все эти функции по большей части предназначены для работы с данными, упрятанными внутри этого самого класса. В некотором смысле класс — это развитие понятия структур из языка C. Но просто собрать это все вместе каким-то образом — невеликое достижение, и толку для программера от этого было бы чуть. Примерно, как от способности копипэйстить свой и чужой код из старых программ:)

    Главное качество классов-объектов для программиста-«лентяя» — возможность делать из существующих объектов, НЕ ТРОГАЯ (и часто вообще не имея доступа к) код этого объекта, свой собственный прекрасных объект всего лишь парой легких мазков.

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

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

    К примеру, в заголовочном файле KrutojeOkno.h у нас будет строчка c таким куском:

    class KrutojeOkno : public BWindow

    Таким элементарным способом мы создаем (объявляем) совершенно новый класс (как это происходит — забота компилятора, а не наша:), но который, при этом, независимо от того, как мы его обвесим причиндалами в дальнейшем, будет обладать автоматически всеми свойствами нормального BeOS-окошка (класс BWindow).

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

    По научному этот трюк называется наследование, а по забугорному — inheritance.

    Естественно, что наследуются и всякие полезные фунции-методы класса-родителя (для этого в языке С++ требуется, чтобы в объявлении было слово public перед названием родительского класса).

    В нашем случае, это, например, Zoom(), Minimize(), SetTitle().

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

    KrutojeOkno->SetTitle(«Eto mojo pervoje okno!»);

    Те, кто пытался на ассемблере или даже в BASIC для DOS написать программульку, рисующую рамку, в которой точка бегала бы за курсором, должны представлять себе, что это самое окно, которое BWindow — не фунт изюма. Кода всяческого там внутри тьма — но нам-то какое до этого дело?

    Например до того, где и как хранится название/титул окна — в char title[], или в AnsiString WindowName. Все знать — это не знать ничего, поскольку невозможно.

    Для наших целей достоточно уметь установить название (KrutojeOkno->SetTitle()) или его узнать (nazvanije = KrutojeOkno->Title()). То же самое с механизмом изменения размера окна — что там внутри и как происходит, как называются переменные, хранящие эти размеры, какие при этом сообщения бегают между окном и сервером приложений — не наше дело. Наше дело — уметь установить нужный нам размер окна — KrutojeOkno->ResizeTo(ширина, высота), или узнать нынешние размеры —

ramka = KrutojeOkno->Frame();

Такое вот отсекание лишних для прикладного программиста сущностей методом упрятывания с глаз долой и называется инкапсуляцией (encapsualtion).

Идея термина понятна — все, что не должно путаться под ногами-руками, как бы засовывается в непрозрачную капсулу:)

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

Многие моджахеды от ООП вообще считают, например, что никакие переменные класса не могут быть доступны извне «напрямую». Например, если у нас есть класс точки Point (состоящий из X и Y), то за такое его воплощение, где можно написать Point.X = 0, моджахеды эти предлагают отрезать половину седалища и убивать на месте методом скармливания тонны овсянки без соли. По их мнению, право на жизнь имеет только такая конструкция Rect.SetX(0). Впрочем, OOП-языки — это такая мощная штука, которая позволяет удовлетворить и правых и левых, например, когда вы пишете Point.X = 0 — на самом то деле может вызываться целая куча методов, которые, например, проверяют, допустимый ли это X и когда вы последний раз чистили зубы.

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

class KrutojeOkno : public BWindow
{
BButton* GlavnajaKrasnajaKnopka;
}

Таким вот простым способом мы утерли нос ребятам из Be Inc — в нашем окошке кроме глупых рамки и желтой полоски будет существовать еще и отличная Главная Кнопка.

Ясно конечно, что все не совсем так просто — эту кнопку надо как-то инициализировать и пришпандорить к окну, а может даже заставить что-то делать — но это уже другая история. Не очень страшная, впрочем.

Да, тут подошло время традиционного объяснения различия между словами класс и объект (класса). За дальнейшее объяснение экстремисты и пуристы могут меня и замочить, но я смелый, когда надо, чтоб народу было понятнее.
Класс — это заготовка, шаблон, мертвая последовательность байт в библиотеке. Объектом класс становится, когда наполняется жизнью — то есть когда запускается программа, выделяется место в памяти и происходит инициализация этого ранее мертвого кода и лежачих данных. Опять же по традиции, во всяческих пособиях для уменьшения словофлудия заместо обоих слов обычно говорят просто — класс! А там уж из текста обычно понятно, о чем речь.

Еще один столп, на котором прочно устроилось ООП — это полиморфизм (polymorphism).

(Попутно будет к месту упомянуть и т.н. перегрузку (overloading)

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

Например, если мы пишем Ekran1 = Ekran2, где оба члена выражения происходят от класса BBitmap (по сути — трехмерный массив байтов) — оператор «=» делает за сценой совсем не то же, когда мы присваиваем одно целое другому (int x, y; x = y;)

ООП-языки позволяют вам создавать свои определения давно закомых значков операторов, всяких «+», «-«, «=», подобный трюк и называется overloading, но рассказ об этом явно лежит за рамками «Курса начинающего пчеловода».)

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

int Linija(int x1, int y1); - чертит линию
от текущего положения (пера) до точки x1,y1. int Linija(int x0, int y0, int x1, int y1);
- чертит линию от x0,y0 до x1,y1. и где-то в теле программы у вас есть код для двух функций. int Linija(int x1, int y1) { DrawLine(x1, y1); } и int Linija(int x0, int y0, int x1, int y1) { MovePenTo(x0, y0); DrawLine(x1, y1); }

В программе вы можете вызвать Linija() с думя или четырьмя параметрами, а уж забота компилятора — как раз по числу параметров решить, какая версия будет вызываться.

Другой способ использовать одно и то же имя для разных целей — это виртуальные (virtual) методы. КРАЙНЕ ВАЖНЫЙ для BeOS-программирования, и, несмотря на грозное и загадочное звучание — весьма простой способ. Важный — потому что практически вся обработка событий и сообщений в BeOS, включая рисование, производится с использованием виртуальных методов, а просто — потому что это просто надо привыкнуть:)

Суть дела тут вот в чем, применительно к проблемам BeOS-программирования. Если перед объявлением любой функции класса стоит слово virtual,

например:

class KrutojeOkno : public BWindow
{
....
virtual int KnopkaNazhata();
...
}

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

class PrjamojeOkno : public KrutojeOkno
{
....

virtual int KnopkaNazhata();
...
}

при этом с совершенно другим кодом.

Если бы мы так не сделали, то вызов PrjamojeOkno->KnopkaNazhata(); на самом деле бы запускал старую функцию, из класса KrutojeOkno, по праву наследования.

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

В стандартном «системном» классе есть виртуальная функция
MouseDown(int x, int y).

Причем в этом самом классе — она пустая, по сути — заготовка.

virtual void MouseDown(int x, int y)
{
}

то есть не делает ничего, НО! — эта функция автоматически вызывается, когда пользователь щелкнул мышкой в окне. Причем вызывается с «правильными» параметрами — местом, где щелкнули.

Грех не использовать такую простую, но ценную штуку в собственном классе — а как же еще мы может поймать мышиный щелчок в нашей программе? Но при этом мы можем снабдить ее осмысленным кодом:

(отрывок заголовочного файла — здесь мы объявляем, что у нас будет своя версия этой функции)

class VidVOkne : public BView
{
...
virtual void MouseDown(int x, int y, int buttons);
...
}
----------------------
(файл с кодом - здесь мы расписываем, 
что наша версия делает) virtual void VidVOkne :: MouseDown(int x, int y) { DrawLine(x, y); }

Ну вот, просто, но уже действенно — при нажатии на кнопку мыши в нашем окне будет рисоваться линия к месту щелчка. Для новичков в С++ на этом примере поясню, что когда вы объявляете класс, например внутри заголовочного *.h-файла (то есть описываете схематически, что у него внутри) — переменные и методы пишутся безо всяких «добавок», но когда уже идет код, то есть как методы этого класса «сделаны», например в *.cpp файле — перед собственным именем метода добавляется спереди название класса, к которому этом метод принадлежит — VidVOkne :: MouseDown.

Ну а для тех, кто еще до сих пор в танке — фраза

class VidVOkne : public BView

означает, что наш класс VidVOkne будет наследником (со всеми потрохами) класса BView.

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

Теперь возвращаемся непосредственно к BeOS — API. На данный момент, чтобы создать и запустить что-либо видимое, нам не хватает пояснений по классу BWindow.

В тексте мы его уже упоминали, в связи с нашим классом KrutojeOkno, но безо всяких пояснений.
Теперь вроде с пояснениями будет полегче, когда я скажу, что BWindow является, как и BApplication, наследником классов BLooper BHandler, соответственно), но боюсь, что еще не все новички-пчеловоды переварили порцию про классы и наследование. Поэтом на сей раз отмечу только факт, важный и для новичков и для гуру —

В самом BWindow НЕВОЗМОЖНО РИСОВАТЬ!!!.

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

Предназначение BWindow, кроме создания пустой рамки на экране:

1)Служить вместилищем-контейнером-родителем (parent) для других объектов-детей (child, children), которые и будут рисовать-петь-плясать и приносить нам кофе с утра в постель.

NB!!! BWindow не может быть добавлен к другому BWindow в качестве ребенка — окна в окне в BeOS не бывает !!!

2)Служить посредником-связником между этими объектами-детьми и системой. То есть ApplicationServer, InputServer и другими системными компонентами.

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

Для того, чтобы обеспечить как рисование, так и работу с сообщениями, в Application Server (см. часть 1 «Введения») создается «близнец» КАЖДОГО окна. Автоматически и невидимо для программиста. Впрочем, можно сказать, когда это происходит — в тот момент, когда в первый раз вызывается метод Show() класса BWindow.

Вот с ним-то, с этим близнецом на самом деле BWindow и общается, незаметно ни для пользователя, ни для программиста.

Впрочем, наблюдать этот факт крайне просто — сгрузите с Bebits программу ProcessController (если вы такой чудак, что еще не поставили ее), запустите. Поместите ее в Deskbar или на рабочий стол, щелкните на иконке и пойдите в раздел «Kill, Debug or Change Priority», там найдите app_server, плавно наведите на него курсор и, в раскрывшемся меню, вы увидите некоторое количество строк с «w::» в начале. Внимательно посмотрев, можно осознать, что все эти строчки с «w::» имеют соответствия на ваших рабочих столах, в виде открытых окон разных программ. Причем, если вы, в меню предыдущего уровня, наведете курсор не на app_server, а на какую-либо программу, то увидите, что там у каждой программы тоже прописаны свои соответствия этим окнам.

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

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


При использовании материалов сайта ссылка обязательна! (Copyright by www.avs-info.ru 2006)