Выбор IDE для написания оконных программ на Си под Windows Опции

[Alt.F4]

Добрый день.
Никак не могу определиться с выбором IDE для написания оконных программ исключительно на Си под Windows.
Подскажите, пожалуйста, что выбрать для простой работы с формами?
Спасибо.

[kolisnichenko_r]

Работаю на C++ Builder 6.
Тестировал C++ Builder 2007, тяжело моей машинке его тянуть.
Для тех задач, которые предомной стоят вполне хватает 6.
Просто и понятно.

[Alla_student]

Хотела спросить, коль скоро:

1) Для Builder 6.0 или выше, есть примеры работы с базой SQL, насколько сложно?
2) Для Builder 6.0 есть пример работы с каким нибудь быстрым plot или chart компонентом и какой это комонент?
3) Есть для него же, компоненты LED, knobs, цифровых и LCD дисплеев, кроме известного IOcomp?
4) Насколько сложно исходный текст или проект Delphy переводить под Builder?
5) Подскажите хороший сайты по этим вопросам и обучению работы под Builder не перегруженный теорией?

[Xenia]

1) Для Builder 6.0 или выше, есть примеры работы с базой SQL, насколько сложно?

На этот вопрос затрудняюсь ответить, но полагаю, что при общении с любой базой требуется, прежде всего, знать язык ее запросов. А Builder 6.0 тут скорее посторонний.

2) Для Builder 6.0 есть пример работы с каким нибудь быстрым plot или chart компонентом и какой это комонент?

Да, объект TChart от TeeChart. Но и он здесь тоже в каком-то смысле посторонний.

3) Есть для него же, компоненты LED, knobs, цифровых и LCD дисплеев, кроме известного IOcomp?

У TeeChart'а так много всяких возможностей, что их невозможно упомнить. Посмотрите программы-демонстраторы: Tee7New.exe и Tee8New.exe (на сайте компании http://www.steema.com/products/teechart/de...iled_demos.html ). Там и другая наглядная агитация есть.

4) Насколько сложно исходный текст или проект Delphy переводить под Builder?

Я бы сказала, что сложно. Это зависит, в первую очередь от того, насколько хорошо вы знаете оба языка С++ и Pascal.
Однако под Билдером можно и паскалевские программы компилировать (в отдельных файлах проекта).
Например, я где-то нашла исходники чтения/распаковки рисунков в формате TIFF (новые Билдеры умеют их читать, а 6-ой еще не умел). Глянула в те исходники и даже не захотелось с ними разбираться - очень уж сложно и запутанно написано. Тогда я их прямо так живьем и пришпандорила к сишному проекту. И они там в окружении C++ файлов отлично компилируются. Только хидеры мне к ним сишные пришлось написать, но это совсем не сложно.

5) Подскажите хороший сайты по этим вопросам и обучению работы под Builder не перегруженный теорией?

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

[Alla_student]

...
Я бы сказала, что сложно. Это зависит, в первую очередь от того, насколько хорошо вы знаете оба языка С++ и Pascal.
Однако под Билдером можно и паскалевские программы компилировать (в отдельных файлах проекта).
Например, я где-то нашла исходники чтения/распаковки рисунков в формате TIFF (новые Билдеры умеют их читать, а 6-ой еще не умел). Глянула в те исходники и даже не захотелось с ними разбираться - очень уж сложно и запутанно написано. Тогда я их прямо так живьем и пришпандорила к сишному проекту. И они там в окружении C++ файлов отлично компилируются. Только хидеры мне к ним сишные пришлось написать, но это совсем не сложно.

Спасибо Ксения за ответ.
По хидерам - это чтобы переменные из паскалевской программы использовать в C билдера?!

По Rs232 забыла спросить, где пример и/или компонент хороший есть?

[Xenia]

По хидерам - это чтобы переменные из паскалевской программы использовать в 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 урезанным, опустив объявление тех его функций, которыми сишная часть программы не пользуется. А паскалевская сторона не может этим самоуправством возмутиться , т.к. Сишного хидера не видит.

По Rs232 забыла спросить, где пример и/или компонент хороший есть?

В этом аспекте я целиком солидарна с выше опубликованным мнением kolisnichenko_r - не нужно в случае RS232 пользоваться классами, а следует использовать базовые функции Windows API. Тем более что COM-порт (он же RS232) выглядит в системе, как файловый девайс. Т.е. из него читают и пишут в него точно теми же самыми средствами, кто и с открытым файлом на диске. Некоторую проблему составляет задание скорости обмена и шевеление контрольными линиями, но при работе с классом эта задача не станет проще - все равно придется разбираться с управлением наряду с тем, чтобы еще понять, как этот класс работает . Так уж здесь лучше без всяких классов. По крайней мере поймете, что Windows может сделать со своим портом, а чего не может, вместо того, чтобы надеяться на всемогущество класса, написанного неизвестно кем.

К тому же как на этом форуме, так и на других, ему подобных, работа с СОМ-портом через Windows API обсасывалась несчетное число раз. И что радует, такая реализация выглядит почти единообразно не всех языках.

[Alla_student]

...
а для Сишной программы я написала вот такой пототип того же самого класса:

Код

class PASCALIMPLEMENTATION TTIFFBitMap : public Graphics::TBitmap

PASCALIMPLEMENTATION - это чтобы проиcходила связь с кассом на паскале?
Очень доходчиво вы Ксения объяснили, cпасибо!

Сообщение отредактировал Alla_student - Oct 25 2012, 20:53

[Xenia]

PASCALIMPLEMENTATION - это чтобы проиcходила связь с кассом на паскале?

Да, чтобы С++ понимал, что в данном случае это класс паскалевского объекта.
Однако на самом деле Builder C++ не только сам написан на Паскале, но и его библиотека классов VCL (Visual Class Library) тоже написана на Паскале. Из-за этого практически все оконные классы (органы визуализации и управления в Windows) объявлены на в Сишных хедерах, как PASCALIMPLEMENTATION паскалевских класов, уже скопилированных и залитых в библиотеку.

От С программиста совершенно не требуется знать, что такое PASCALIMPLEMENTATION, т.к. в Сишных хидерах все это уже сделано. Но в моем случае это была паскалевская самоделка, а потому мне самой пришлось забраться в хидер и подсмотреть, как там С++ закомят со скомпилированным пасклевским кодом. Т.е. преамбулу я просто сдула оттуда, не разбираясь, что бы это значило.

А дельфи отдельно - это хорошо, но не дикий замес (паскаль+си) в виде CB. ИМХО.

demiurg_spb во многом прав. Основа, написанная на Паскале, порой сильно затрудняет жизнь С-программистам. Например, от классов, построенных на паскалевской основе (та самая PASCALIMPLEMENTATION), не удается создать производные. Точнее говоря это сделать можно, но слишком уж через ухо.

Зато новичку там раздолье - фактически имеем набор готовых кубиков, из которых буквально за минуты можно состряпать программу, по внешнему виду неотличимой от тех, над которыми профессионалы корпят месяцами. Но эта лафа длится покуда вас удовлетворяют стандартный набор и функции тех кубиков. Но так только захочешь такой кубик "распилить" или серьезно модифицировать, но вляпываешься в такую бяку, что PASCALIMPLEMENTATION - просто цветочки.

Т.е. в определенном смысле это - ... ЛЕГО . Собирать легко, а самому сделать новую фигурку, чтобы подходила по замку к остальным, или невозможно, или очень трудно.