Структури файлів в C + + Builder

Наталія Єлманова, Центр Інформаційних Технологій

Структура файлу проекту

Для кожного додатка C + + Builder створюється один файл проекту, один make-файл і один файл ресурсів. Файл проекту генерується при виборі пункту меню File/New Application. Спочатку файлу проекту присвоюється за замовчуванням ім'я Project1.cpp. Якщо в процесі розробки програми додаються форми і модулі, C + + Builder оновлює файл проекту.

Для переглянути файл проекту слід вибрати пункт меню View/Project Source. Ця операція виконає завантаження вихідного тексту файла проекту в редактор коду (рис. 1).

Рис. 1. Перегляд файлу проекту в редакторі коду

Файл проекту має таку ж структуру, як і файл модуля. Подібно до файлу модуля, це назва файлу вихідного коду на мові C + +, який компілюється з іншими файлами при створення виконавчого файлу.

В файлі проекту є певний набір ключових елементів:

Директива препроцесора # include призначена для включення в текст проекту заголовки, що посилається на описи класів бібліотеки компонентів.

Директива препроцесора # pragma hrdstop призначена для обмеження списку заголовків файлів, доступних для попередньої компіляції.

Директива USEFORM повідомляє, які модулі і форми використовуються у проекті.

директива USERES компілятора приєднує файли ресурсів до виконуваному файлу. При створенні проекту автоматично створюється файл ресурсів з розширенням *. res для зберігання курсорів, піктограми програми та ін

Application-> Initialize () Це твердження критично тільки у випадку, якщо програма є OLE automation-сервером. В інших випадках воно фактично нічого не робить.

Application-> CreateForm () Це твердження створює форму додатку. За замовчуванням, кожна форма в додатку має своє твердження CreateForm.

Application-> Run () Це твердження запускає програму (точніше, переводить його в стан очікування настання однієї з подій, на яке воно має реагувати).

Конструкція try ... catch використовується для коректного завершення програми у разі виникнення помилки при ініціалізації, створенні форм, запуску програми.

Структура make-файлу

Make-файл - Це текстовий файл, що містить макроси, директиви та інструкції по компіляції і складання проекту для утиліти make.exe. Відзначимо, що make-файл по суті нічим не відрізняється від звичайного знайомого користувачам С і С + + make-файлу. Він генерується автоматично при створенні проекту, і його вміст залежить від установок, зазначених програмістом в опціях проекту. Щоб побачити зміст make-файлу, слід вибрати пункт меню View/Project Makefile (рис. 2).

Рис. 2. Приклад структури make-файлу

Структура модуля

Модулі є основою для створення бібліотек та програм в C + + Builder. Модуль містить вихідний текст на мові C + + і спочатку представляє собою файл із розширенням *. CPP. Надалі кожен такий файл компілюється в Об'єктовий файл із розширенням *. OBJ. Об'єктні файли, у свою чергу, збираються компонувальником в виконуваний файл з розширенням *. EXE.

При додаванні до проекту нової форми генерується новий модуль. При додаванні модуля до проекту за допомогою вибору пункту меню File/New Unit створюється порожня структура модуля, до якої включено директиви: # include ; # pragma hdrstop; # include "Unit2.h"

Директива # include "Unit2.h" вказує на те, що в текст модуля повинен бути включений відповідний заголовки.

При створення модуля використовуються наступні правила:

Назва повинно бути унікальним. Два модуля з одним і тим же ім'ям не можуть використовуватися одночасно в одному і тому ж проекті.

Якщо модуль пов'язаний з формою, то ім'я вихідного файлу модуля і файлу форми (з розширенням *. dfm) повинні бути однаковими. При створенні обробника подій в інспектора об'єктів в тексті файлу модуля генерується шаблон функції, в який розробник повинен вводити код, що виконується при настанні оброблюваного події.

Структура h-файлу

h-файл генерується при створенні нового модуля. У ньому міститься інформація про дані і функції, які можна використовувати в модулі. h-файл для модуля, пов'язаного з формою, містить описи інтерфейсних елементів і інших компонентів цієї форми і обробників подій для них (тобто, в термінології об'єктно-орієнтованого програмування, опис класу форми). Такі опису автоматично додаються в h-файл при внесенні в форму нових компонентів або створення нових обробників подій. Іншими словами, у h-файлі міститься інтерфейс, а в самому модулі - реалізація.

Рис. 3. Приклад структури h-файлу

Примітка. Під час видалення з форми компонентів їх опису видаляються з h-файлу, а опису обробників подій зберігаються. При перейменування компонентів змінюються їхні опису в h-файлі, а також імена і описи обробників подій, згенеровані автоматично. Однак при цьому не змінюються посилання на ці компоненти і обробники подій, що використовуються в інших функціях, тому рекомендується перейменовувати компоненти й обробники подій одразу ж після їх створення, поки на них не з'явилися посилання.

Не рекомендується видаляти з модуля порожні функції (наприклад, випадково створені шаблони обробників подій). Вони не збільшать розмір файлу, що виконується, але їх видалення може призвести до неможливості заново згенерувати обробник події, якщо в цьому виникне необхідність.

Відзначимо, що в модулі можуть містити функції, не описані в h-файлі, однак видимість їх у цьому випадку обмежується даним модулем.

Всередині модуля функції можуть бути визначені і посилатися один на одного в довільному порядку. Якщо цей модуль посилається на інші форми і модулі, слід з допомогою директиви препроцесора # include включити в нього відповідний h-файл за допомогою пункту меню File/Include Unit Hdr ... . Після цього інтерфейсні елементи іншого модуля будуть доступні в даному модулі.

Файл форми

