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

Visual Studio.
А что значит "простая работа с формами"?
Простая работа в моем понимании - простой интерфейс. А для простого интерфейса даже форм не нужно, достаточно родных виндовых ресурсов (окон диалогов и редактирования, кнопок-переключателей всяких...) и MFC.

Pelles C

Типа выпадающие списки, кнопочки всякие было просто добавлять.
Попробую.

Visual Studio никогда не славился "простой" работой с формами
Я пользую C++ Builder 6 и не сильно парюсь при этом с ними

А отчего 6-ой? С тех пор много новых Builder'ов вышло.

А до этого был 5-й... Меня и он устаивал всем, как сейчас и 6-й...
Привык я к нему, как ко всему хорошему

А зачем на 6-й перешли?
Сам сижу на 5-м, причин перехода вверх не вижу никаких.

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

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

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

Есть очень много книжек по этой теме, например: Архангельский "Программирование на С++ Builder 6.0"
Кент Рейсдорф Borland C++ builder. Освой самостоятельно
Послед Б.С. Borland C++ Builder 6. Разработка приложений баз данных
И еще много...
Там есть все ответы на заданые вопросы

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


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


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


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


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

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

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

Я с этого начинал: http://www.piclist.ru/S-COM-THREAD-RUS/S-COM-THREAD-RUS.html
Доступно и понятно.

Нет, это лишь для того, чтобы Сишная часть программы могла вызывать функции из паскалевской части программы.
Ведь после того, как каждая из частей откомпилируется своим компилятором, получатся достаточно обезличенные объектные модули (*.obj), которые скручивает в одну программу линкер. Потому и надо, чтобы вызовы из одного модуля соответствовали входу другого. Когда всё на одном языке пишешь, о таких вещах обычно не задумываешься, т.к. компилятор компилит все модули по одинаковым правилам. А когда модули разного типа, то это приходится учитывать. Кстати, точно такого же плана проблема вызывать из C++ функции, написанные на обычном C (который ++) или ассемблере. В последнем случае это тоже делается в хидере при объявлении функции. Например, вот так:

После такого объвления прототипа функции компилятор поймет, как к этой функции сделать правильное обращение.

Для паскалевского случая у Билдера тоже есть специальный квалификатор __pascal, который требуется лишь приписать спереди у функции, чтобы компилятор оформил к ней вызов по паскалевским правилам. Например:

после этого она воспринимается как паскалевская, и обращение к ней будет соответствующее.

Кроме того, на языке C объявление прототипа функции обязательно, т.е. еще до своего вызова функция должна быть объявлена (за исключением лишь тех случаев, когда тело самой функции предшествует в тексте своему вызову). И это отнюдь на обременительное, а очень полезное средство избежать многих ошибок, связанных типом и порядком следования аргументов. А чтобы все модули программы имели единообразное представление о функциях, их прототипы выносятся в отдельный файл - хидер, который инклюдится в начало кода как тех модулей, которые функцией пользуются, так и того модуля, который содержит тело этой функции. Уж тогда-то единообразие гарантируется. К тому же хидер служит замечательной подсказкой про то, в каком порядке у вызываемой функции следуют аргументы.

Но когда программа двуязычна, то единый хидер обычно всюду не подсунешь, и тут приходится брать на себя заботу о соответствии. Например, у меня с читалкой TIFF-картинок был более сложный случай. На Паскале объявление класса TTIFFBitMap было таким:

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

Сходство между ними очевидно. А мне была нужна от того класса функция LoadFromTifFile(...), которая читала картинки с диска и заполняла ими Bitmap. Чаще всего в межмодульном вызове участвует лишь небольшое число функций, им-то и заводим хидеры на Сишный лад (у Паскаля тоже есть свои хидеры *.hpp, которые для С не годятся). Как видите, со стороны С я объявила класс TTIFFBitMap урезанным, опустив объявление тех его функций, которыми сишная часть программы не пользуется. А паскалевская сторона не может этим самоуправством возмутиться , т.к. Сишного хидера не видит.


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

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

Ну исключительно на Си думаю что это не рационально... А вот на С++ уже ближе к делу. Вам уже советовали продукты от MS и Borland. Я бы вам рекомендовал QtCreator.
Если вы только начинаете, то имеет смысл изучать что-то перспективное и актуальное. А подсаживается на древний Builder - это совсем не разумно.
Тут ИМХО 2 пути Студия с дот-нетом или Qt. Последний бесплатен и как следствие легален... Решать вам.

