Главная

Особенности программирования 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 и код простейшей программы придется взяться в следующий раз.
Мозги–то у читателя не из хром–кобальта, могут и поизноситься от перегрузки, а нам, для полного счастья, еще не хватает пояснения–отступления про конструкторы–деструкторы, а также стеки и кучи.

До встречи:)

(С) Сергей Долгов, 2003

hello

г–н Долгов! откуда вы взяли SetTitle(«Eto mojo pervoje okno!»)? а как же “Hello word!!!” :))))

Чо заглохло,

Чо заглохло, чо заглохло… Голодные годы были, потому и заглохло! Восемь лет питаться эманациями Духа Беос — мало кто сможет. ;–)

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Allowed HTML tags: <a> <em> <i> <img> <strong> <b> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Подробнее о форматировании

CAPTCHA
Введите перечисленные символы, чтобы мы убедились, что вы не робот. Не требуется для зарегистрированных пользователей.
5
W
Y
5
3
B
Enter the code without spaces and pay attention to upper/lower case.