Кто знает язык C++ нужно пояснить что означает каждая строчка програмы
Опишите что означает каждая строчка и что она делает!
#include
#pragma hdrstop
void __fastcall TForm1::N3Click(TObject *Sender)
<
OpenDialog2->Execute();
Memo1->Lines->Clear();
Memo1->Lines->LoadFromFile(OpenDialog2->FileName);
Form1->Caption=OpenDialog2->FileName;
>
//—————————————————————————
void __fastcall TForm1::N4Click(TObject *Sender)
<
Memo1->Lines->SaveToFile(OpenDialog2->FileName);
Memo1->Lines->LoadFromFile(OpenDialog2->FileName);
>
//—————————————————————————
void __fastcall TForm1::CP8661Click(TObject *Sender)
<
#include //загрузка стандартной библиотеки С++ Билдер
#pragma hdrstop// тоже стандартная строка, создается автоматом.
void __fastcall TForm1::N5Click(TObject *Sender)
<
SaveDialog1->Execute();//включение диалога «сохранить файл»
Memo1->Lines->SaveToFile(SaveDialog1->FileName);// сохранение линий в выбранный файл
>
//—————————————————————————
void __fastcall TForm1::P12511Click(TObject *Sender)
<
char *k=new char[100000]; // создание одномерного массива из кучи элементов
OemToChar(Memo1->Text.c_str(),k); // загрузка нулевых значений в компонент текста
Memo1->Text=(AnsiString)k; // преобразование текста
>
//—————————————————————————
void __fastcall TForm1::CP8661Click(TObject *Sender)
<
Структура файлов модулей форм
СТРУКТУРА ГЛАВНОГО ФАЙЛА ПРОЕКТА
В процессе проектирования вами приложения C++Builder автоматически создает коды головного файла проекта, коды отдельных модулей и коды их заголовочных файлов.
Головной файл содержит функцию WinMain (main– для консольного). Обычно мы его не видим и не трогаем. Для просмотра: меню Project| ViewSource
// макросы, подключающие файлы ресурсов и форм
WINAPI WinMain (HINSTANCE, HINSTANCE, LPSTR, int)
catch (Exception &exception)
Начинается файл головного модуля строками, первый символ которых — «#». С этого символа начинаются директивы препроцессора. Среди них наиболее важны для вас директивы #include.Эти директивы подключают в данный файл тексты указанных в них файлов. В частности, подобными директивами включаются в текст заголовочные файлы. Например, директива #include подключает заголовочный файл vcl.h,содержащий объявления, используемые в библиотеке визуальных компонентов C++Builder.
После директив препроцессора в файле размещены предложения USERESи USEFORM.Это макросы, используемые для подключения к проекту файлов форм, ресурсов и др. Препроцессор развернет эти макросы в соответствующий код. В данном случае вы можете видеть два макроса USEFORM,подключающих формы. C+4-Builder автоматически формирует соответствующее предложение с макросом USEFORMдля каждой формы, вносимой вами в проект. Первый параметр макроса содержит имя файла модуля, соответствующего форме (например, «Unitl.cpp»), а второй параметр — имя формы.
Последний параметр определяет окно приложения. Этот параметр может в дальнейшем передаваться в функцию ShowWindow.
В головной функции main, используемой в консольных приложениях тоже имеются параметры, дающие доступ к элементам командной строки. Впрочем, эти параметры и в WinMain, и в mainиспользуются достаточно редко.
После заголовка функции WinMainследует ее тело, заключенное в фигурные скобки.
Первый выполняемый оператор тела функции — Application—>Initializeинициализирует объекты компонентов данного приложения.
Последующие операторы Application—>CreateFormсоздают объекты соответствующих форм. Формы создаются в той последовательности, в которой следуют эти операторы. Первая из создаваемых форм является главной.
Последний оператор — Application—>Runначинает собственно выполнение программы. После этого оператора программа ждет соответствующих событий, которые и управляют ее ходом.
Перечисленные операторы тела функции WinMainзаключены в блок try, после которого следует блок catch.Это структура, связанная с обработкой так называемых исключений — аварийных ситуаций, возникающих при работе программы. Если такая аварийная ситуация возникнет, то будут выполнены операторы, расположенные в блоке catch.По умолчанию в этом блоке расположен стандартный обработчик исключений с помощью функции Application—>ShowException.
Все описанные выше операторы головного файла приложения заносятся в него автоматически в процессе проектирования вами приложения. Например, при добавлении в проект новой формы в файл автоматически вставляются соответствующее предложение USEFORMи оператор Application—>CreateForm,создающий форму. Так что обычно ничего в головном файле изменять не надо и даже нет необходимости его смотреть.
Имя головного файла проекта по умолчанию дается стандартное: Projectl, Project2и т.п. Это же имя будет и у выполняемого модуля вашей программы. Так что желательно изменить имя по умолчанию. Для этого достаточно сохранить головной файл проекта под соответствующим именем.
Каждый такой модуль состоит из двух файлов: заголовочного, содержащего описание класса формы, и файла реализации.
Ниже приведены тексты этих файлов модуля формы, на которой размещена одна метка (компонент типа TLabel)и одна кнопка (компонент типа TButton).Подробные комментарии в этом тексте поясняют, куда и что в этот код вы можете добавлять.
С++ Builder: как ускорить компиляцию с помощью предкомпилированных заголовков
Принцип действия предкомпилированных заголовков
Для управления предкомпилированными предназначена директива компилятора #pragma hdrstop. Все заголовочные файлы, включенные до этой директивы, помещаются в один образ, например:
Таким образом, для повторного использования предкомпилированного заголовка необходимо выполнение двух условий:
Сократить затраты на компиляцию стандартных заголовков до минимума можно только в том случае, если скомпилировать один образ, содержащий все стандартные заголовки, необходимые для проекта. Для этого нужно, чтобы:
Выполнить эти условия достаточно просто, для этого в начало каждого cpp-файла необходимо поместить следующие строки:
Из-за наличия этих констант включить math.hpp в файл pch.h нельзя.
Кстати, С++ Builder при добавлении новых модулей в проект реализует описанную стратегию управления предкомпилированными заголовками. Например, при создании нового приложения, файл Unit1.cpp будет таким:
Если посмотреть на текст vcl.h, то можно увидеть, что он является оболочкой для включения большого числа других стандартных заголовочных файлов.
Управлять составом включаемых в vcl.h заголовков можно с помощью специальных символов (INC_VCLDB_HEADERS, INC_VCLEXT_HEADERS и др.). В моей версии pch.h эти символы определяются с помощью #define до включения vcl.h, что приводит к увеличению числа включаемых файлов.
Как в существующем проекте перейти к использованию предкомпилированных заголовков
Даже в большом проекте перейти к использованию предкомпилированных заголовков достаточно просто.
После этого в начало каждого cpp-модуля необходимо вставить 2 строки:
Все ранее включенные заголовочные файлы остаются на своих местах, их удалять не надо. Например:
Так как во всех стандартных заголовках применяются стражи повторного включения, то повторное их упоминание не влечет за собой повторного включения.
Теоретически можно еще больше повысить эффективность компиляции, если включить в pch.h не только стандартные, но и все пользовательские заголовочные файлы. Практически, так как пользовательские заголовки меняются достаточно часто, это может повлечь за собой частую перекомпиляцию pch.h, что негативно скажется на времени компиляции. Кроме того, пользовательские заголовки обычно не бывают очень большими и компилируются очень быстро. Поэтому включать их pch.h не целесообразно.
Как проверить, что предкомпилированные заголовки используются эффективно
При добавлении в проект новых файлов нужно не забывать включать в них pch.h, иначе для них не будет использован общий предкомпилированный образ. Такая же ситуация может возникнуть, если в каком-то модуле включаются стандартные заголовки, которые не вошли в pch.h. Для того, чтобы отследить такие файлы, есть несколько способов:
#ifndef PCH_H #define PCH_H #define INC_VCLDB_HEADERS #define INC_VCLEXT_HEADERS #include /* Все, что подключается предыдущими 3-мя строчками // Core (minimal) Delphi RTL headers #include #include #include #include #include #include // Core (minimal) VCL headers #if defined(INC_VCL) #include #include #include
Include vcl h что это
Вот только не надо говорить, что там ничего про это нет. Все там есть, ты просто ленишься думать самостоятельно и хочешь, чтобы тебе все на блюдечке поднесли да разжевали.
Директива #pragma имеет следующий синтаксис:
и вызывает действия, зависящие от указанной опции. Список возможных опций вы можете найти во встроенной справке C++Builder. Он довольно обширен и связан с различными режимами работы препроцессора.
Пример директивы #pragma вы можете видеть в любом модуле своего проекта. Первые две строки файла любого модуля имеют вид:
#include
#pragma hdrstop
Здесь использована опция hdrstop. Она связана с особенностью работы препроцессора, производительность которого существенно повышается, если учитывается, что некоторое количество заголовочных файлов общие для всех модулей. Директива #pragma hdrstop указывает компилятору конец списка таких общих файлов. Так что надо следить за тем, чтобы не добавлять перед этой директивой включение каких-то заголовочных файлов, не являющихся общими для других модулей.
В файлах модулей вы можете еще увидеть две директивы #pragma:
#pragma package(smart_init)
#pragma resource «*.dfm»
Например, директива #include подключает заголовочный файл vcl.h, содержащий объявления, используемые в библиотеке визуальных компонентов C++Builder.
Следующая директива включает файл Unit1.h, который ищется прежде всего в каталоге, в котором расположен файл, содержащий данную директиву:
Так объявляется указатель с именем Form1 на объект класса TForm1, в дальнейшем он может использоваться для доступа к свойствам и методам формы с именем «Form1».
Так начинается определение обработчика события OnClick для компонента типа TEdit с именем «Edit1», принадлежащего форме с именем «Form1».
Событие соответствует щелчку мыши на компоненте и некоторым другим действиям пользователя
typedef void (__closure *TNotifyEvent)(
System::TObject* Sender);
__property Classes::TNotifyEvent OnClick
В общем создали мы проект. Смотрим. Первым делом в глаза бросается обширный комментарий, общий смысл которого заключается в том, что при использовании функций, которые экспортируют описания функций, среди параметров которых встречается AnsiString, исходник приложения, которое использует такое DLL, должен быть скомпилирован с использованием библиотеки MEMMGR.LIB. Ну мы особо выкаблучиваться не будем, и строковые параметры будем передавать как char*. Обратите внимание, что ничто не запрещает использование строк AnsiString внутри кода DLL. Не забудьте только прокомпилировать проект в режиме Release и со снятой галочкой Use Dynamic RTL.
Так вот. Продолжаем. Пишем код какой-нибудь функции и какой-нибудь завалящий класс в наш юнит. Обратите внимание, что заголовочный файл по умолчанию не создается, посему при открытии Open Source/Header File нам предлагается создать новый файл. Что мы и делаем, а затем сохраняем его под расширением *.h. Соответственно имеем исходники:
Комментарий я с Вашего позволения выкинул. Теперь по поводу заголовочного файла. Все экспортируемые функции при сборке должны иметь спецификатор _export или __declspec(dllexport), а импортируемые _import или __declspec(dllimport). То есть если файл заголовка используется самим DLL, то перед функциями должен стоять один из пары первых спецификаторов, а если использующим DLL приложением, то один из пары вторых. Проще всегод это сделать так:
Теперь собираем приложение, присоединяем получившийся *.lib файл к проекту приложения, добавлям:
. в главный файл, собираем, запускаем и пробуем.
В следующем шаге мы рассмотрим возможность использования файлов библиотек напрямую.