имхо от целей зависит. Если писать коммерческий софт для пользователей, то да. А если всякие отладочные утилиты для себя набрасывать - то обычно или делфи или билдера хватает чтобы быстро накидать кнопочек на форму и поиграться с железом.

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

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

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

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


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

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

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

Эта лафа длиться ровно столько -- сколько необходимо новичку чтобы привыкнуть к сладкой жизни и отучиться критически думать! ((
Как только ты начинаешь сталкиваться с суровыми реалиями жизни в виде экзотических требований заказчика (особенно это актуально для электроники) -- вот тут хана! после этого имеем синдром дельфиста!

Всё это печально и вот поэтому я рекомендую не советовать молодым умам садится на наркотик под названием Borland ибо он всё больше неактуален.

Во бредятины понапИсали...

Бред какой-то Борланд ещё не умер???? Visual Studio C# или С++, кто лучше мелкософта знает систему....

Что предложил бы Гудвин я догадываюсь.
Pelles C, не? ;>

Ваше мнение односторонне, а потому я его оспорю.
Во-первых, умение критически мыслить как раз и тренируется в процессе использования стандартных/типичных средств. Например, "критические" высказывания относительно качества и устройства автомобиля от тех, кто сам ни разу не садился за руль, - ничего не стоят. Прежде чем изобретать новый велосипед, нужно сперва поездить на тех велосипедах, что имеются в продаже. Причем не навороченных, а самых обыкновенных. Короче говоря, критичность мысли приходит лишь в процессе использования того, что уже завоевало признание потребителей. Иначе легко впасть в другую вредную крайность - всякое дело начинать с нуля, "абортируя" опыт предшественников. Ведь суть тут состоит не в том, чтобы избавиться от очевидных недостатков, а чтобы не насажать новых. Тем более что большинство неурядиц типа того, что "нос вытащишь - хвост увязнет". Т.е. абсолютное большинство недостатков являются лишь следствием достигнутого компромисса между двумя негативными крайностями, тогда как потребитель самого компромисса не замечает, а обращает внимание лишь на заметные ему недостатки.

Конкретизирую. Бывает такая детская "одевалка" для девочек, сделанная как компьютерная программа. Выбираешь пресонаж-картинку - какую-нибудь няшку-анимашку. И вот она появляется на экране в полный рост - или голенькая (в одних трусиках), или в школьной форме. А дальше задача ее обуть/одеть по своему вкусу. Открываешь меню "туфли" и там туфлей разных видимо-невидимо! И это только фасоны, а цвет отдельным пунктом меню и идет. Выбираешь туфли, выбираешь их цвет, - и тут в руке у персонажа появляется сумочка под цвет туфлей. От сумочки можно отказаться, но можно подобрать другой тип или цвет. Сумок там тоже видимо-невидимо. Тоже относится к блузкам (воротнички и рукавчики к ним идут по отдельным пунктам меню), бантикам, шапочкам, очкам, наушникам и прочим аксессуарам, включая даже самурайский меч. Потому я и отношу программирование к самым, что ни на есть, девчоночьим занятиям.

Скажем, в Билдере (а точнее говоря, в графике TeeChart) есть объект Chart1, представляющий собой доску/окошко графика, в котором можно поместить несколько "шлейфов" (несколько графиков на одной и той же сетке координат). Первым из которых будет Series[0], а остальные дальше по возрастающим номерам. Стираем точки функцией Clear(), а добавляем функцией AddXY(x,y). Этого знания о графике вполне достаточно на первое время. Вот пример графика синусоиды, но вместо функции sin() вычислить/определить y можно любым другим способом:

А вот две кривые (sin и cos) на одном графике:

И это всё! А дальше как анимашку одеваем - шмякаем мышой по графику, открывается меню, а там куча-мала всевозможных раскрасок. Тут и линией можно те точки соединяться и виде пузатых шариков их отображать, с тенями всех сортов, надписями по осями т.п. Но если туда не лезть, то будет типа школьной формы, без выкрутас и наворотов. И даже оси само нарисует и под размер окошка отмасштабирует. Не нравится что-то - открой меню и выбери другой из множества заранее заготовленных вариантов. А если стало совсем уж невтерпеж узнать, как это все это внутри программирутся, то можно заглянуть в dfm-файл, где это выглядит примерно так:

Вы наизусть помните, как выглядит 37622-ой вариант туфель? Я нет, и помнить этого не хочу! А если всё это не нравится, то вот тебе, привереда, в руки точкодолбильник с линию чертилкой и рисуй тогда сам.

Построение 3D-графиков ничуть не труднее двухмерных - разница только в том, что вместо функции AddXY(x,y) координаты точек задают функцией AddXYZ(x,y,z). Тогда на одну строчку больше получается, т.к. внутри цикла x крутят еще цикл y, а значение z рассчитывают на их основе.

- это из рекламы TeeChart

- а это из квантово-механической программы расчета картины интерференции электронов.

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

Билдер не наркотик, а промежуточная по сложности ступень программистского мастерства. Не ступенька виновата, что на нее кто-то "подсаживается", навсегда на ней замирая. Такой человек просто выдохся. Вот при штурме горных вершин тоже устанавливают где-то посредине маршрута восхождения промежуточный лагерь. Кто-то добирается до этого лагеря, акклиматизируется там и восходит дальше, а кто-то этого совершить неспособен. И наивно полагать, что если тот лагерь снести, то все альпинисты "подсадятся" исключительно на 7-митысячники. Скорее, наоборот, без промежуточного лагеря, до 7-тысячних вершин дойдет гораздо меньше альпинистов, нежели при существовании промежуточного лагеря. Так и здесь. Нежели не дюж подниматься выше, то не сетуй, что промежуточный лагерь тебе в этом помешал.

В определенном смысле дисциплина программирования в своем прежнем качестве умирает, если еще не умерла. Т.е. все больше определяет не знание языка, а умение/эрудиция в пользовании чужими заготовками. Т.е. ситуация тут точь-в-точь как с раскраской готовых фигурок на свой вкус. И не надо в том винить программистов – время сейчас такое. Ведь и в электронике точно такая ситуация, хотя мало кто этим возмущается: электроника стремительно превращается в схемотехнику. Даже есть ходящее выражение "даташиты курить". А означает это, что разработчик изучает спецификации на очередную сборку, которую выбросили на рынок. И эти спецификации есть прямая калька со списка тех туфлей, которые можно напялить на няшку-анимашку. И все эти сборки (микросхемы) есть ни что иное, как готовые объекты, которые соединяют с друг с другом согласно спецификации. Вот вам и прототип ЛЕГО в новом качестве. А спроси нынешнего "электронщика" – как работает транзистор в схеме с заземленной базой? – каждый второй выпадет в осадок. Забывать стали люди, как транзисторы работают, зато в курсе того, какие новые микросхемы на рынке появились и сколько они там стоят.


Борланд умер, но дело его живёт! Суть не в том, "кто лучше знает систему", т.к. речь идет о прикладном программировании, а не системном. TeeChart замечательно строит графики, как и Adobe PhotoShop обрабатывает картинки, но не потому, что они "хорошо знают систему", а только потому, что достигли совершенства на том поприще, на котором позиционируют свое ПО.

По моим наблюдениям гораздо большее число людей, не добравшись до вершины, сошли с трасы, но не потому, что подсели на примитив, а потому, что испугались сложности управления более сложными инструментами или не сумели самостоятельно их освоить. Именно поэтому детям покупают игрушечные конструкторы (типа того же ЛЕГО), а не фрезерный станок. Инструмент, по числу рукояток превосходящий оные в кабине самолета или космического корабля, приводит к противоположной беде - вместо того, чтобы думать о решении своей задачи, пользователь мандражирует на тему "все ли рукоятки я правильно нажал?".

Топикстартер инициировал холивар, не раскрыв главного - цели. Как "академическому" программисту нужно одно, как инженеру другое, исследователю в определенной области знаний третье и т.д. Бесплатных инструментов достаточно - теже MS (NET WinForm) и Borland (серия Turbo).

Тут скорее не цель, а личные склонности. Кто-то способен строить пирамиду, складывая ее из песка по крупинке, чтобы сразу получить монолит. А у кого-то на это не хватает ни терпения, ни мотивации. И для последних предпочительнее построить ту пирамиду хоть из бумаги/картона, лишь бы стояла! А уж только потом заняться ее упрочением.

Лично я, вообще-то, из первых - люблю чтобы хоть малая часть, но до идеала вылизана была. Однако большинство предпочитает подход с другого края - получить поскорее хоть какой-нибудь результат, и лишь после этого его совершенствовать.

Поэтому программирование в виде сборки на скорую руку из готовых "ширпотребных" заготовок имеет огромную армию своих почитателей. И действительно, чтобы переночевать в лесу, можно наспех построить шалаш, в не рыть фундамент под строительство нового дома. Вот и курсовые/дипломные работы, где сроки выполнения важны прежде всего, сборка из готовых кубиков много предпочтительнее "основательного" программирования, особенно, если собственного опыта в данной области не слишком много.

В конце концов, едят же многие люди в Макдональсе, тогда как есть рестораны? Вот и Билдер от Борланда и есть вот такой Макдональдс. А холивара никакого тут нет, т.к. Макдональдс ресторанам себя не противопоставляет, а имеет круг своих собственных почитателей. Особенно среди детства и юношества.

Поддержу Sinclair, программирование "из кубиков" очень быстро превращает нормального спеца в полупрограммиста. Дальше идет бла бла блаЮ которое я удалил, затем опять соглашусь с Sinclair это печально.

Xenia, респект за столь впечатляющий оффтопик. В программировании "из кубиков" нет ничего страшного. Каждый программист должен уметь найти подходящий "кубик" для своей задачи (и написать недостающие). Однако, именно Билдер имеет несколько печальных особенностей, которые делают его непригодным для обучения.
По пунктам:
1. Ужасное IDE, со слетающими настройками, расползающимся indentation, провоцирующее на программирование мышью.
2. Тормозной компилятор. Сколько в интернете есть ускорятелей билдера и всё равно, мало-мальский проект компилируется по 10 минут. В итоге у программиста нервный срыв и психушка.
3. Самое главное: билдер провоцирует писать код одним куском, используя идеологию "код-за-формой". В итоге, программа получается не модульной, а намертво спаянной с GUI.

С другой стороны, если топикстартеру нужно быстро сделать программку с GUI без .NET фреймворка на C++, то лучше билдера ничего не придумаешь. Если нужно качественно и кроссплатформенно, то QT + Visual Studio (или любой текстовый редактор). Если нужно с MFC (препод заставляет), то Visual Studio.

Что у вас за прожекты такие, что 10 минут компилируются?
Ни разу такого не видел... максимум ИАР какой-нибудь полминуты комилирует...

А я для собственных утилей все более склоняюсь к python.
Он уже сам в себе содержит все необходимое, а если надо изысков, то есть PyGTK, WxPython и PyQt - на любой вкус.

1. Практически не нужна "IDE", соответственно не стоит вопрос выбора
2. Свободно, открыто, бесплатно (no crack, no crime)
3. Практически нет лишнего мусора в коде - только конкретные и понятные действия.
4. Можно править на лету и в любом месте
5. И многое другое.

Пример:


Ещё пример:


Я все это к тому, что если человеку надо нарисовать пару кнопок и простейший лог, то совсем необязательно для этого заглубляться в дебри msdn/rsdn, ставить (скорее всего, нарушая закон) студии/билдеры

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

сколько стоит?

А не подскажите как скрестить QT и VS по шагам, а то у меня ничего не получется
И хотя бы простой пример в этой связке?!


Очень интересно. С python никогда не работала, хотя часто слышала, как о прекрасном скриптовом языке.
Подскажите сайт с примерами о которых вы пишите, интересно как это все выглядит живьем и как можно работать с ним - написать отображение графиков в том числе отображать в реалтайме данные поступаемые с порта , цифровых LCD (7-мисегментных) и стрелочных табло, LED, различных по форме кнопок, работать с RS232, ну и с SQL? Как получать исполняемый код, а не в режиме интерпритатора?


Примеры с комментариями можно?! А то этого "зверя", я совсем не поняла, как там программировать и получать исполняемый код с RT довеском в ~100MB

http://qt-project.org/faq/answer/what_is_t...l_studio_add-in

По шагам не расскажу - плотно не работал с этой штукой.

А зачем Вы крестить пытаетесь? У QT своя IDE недурна.

боюсь что дохрена.







примеров полно вместе с самим лабвиндовс. help там более чем понятный.

RT довесок вроде поменьше будет. да, это недостаток. но если софт делать для себя - то вроде терпимо.

http://www.py2exe.org/

Я утилитки для PC накидываю на C# в студии. Вообще нет гемора. И возможностей море.