Цитата(Alla_student @ Oct 25 2012, 05:48)
По хидерам - это чтобы переменные из паскалевской программы использовать в C билдера?!
Нет, это лишь для того, чтобы Сишная часть программы могла вызывать функции из паскалевской части программы.
Ведь после того, как каждая из частей откомпилируется своим компилятором, получатся достаточно обезличенные объектные модули (*.obj), которые скручивает в одну программу линкер. Потому и надо, чтобы вызовы из одного модуля соответствовали входу другого. Когда всё на одном языке пишешь, о таких вещах обычно не задумываешься, т.к. компилятор компилит все модули по одинаковым правилам. А когда модули разного типа, то это приходится учитывать. Кстати, точно такого же плана проблема вызывать из C++ функции, написанные на обычном C (который ++) или ассемблере. В последнем случае это тоже делается в хидере при объявлении функции. Например, вот так:
Код
extern "C" {
double sum_d(double *d, int length);
}
После такого объвления прототипа функции компилятор поймет, как к этой функции сделать правильное обращение.
Для паскалевского случая у Билдера тоже есть специальный квалификатор __pascal, который требуется лишь приписать спереди у функции, чтобы компилятор оформил к ней вызов по паскалевским правилам. Например:
Код
double __pascal sum_d(double *d, int length);
после этого она воспринимается как паскалевская, и обращение к ней будет соответствующее.
Кроме того, на языке C объявление прототипа функции обязательно, т.е. еще до своего вызова функция должна быть объявлена (за исключением лишь тех случаев, когда тело самой функции предшествует в тексте своему вызову). И это отнюдь на обременительное, а очень полезное средство избежать многих ошибок, связанных типом и порядком следования аргументов. А чтобы все модули программы имели единообразное представление о функциях, их прототипы выносятся в отдельный файл - хидер, который инклюдится в начало кода как тех модулей, которые функцией пользуются, так и того модуля, который содержит тело этой функции. Уж тогда-то единообразие гарантируется. К тому же хидер служит замечательной подсказкой про то, в каком порядке у вызываемой функции следуют аргументы.
Но когда программа двуязычна, то единый хидер обычно всюду не подсунешь, и тут приходится брать на себя заботу о соответствии. Например, у меня с читалкой TIFF-картинок был более сложный случай. На Паскале объявление класса TTIFFBitMap было таким:
Код
TTIFFBitMap = class(TBitmap)
public
constructor Create; override;
destructor Destroy; override;
<... много чего пропущено ...>
procedure LoadFromTifFile(FileName:String);
end;
а для Сишной программы я написала вот такой пототип того же самого класса:
Код
class PASCALIMPLEMENTATION TTIFFBitMap : public Graphics::TBitmap
{
public:
virtual TTIFFBitMap();
virtual ~TTIFFBitMap();
void __fastcall LoadFromTifFile(AnsiString FileName);
};
Сходство между ними очевидно. А мне была нужна от того класса функция LoadFromTifFile(...), которая читала картинки с диска и заполняла ими Bitmap. Чаще всего в межмодульном вызове участвует лишь небольшое число функций, им-то и заводим хидеры на Сишный лад (у Паскаля тоже есть свои хидеры *.hpp, которые для С не годятся). Как видите, со стороны С я объявила класс TTIFFBitMap урезанным, опустив объявление тех его функций, которыми сишная часть программы не пользуется. А паскалевская сторона не может этим самоуправством возмутиться
, т.к. Сишного хидера не видит.
Цитата(Alla_student @ Oct 25 2012, 05:48)
По Rs232 забыла спросить, где пример и/или компонент хороший есть?
В этом аспекте я целиком солидарна с выше опубликованным мнением kolisnichenko_r - не нужно в случае RS232 пользоваться классами, а следует использовать базовые функции Windows API. Тем более что COM-порт (он же RS232) выглядит в системе, как файловый девайс. Т.е. из него читают и пишут в него точно теми же самыми средствами, кто и с открытым файлом на диске. Некоторую проблему составляет задание скорости обмена и шевеление контрольными линиями, но при работе с классом эта задача не станет проще - все равно придется разбираться с управлением наряду с тем, чтобы еще понять, как этот класс работает
. Так уж здесь лучше без всяких классов. По крайней мере поймете, что Windows может сделать со своим портом, а чего не может, вместо того, чтобы надеяться на всемогущество класса, написанного неизвестно кем.
К тому же как на этом форуме, так и на других, ему подобных, работа с СОМ-портом через Windows API обсасывалась несчетное число раз. И что радует, такая реализация выглядит почти единообразно не всех языках.
Выбор IDE для написания оконных программ на Си под Windows
Oct 14 2012, 07:13