Форма є одним з найважливіших елементів програми C + + Builder. Процес редагування форми відбувається при додаванні до форми компонентів, зміні їх властивостей, створенні обробників подій.

Рис. 4. Структура файлу форми

Коли до проекту додається нова форма, створюються три окремих файлу:

Файл модуля (. cpp) - містять задану вихідний код, пов'язаний з формою.

h-файл (. h) - Містять задану опис класу форми, тобто описи містяться на формі компонентів і обробників подій.

Файл форми (. dfm) - двійковий файл, який містить відомості про опублікованих (тобто доступних в інспектора об'єктів) властивості компонентів, що містяться у формі. Двійковий файл форми містить інформацію, яка використовується для конструювання форми з компонентів, розташованих на ній. При додаванні компонента до форми та заголовки, і двійковий файл форми модифікуються. Під час редагування властивостей компонента в інспектора об'єктів ці зміни зберігаються в двійковому файлі форми.

Хоча в C + + Builder файл. dfm зберігається у двійковому форматі, його зміст можна переглянути за допомогою редактора коду. Для цього потрібно натиснути праву клавішу миші над формою і з контекстного меню форми вибрати пункт View as Text.

Відзначимо, що при вилученні будь-якого компоненту з форми в буфер обміну в останньому реально виявляється частина тестового подання файлу форми, що містить опис даного компоненту. У цьому можна переконатися, виконавши потім операцію вставки з буфера обміну в будь-якому текстовому редакторі. Модулі Delphi 2.0

C + + Builder створений на основі візуальної бібліотеки компонентів Borland Delphi, що стала за останні два роки дуже популярною серед розробників. З цієї причин цей продукт має спільну з Delphi бібліотеку класів, частина з яких залишилася написаної на Object Pascal. З цього випливає, що в додатках можна використовувати компоненти, створені для Delphi 2.0.

Однак сумісність з Delphi цим не вичерпується. У проектах C + + Builder можна використовувати не тільки бібліотеку компонентів Delphi, але і код, написаний на Object Pascal, а також форми і модулі Delphi. Ці можливості з'явилися завдяки включенню в С + + Builder обох компіляторів - С + + і Object Pascal.

Рис. 5. Типи файлів, що використовуються в проектах С + + Builder

В Відповідно до цього як частин проекту можуть бути використані модулі, написані на Object Pascal. У цьому можна переконатися, взявши форми якого-небудь з прикладів, створених в Delphi 2.0 і включивши їх в проект С + + Builder. Візьмемо як такого прикладу додаток Graphex з набору прикладів Delphi 2.0. Створимо новий проект, видалимо з нього створену за замовчуванням форму і додамо два модулі з програми Graphex - Graphwin.pas і Bmpdlg.pas.

Рис. 6. Додавання модулів Delphi до проекту.

Скомпіліруем проект. Можна переконатися в працездатності отриманого програми, запустивши і протестувавши його.

В разі використання форм Delphi до проекту додаються два файли - файл форми з розширенням *. dfm і файл модуля з розширенням *. pas. Опис класу форми міститься в самому модулі, отже, для цього не потрібен окремий файл заголовка.

Розглянемо більш докладно структуру модуля Delphi. В якості найпростішого прикладу наведемо структуру модуля, пов'язаного з формою, яка містить єдиний інтерфейсний елемент - кнопку закриття вікна: unit Unit1; interface uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs; type TForm1 = class (TForm) Button1: TButton; procedure Button1Click (Sender: TObject); private (Private declarations) public (Public declarations) end; var Form1: TForm1; implementation ($ R *. DFM) procedure TForm1.Button1Click (Sender: TObject); begin close; end; end.

Основними елементами модуля є:

Заголовок модуля - призначений для ідентифікації модуля і повинен бути унікальним для даного проекту. Чи збігається з ім'ям файлу з розширенням *. pas.

Секція інтерфейсу (починається зарезервованим словом interface). Секція інтерфейсу є місцем, де оголошуються константи, типи, змінні, процедури і * функції, які доступні для використання іншими програмними модулями. При оголошення процедур і функцій в секції інтерфейсу необхідними є тільки їх заголовки. Тіла, або реалізації, цих процедур і функцій розташовуються в секції реалізації.

Секція реалізації (починається зарезервованим словом implementation) містить процедури та функції, включаючи обробники подій. Оголошення обробників подій повинні бути присутніми в секції інтерфейсу. Крім цього, секція реалізації може мати додаткові процедури, функції та оголошення констант, типів і змінних, згадки про яких немає в секції інтерфейсу, але ці оголошення видимі лише в межах даного модуля.

Секції ініціалізації та завершення (починаються з зарезервованих слів initialization і finalization) - необов'язкові секції для розміщення операторів, що виконуються відповідно при запуску і завершенні програми. Пропозиція uses (необов'язкове) містить імена інших модулів, які використовуються даним модулем та може розташовуватися безпосередньо за ключовим словом interface і за ключовим словом implementation. Пропозиція uses робить секцію інтерфейсу інших модулів доступною в даному модулі.

Відзначимо, однак, що для створення нових модулів Delphi потрібна наявність Delphi. У С + + Builder їх можна тільки використовувати. Можливості редагування форм і модулів Delphi в С + + Builder істотно обмежені - допустимі тільки операції, не зачіпають секцію інтерфейсу модуля. Наприклад, можливо пересування інтерфейсних елементів у межах їх містять компонентів-контейнерів, зміна розмірів, копіювання в буфер обміну, але заборонено їх застосування або видалення. Можливі зміни всередині коду процедур і функцій, але заборонено додавання нових обробників подій.

* В термінології Pascal процедурами зазвичай називають функції і не повертають значень (зокрема, обробники подій). Єлманова Н.З., Кошель С.П. Вступ в Borland С + + Builder

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/