Russian Qt Forum

Собственно сабж.

Желающие могут не читать следующее "повествование", в котором описана мотивация данного вопроса.


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

Т.к. изначально приложение подразумевалось как локальное без поддержки сетевой БД, то встал вопрос, на чем "писать" БД?

Ответ для меня казался очевидным: SQLITE, но не тут-то было - чтобы научить SQLITE обрабатывать регистронезависимый LIKE нужно было чуть напрячь силы, что было проделано и решено, но осадок-то остался )) Еще одна ложка дегтя: у меня уже была некая база данных на SQLITE, которая использовалась в другом ПО, написанном под win то ли на Delphi, то ли на Bulder'е; но как выяснилось данные в ней были "забиты" в win1251 и отказывались нормально (без кракозябрб) отображаться стандартными средствами Qt без применения "костылей" и/или перекодировок исходной БД. С небольшими потугами и это было преодолено, но опять-таки осадок остался...

Позже было решено вообще перенести БД на firebird-embed под win: опять танцы с бубном в несколько часов по сборке более-менее работающего QIBASE, но не понравились некоторые ограничения на LGPL QIBASE. Вроде ничего страшного, но все же...

Дошло дело до отчетов: "поплясал" с ncreport пару дней, но в итоге все заработало. Не понравилась его "медлительность".
В итоге более-менее работоспособное приложение было готово и пришел черед его дистрибуции )) Под "дистрибуцией" я здесь подразумеваю перенос бинарников на рабочее место, где приложение должно было работать. И, о ужас, дистрибутив  занимал почти 40 МБ: ладно, сетка локальная, 100 Мбит/с, размер не существенный, можно поставить всем пользователям.

Тут также не понравился еще один момент(на win-платформе): если даже на компьютере были библиотеки Qt, но другой версии, приложение отказывается работать, т.о. простой перенос бинарника приложения не гарантирует его работу, приходится тянуть все зависимые библиотеки... А, библиотеки не получается разместить единовременно в директории windows или system(32) - могут отказаться работать потенциально имеющиеся другие приложения Qt, если таковые были, а библиотеки Qt для них были установлены в эти системные директории. Значит приходится таскать весь груз зависимостей с дистрибуцией...

Ради эксперимента, запустил "старый-добрый" Delphi и выполнил то же самое приложение суммарно не более чем за 1 сутки времени размером "дистрибуции" 8 МБ в едином exe-файле (ну, плюс файл БД и sqlite3.dll) с поддержкой таблиц SQLITE, заведомо заполненных в кодировке win1251; с поддержкой freereport; против двух недель "танцев" и около 40 МБ зависимых библиотек (само приложение занимало чуть более 2 МБ) на Qt.

Вот и возник вопрос, а почему все же вы используете Qt?
Чем вас привлекает Qt, кроме "Write Once, Deploy Anywhere" и, для некоторых, "LGLP"?

Просто лично для себя я сделал вывод: если надо очень скоро написать приложение под win, то лучше все же использовать "старый-добрый" Delphi (Builder) с его(их) кучей "готовых" решений...

Всем, кто читал столько много букв: огромное спасибо.
Всем ответившим: заведомо спасибо.

P.S. данный пост не подстрекает к холивару

Было (http://www.prog.org.ru/topic_875_0.html)

никогда не работал с базами данных, на qt разобрался за 20 минут, все прекрасно работало.
а можно вопрос - а дельфи у вас купленная?

:) Никогда не работал с БД, но Ваш вопрос достаточно общий. Дело в том что Вы судите с высоты достигнутого опыта - и, не в обиду Вам, Ваша оценка необъективна. Да если я "в своей нише", если задача типовая (в смысле половина и больше мне хорошо знакома), то вопрос только в том "какая оплата в час" - и все. Но совершенно неправильно обобщать этот подход.- когда о задаче ничего (или почти ничего) неизвестно - никаких "заведомых" преимуществ у Вас не будет, и неизвестно что легче выучить - "ту" систему или "эту". Ясно только что учить все равно придется  :)   

Это ж вы чего туда набрали?
4.7.3-mingw: mingwm10.dll+libgcc_s_dw2-1.dll+QtCore4.dll+QtGui4.dll+QtSql4.dll+qsqlite4.dll = 12,5Мб. Откуда ещё 27,5?

Если размер дистрибутива так уж важен - один раз разобраться со статической компиляцией (да, один раз прийдётся потратить время, чтобы разобраться). Получите независимый exe, который после upx (http://ru.wikipedia.org/wiki/UPX)'а будет весить едва ли больше 4Мб.

А вообще, если не нужна кроссплатформенность и важен малый объём исполняемого кода - имеет смысл смотреть в строну дотнэтов.

Да, тут библиотеки Qt не сдюжили. Правда такое использование, как я вам уже объяснял, противоречит документации по SQLite.
Ради интереса предлагаю взять правильную базу с SQLite с произвольной допустимой кодировкой (utf-8 или любой из utf-16) и посмотреть насколько удобно будет с ней общаться средствами той сами Delphi библиотеки (результата не знаю - может это там и предусмотренно, но что-то мне подсказывает...).

1) Писать на том языке, среде, фреймворке, который знаешь всегда проще и быстрее.
2) Задача в данном случае была довольно специфичная, как я уже выше писал.

Обобщу: если надо очень скоро написать приложение, то лучше все же использовать то, чем владеешь.

Теперь про Qt: главный козырь, как ни крути кроссплатформенность. Кроме того библиотека включает в себя довольно большое число хорошо продуманных и реализованных классов. Хорошая справка опять же.
Ну и бесплатность, как ни крути иногда немаловажна, хотя в нашей стране и Делфи у многих «бесплатная».

Есть у Qt и минусы:
- встречаются (хоть и не слишком часто) баги и несоответствие с описанием (не то, чтобы конкуренты этим не страдали, но всё же...)
- обратная сторона кроссплатформенности - если нужно что-то, чего нет в Qt встаёт вопрос: то ли реализовывать апишками, восстанавливая потом, если нужно, кроссплатформенность дефайнами, то ли искать сторонние кросплатформенные реализации и разбираться, подходит оно тебе или нет.

Кроме того, в Qt Creator'е:
- не очень удобный дизайнер, а на небольших разрешениях экрана - вообще непригодный к использованию,
- с gdb под win нередки проблемы с сегфолтами и падениями.

У меня есть честно купленный Visual Studio 2005. Сейчас я его снес. Основная причина кроссплатформенность.

Вопрос с кодировкой решается вовсе не костылями. А вполне нормальными директивами выбора нужной кодировки. Не?


Ну так. А что вы хотели? Программа на делфи использует стандартные виндовые библиотеки. А наличие Qtшных библиотек в замен виндовых нормальная цена за кроссплатформенность. Будет у вас 2 или больше программы на Qt. И этот минус сойдет на нет практически совсем.

Есть много удобных классов которых мне не хватало в MFC и delphi. (По сравнению с delphi еще и язык мне больше нравится)

Qtшная куча лично мне показалась более объемной (в смысле полезного объема):)

Как в тему захожу, так в глаза бросается. Исправь цифры.  ;)

40,0 - 12,5 = ?

msvc 2008
QMAKE_CFLAGS_RELEASE    = -O1 -Os -MT

configure.exe -fast -static -release -qt-zlib -no-gif -no-stl -no-libpng  -no-libmng  -no-libjpeg -no-libtiff -no-exceptions  -no-webkit -no-rtti -no-phonon -no-qt3support -no-multimedia  -no-native-gestures -no-plugin-manifests -no-openssl -no-script -no-scripttools -no-declarative -no-style-plastique -no-style-cleanlooks -no-style-motif -no-style-cde -no-style-windowsce -no-style-windowsmobile -no-accessibility -no-opengl -no-openvg -no-dbus

К тому же вырезано всё что только можно в qfeatures.h

Полученный размер стат. сборки с использованием QtCore + QtGui + QtNetwork составляет  3,9 МБ (1.6 Мегабайт в архиве 7zip)..  
Всё равно не могу понять, откуда берутся эти мегабайты. Было бы интересно найти улититу, которая может показать какие классы и методы попадают в конечный бинарник.

27.5 :)

Сорри за флуд, позже увидел пост BRE!

Долгое время программировал в Билдере. Года три назад попались мне исходные тексты на Qt. Заинтересовало. Как раз и время свободное было. Решил попробовать сам что-нибудь написать. Приведу далеко не все аргументы, а только те, которые в то время заставили меня распрощаться Билдером:
1. Лайоуты. Разве Вам не приходилось встречаться с тем фактом, что Ваша форма на экранах с разным разрешением и разными настройками Винды отображается неправильно (не помещается весь текст, компоненты куда-то уехали и т.д.)? Да, эта проблема решается, но кодировать надо самому. А на сложной форме, да не одной, это еще тот геморрой! Лайоуты снимают эту проблему без каких-либо затрат с моей стороны!
2. Сигналы и слоты позволяют решить много проблем и сильно облегчают жизнь. Например, отделить формы от расчетной части. В Билдере я это тоже делал, но уж больно некрасиво это получалось (если вообще получалось). 
3. Локализация. В Qt есть механизм локализации, и нечего самому придумывать не надо!
4. Как говорилось выше, библиотека Qt ОЧЕНЬ ПРОДУМАНА. И многие мелочи, что мне приходилось в компонентах Билдера дописывать из раза в раз самому, в Qt  уже реализованы в классах.

Поначалу, пока не освоился с Qt, маленькие программки (однодневки) тоже быстрее писались на Билдере. Но со временем надобность в нем отпала и я Билдер снес!

Да, среда программирования у  Билдера мощная, но Qt Creator не стоит на месте а быстро развивается. И на сегодняшний день в нем есть фишки которых мне не хватало в Билдере. Например, показать где используется. Очень полезная вещь, особенно когда правишь программу написанную год назад, и уже подзабыл многие связи в ней. А вообще спорить о IDE можно, но бесполезно. Все определяется привычкой.

Для интересующихся "размером": ну откуда вы взяли, что именно этими библиотеками ограничивается набор? я про это вроде не говорил, считайте
+ QtWebKit4.dll ~16 МБ - пришлось поиспользовать для генерации отчетов
+ QtScript4.dll ~2 МБ   - пришлось поиспользовать для генерации отчетов
+ firebird-embedded ~8 МБ
- sqlite.dll
и далее
+ приложение (с графическими ресурсами) ~2 МБ
+ база ~4 МБ
ну, если этап округления кого и обидел, то извините. соль-то не в этом, правильно я собрал (или даже написал)  свое приложение, или нет; даже не в том, что я не доволен, что приходится таскать груз зависимостей; и даже не в моей субъективной оценке...
Суть топика не "унизить" Qt, а узнать мотивации людей, почему они используют Qt в своей работе?
Лично мне многое нравится в Qt, но есть один тормозящий меня момент: не очень развитый набор именно готовых GUI виджетов и компонентов, поэтому в большинстве своем приходится писать велосипед, хоть и потенциально кросс-платформенный, но велосипед, что ЛИЧНО МЕНЯ не устраивает в написании, как выразился Wlad_C, однодневок. Я не спорю, опыт у меня не шибко велик, о чем и было написано изначально.

буду очень признателен, если поможете обойти методом отличным от того, который предложил LisandreL в топике http://www.prog.org.ru/topic_18057_0.html

я отвечу вопросом на вопрос, можно? А Вам зачем?  ;)


Думаю, ответ вы поймете?

В qt реализованы все необходимые виджеты. Если нужны какие то спец-ые - пишите сами...для этих целей все реализовано. Тем более всем не угодишь: для одно один набор контролов очевиден для включения, для другого другой!

А вы не пробовали отправить базе:
?

У меня нет под рукой подходящей заготовки. Ка то давно цеплялся к базе firebird (к сожалению все было ради теста qt и код не сохранил) - могу ошибаться но именно так и делал.

Для меня принципиально при переходе с Делфи было понимание того, что после серии его перепродаж перспектив у этого семейства продуктов по большому счету нет. Правда теперь я и будущем Qt на десктопе сомневаюсь :(.
Что касается лично Вашей ситуации - то, по моему, малые десктоп приложения для работы с БД и отчетами и есть самая слабая сторона Qt. Ну собственно Ваш опыт это хорошо подтверждает.

>>Обобщу: если надо очень скоро написать приложение, то лучше все же использовать то, чем владеешь.
Это всяко, даже если инструмент совсем убогий, но его возможности хорошо известны, равно как и методы работы с ним. Будь то хоть поганый, но прошедший медные трубы, паяльник.

Ну это Вы не в курсе. Для Qt существует довольно много готовых виджетов, например:
wwWidget на http://www.wysota.eu.org/wwwidgets/ (http://www.wysota.eu.org/wwwidgets/)
для построения графиков – Qwt Widgets и т.д. Погуглите. Внимательно почитайте этот форум. Найдете очень много интересного.

Добавлю.
Привычка - вторая натура! Просто Вы еще мыслите категориями Билдера. Со временем это пройдет! Хотя, лично у меня, при переходе с Билдера (8 лет просидел) на Qt ощущения, что не хватает компонент не было. А совсем даже наоборот :). В билдере для работы с юникодом приходилось использовать компоненты сторонних разработчиков (что не есть гут). QString изначально есть юникод. Чтобы избавится от "казенного" вида Билдеровских форм, опять же приходилось использовать компоненты сторонних разработчиков (платные, без исходных кодов). Виджеты в Qt изначально имеют элегантный вид, а если хочется что-то изменить для этого есть стили: легко и просто. И много чего еще нашел. То есть, в Qt я сразу нашел то, чего мне не хватало в Билдере. Поэтому, "в переходный период" у меня не было никаких сомнений. Я с энтузиазмом разбирался в Qt. Знал, что это того стоит. Не зря будет потрачено время.

И никто не упомянул про паршивый(по качеству сгенерированного кода) компилятор в delphi/c++ builder. С Qt можно взять ms c++/intel c++ compiler/g++/... и программа будет просто банально работать быстрее.

Такое подозрение, что на Delphi никто толком и не сидел с этого форума.

Было дело когда-то давно.... Компилится в разы быстрее, чем с++.

>>про паршивый(по качеству сгенерированного кода) компилятор в delphi/c++ builder
в чём то проявляется?

>>Компилится в разы быстрее, чем с++.
да и код компактнее и работает быстрее.
В этом отношении Дельфя никто не смог догнать

Вот в этом у меня сильные сомнения.

>>Вот в этом у меня сильные сомнения.
а у меня нет. Это просто факт по моему (и многих других людей) опыту работы с Дельфи и другими инструментами создания ПО.

Компилятор + библиотека + IDE - определяются кругом задач, которые с их помощью необходимо решать. Когда имеющиеся программные средства не позволяют эффективно решать поставленные задачи, подыскиваются новые компоненты, позволяющие это делать. При этом всегда приходится чем-то жертвовать (не являющемся принципиальным для решаемых задач), т.к. нет ничего идеального.
Если имеющиеся программные средства позволяют успешно решать круг нужных задач, то переход на новые библиотеки, IDE, компилятор, ничего, кроме головной боли не дает! Отсюда и возникают вопросы: почему вы используете Qt, почему вы используете Делфи и т.д.

У «многих других людей» факты другие:
http://www.gamedev.ru/flame/forum/?id=78283
http://www.gamedev.ru/flame/forum/?id=14391

Люто плюсую. Также имею сомнения.

[offtop]
Исходя из анализа работы BC 3.x - BC 5.x , эти компиляторы компилят ужасно тормозной и большой код , по крайней мере под DOS.
Просто я щас пишу одну софтинку для железки на которой установлен ROM DOS.
И для разработки программ для нее производители рекомендуют BC/TC v 3.x, так вот, если приложение сложное и необходимо фиксировать события с точностью порядка 0.1 мс, то оно просто не влезает на флэш диск девайса и работает оч. медленно.

Другое дело - компилер Open Watcom, перешел на него и ни сколько не жалею: скорость выросла раза в х3, а размер приложения упал в х5 раз.
Такие вот дела. :)
[/offtop]

В системе есть библиотеки (libc,libstdc++)/crt, написанные на c/c++. Через них ОС предоставляет прикладное API. Голая программа на с++ обязательно использует эти библиотеки. Голая программа на паскале также использует эти библиотеки, но плюс к этому использует также runtime паскаля, который представляет из себя оболочку на сишным runtime+расширения паскаля. Отсюда простой вывод, что голая программа на паскале всегда будет больше "тянуть" чем аналогичная на c++. Тянуть - имеется ввиду с динамическими зависимостями. Плюс ко всему некоторые вызовы к системе на паскале будут делаться не напрямую, а через паскалевские оболочки. Отсюда накладные расходы. Если уж сравнивать размеры бинарников, то надо сравнивать статически-откомпилированные. Тормозить или не тормозить схожие программы могут из-за библиотек(vlc/qt).

Дельфи лет 8 палочкой не тыкал, но как он может быть быстрее, если до сих пор трудности с x86_64(уже добавили или по-прежнему обещают?). То же самое относительно всяких sse/avx. Но даже если не брать все эти новые инструкции, мне очевидно, что компиляторы c++ сейчас развиваются гораздо быстрее чем паскалевские и по всяким оптимизациям уже ушли далеко вперёд.

Зачем нужен дос в 2011-м году(ну кроме лабораторных 1-го курса)?

Развлекаются ;)

Читай внимательно:
См. ROM-DOS (http://en.wikipedia.org/wiki/ROM_DOS#ROM-DOS).

Я читал, но у меня вывод один. Либо это очень старые девайсы(over 12 лет), либо их конструкторы допустили конструкторские промахи.
В обоих случаях я не вижу смысла связываться с такими устройствами.

Я с Вами не соглашусь.
Да, в Qt реализовано все, чтобы можно было САМОМУ СОЗДАТЬ подходящий виджет. Но сколько вы потратите на это времени? И много ли Вы видели именно "готовых" виджетов для Qt, я имею ввиду не их количество, а их разновидности: разные клоны текстовых редакторов, colorpicker'ов, taskpanel'ов, виртуальных клавиатур, индикаторов и имитаций небольшого количества аналоговых девайсов - это больше похоже на "Hello, world" разных людей, пытающихся "улучшить" по их мнению уже имеющиеся виджеты 3х лиц и не более чем.
Не буду спорить, есть и вполне стоящие виджеты(компоненты) для Qt, но их единицы.
Посмотрите хотя бы тот же torry dot com net и сравните разнообразие и количество "готового" с тем же wysota.eu.org/wwwidgets или qt-apps.org.
Возможно, это плата за кросс-платформенность; а возможно, и за то, что Qt все же ИМХО движется в сторону мобильной платформы, для которой бОльшее значение имеют различные "фантики" в виде анимаций и простоты интерфейса, нежели нагромождение элементов управления. Это только лишь мое мнение и не более чем.

Согласен, расширений для Qt почти нет, только qtlabs интересно и можно использовать. Более того выскажусь уже неоднократно: расширяемостью виджетов в Qt даже и не пахнет. Это значит вы никогда не сделаете второй qttreeview.

т.е.?

Лично меня в Qt привлекает, на мой взгляд, отличнейшая документация и LGPL.
Кросс-платформенность для меня пока нечто абстрактно-потенциальное, т.к. вряд ли я буду писать супер-мега-прогу, которой бы захотели пользоваться полмира. А на сегодня большинство "моих пользователей" - пользователи windows, поэтому в свободное время изучаю и пишу "для себя" небольшие приложения на Qt; а "заказные" программы все же делаю не на Qt, потому что так для меня все же быстрее выходит.

 ;D

[offtop]
Вы просто наверняка не в теме, ман: АСУ ТП, Промышленная автоматика, ПЛК и т.п.
В частности бюджетные девайсы (PLC) типа: ADAM 5510x, ICP DAS и т.п. имеют на борту ROM DOS (или аналогичную ОС), и
тот факт что там стоит эта ОС - очень даже хорошо и огромный плюс!, т.к. в ней можно делать такие вещи, что в остальных ОС сделать невозможно или оч. трудно.
К примеру: закодить жесткий режим реального времени, перегрузить таймеры так, чтобы они тикали с частотами вплоть до 1МГц что очень важно в некоторых отраслях и задачах.

Правда у этих моделей слабый ЦПУ (~40МГц но реально работает на 10ти МГц) - но это мелочи.

Поэтому ваше утверждение о том что: "В обоих случаях я не вижу смысла связываться с такими устройствами." - просто вызывает снисходительную улыбку: :) и удивление:  :o   

Такие девайсы в целом цена/производительность/возможности для бюджетных АСУТП очень даже хороши, естественно, при умелом подходе.
[/offtop]

Но это оффтоп.

Да, я с этим тоже согласен.
Также меня, как АСУ-шника, очень сильно напрягает отсутствие "системных" классов для работы с периферией PC, например USB, Serial портов, GAME/Joystic портов, и др., да и Sockets сделаны не очень...
И в ближайшем будующем этого ждать не приходится, а жаль.  :-\

Никогда не выйдет стабильного "сертифицированного" набора 3rdparty библиотек с виджетами.

Да, помню как мы радовались, когда пересели с Borland C++ на Buider: компонент то сколько готовых! Но радость была недолгой:
1. Стоящих компонент раз, два, ... и все.
2. Документация на них, если и есть, то оставляет желать лучшего. А защастую ее нет вообще.
3. И все это великое множество компонент написано чисто по студенчески, т.е. работает только в принципе: шаг влево, шаг в право и крах программы без какого-либо предупреждения.

Приведу только один пример. Есть один сайт. На нем более 20 различных программ автора сайта. Большая часть из них платная, но есть и бесплатные. Меня заинтересовало: на чем он их так лихо клепает? Скачал одну. Посмотрел - на Делфи. Запустил. Там, кроме всего прочего, надо было ввести 2 вещественных числа. Я знал, что на моем компьютере разделителем дробной части является запятая. Поэтому специально ввел числа через точку. Эффект был предсказуем - программа рухнула без какого-либо предупреждения! О том, чтобы исправить ошибку оператора мечтать и не приходится. Это закономерный конец программ авторы которых программируют мышкой и используют великое множество готовых компонент!

>>Никогда не выйдет стабильного "сертифицированного" набора 3rdparty библиотек с виджетами.
поясняй.
Приведи примеры сертифицированных компонентов для борланада, их цены, уровень поддержки.

А еще есть катортография, где Qt не пашет, есть драйвера, где Qt совсем некчему, т.д. Нельзя объять необъятное! Просто Qt не для Вас. Ищите подходящую библиотеку.

А чем плоха Qt для картографии? О_о

Тем что написано 0

А Вы наберите в гугле: ГИС, и почитайте. Там своя специфика. Существуют специальные библиотеки для ГИС как платные, так и бесплатные. И их объем не уступает Qt.

Напрасно вы так думаете, я несколько в теме.


Знаете, вы приводите смешные аргументы. Таймеры "оттикать" на любом современном контроллере никаких проблем не составляет, тем более что они как правило реализованы аппаратно.
А этот ваш дос... 286-ой какой-нибудь? Жрёт наверное как танк, стоит столько же, один производитель - intel(сомневаюсь что какая-нибудь via), альтернативных поставщиков хрен найдёшь. На средства разработки все давно забили(вы же сами пишете про bc 3).
Не надо делать в силу привычек из пром. контролеров писюк. Есть гораздо более лучшие решения. Взять тот же cortex-m. Есть куча разных специализированных современных операционок разной степени жирности/реалтаймовости.
Ещё весьма интересно как в этом вашем досе с многозадачностью, графическим интерфейсом, драйверами устройств. Флешку или клавиатуру так просто не всунешь, поди?

мы на Qt выпустили уже три коммерческих комплекса для картографии и навигации, и вот как-то улыбнулись ))

а если судить по числу "готовых модулей", то мне кажется тут вообще Qt не причем :))

А я и не говорил, что нельзя. Разговор не об этом. µarbius ищет готовые решения!
Чтоб взял виджет - и программа готова! Его цитата:
Всего несколько часов. Но это будет именно то что мне надо, и работать будет так, как я задумал! А подгонка чужого творения под мои нужды занимает порой гораздо больше времени.

я не говорил, что я их именно ищу. я говорю, что многого не хватает для desktop-приложений.

Думаю, Вы лукавите. Ну, если уж "скатились" до делфей, то почему, например, Ehlib бесплатен, а аналогичный продукт для Qt стоит аж за 300 у.е. Почему, чтобы сделать на Qt сортировки, иерархические заголовки, да, те же комбобоксы и прочее, нужно каждый раз тратить, как вы говорите, "несколько часов" ? Это я немного утрирую, но суть, что для тривиальных задач все же приходится тратить время, остается. Так можно договориться, что и на ассемблере писать - одно удовольствие. Если было все так быстро и просто, не думаю, что стоило бы брать столько денег за "обычный грид", например.

Нет, не в теме.

Ну ну. Оттикайте ка мне таймеры на PLC от Schneider Electric, Siemens, Control Microsystems и т.п. А я на вас посмотрю. :)
Ах, вы наверное под "контроллером" понимаете микроконтроллер?
Если так - то вам никто в АСУ ТП не даст паять и программировать свою наколенную поделку, т.к. это детский сад.
А промышленности принято использовать готовые решения на ПЛК!
Улавливаете разницу между ПЛК и процессором/микроконтроллером? ;)

Процессор - аналог Intel 80186/80188.

Неважно сколько жрет (~10-30 Вт).
Остальное я не распарсил: причем тут вообще VIA и сотоварищи?
Какие альтернативные поставщики?

А какие вы знаете еще средства для разработки под DOS ?
И вообще, ПЛС с возможностью программирования на С/С++ это скорее исключение чем правило.
Для программирования ПЛС применяются иные языки и инструментальные средства! Есть даже (вы удивитесь) стандарт для этого!

Кто делает писюк? Вы о чем?

Найдите мне дешевый ПЛК на Сortex-m (если вообще найдете). А насчет операционок - то с точки зрения АСУ-шника вообще пофигу какая ОС стоит на ПЛК, т.к. АСУ-шник программирует ПЛК при помощи специализированных "IDE".
И не факт, что он сможет при необходимости доковыряться до внутренностей ПЛК и его ОС для реализации каких-то специфических задач.
Т.е. в этом плане стандартные возможности промышленных ПЛК не очень гибкие: из-за ограничений IDE, ОС и т.п.,
тем более, что различные ПЛК "заточены" под разные задачи (отрасли промышленности).

;D Зачем многозадачность то? Зачем графический интерфейс? Зачем драйвера устройств? Зачем Флешка? Зачем клавиатура?

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


  

Посмотрел для интереса в инете
Для физических лиц там тоже цены есть! Но суть не в этом. Просто подходы к программированию у нас с Вами разные. Ответственность за свои результаты работы тоже разная.
Так никто же и не спорит, что для начинающих программистов лучше Билдера и Делфи ничего пока нет (Бейск не в счет:) )

Ваши ПЛК сравнимы по возможностям с МК как по техническим характеристикам, так и потому что вы их программируете на низкоуровневом языке. Я не призываю что-то там разводить и паять наколенные поделки: уже давным давно есть одноплатные компьютеры, которые вставляй в слот, подключай перефирию и работай. Есть референсные дизайны от производителей и т.д.
Судя по тому, что вас пустили с этим вашим досом в АСУ ТП, с контролем качества принимаемых решений у вас не важно. То есть тот же детский сад.

Как и ожидалось - еда мамонта.

Сколько жрёт  - очень даже важно для систем аварийного питания и переносных устройств. У вас ват 20, а можно вложится в 1.

Взаимозаменяемость. Слышали такое? Это когда производитель снимет с производства ваш "аналог Intel 80186" или будут трудности с поставками из-за каких нибудь аварий на Фукусимах вы будете вынуждены останавливать производство/продажи или испытывать трудности с ремонтом/сопровождением. Или надеетесь, что интел ещё 20 лет будет эту еду производить?

Так в том-то и дело, что дос уже не нужен в новых разработках. Поддерживать старые - да, можно было лет 5-10 назад. Но сейчас с этим уже пора заканчивать и заниматься только эпизодически, делать ремонт. А вы я как вижу делаете новые разработки? В этом-то весь и маразм ситуации.

Вы делаете со своим досом.

Ну так чего ж вы не программируете из под этих IDE на предметно-ориентированных языках? Может просто потому, что под ваш дос их никто не пишет и не поддерживает? А чем то, что есть, так лучше уж c++...

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

Я не знаю что вы там ваяете, но у промышленного контроллера есть интерфейс взаимодействия с человеком. А это в первую очередь - дисплей и клавиатура, которые можно не изобретать, а взять готовые с рынка, к которым есть драйверы под современные ОС. Кроме этого, контролер часто подключают к различным сетям, переносят информацию туда-сюда. А тут привет драйверам.
Или на вашем контроллере по прежнему семисегментные индикаторы с тремя кнопками управления? Судя по тому, что я уже знаю(дос+древний процессор+древние инструментальные средства) так оно и есть.
Многозадачность - нужна для управления одновременно несколькими задачами на одной железке. Внезапно, да? В конечном счёте это дешевле(одна железка вместо нескольких+за разработку можно посадить быдлокодеров которые не умеют автоматы состояний) и надёжнее(при проблемах в одной задаче система продолжает выполнять остальные). Но вам конечно же в 2011-м году многозадачность не нужна.

Ну вы же не знаете обо мне ничего, чем я занимаюсь/занимался, чем интересуюсь, где и как учился и т.д. Зачем такие выводы делаете?
Аськи и прочие браузеры, кстати, никогда не писал.

Да, сравнимы. И что с того? Для текущих задач по сочетанию цена/производительность эти ПЛК - оптимальный вариант.
Одноплатные компьютеры - это совсем из другой оперы, не нужно путать ПЛК и то что вы привели в пример.

;D

Ну да, хотелось бы что-нибудь побыстрее конечно.

Наврядли уложитесь в 1 Ватт.

С взаимозаменяемостью тут при использовании любых ПЛК будут проблемы. И пока продукт (ПЛК) пользуется спросом - то фирмы производители не будут его снимать с производства.

Для тех ПЛК которые сейчас использую (точнее некоторые их модификации) для программирования используются более новые
среды на языках IEC61131-3.
Но эти среды не дают такой гибкости для использования некоторых аппаратных особенностей ПЛК, как если бы ПЛК был на чистом DOS.
Да, не спорю, в некоторых средах есть возможность писать некоторые модули на Си, но этого может быть мало для поставленной задачи.

Я ничо с досом не делаю, это ДОС делает со мной. :)

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

 
Вы не путаете ли "графические панели" с ПЛК?
У контроллера один интерфейс: Ethernet/Serial + светодиодики на панели!  :)

2 Wlad_C:
Ну, в общем я с вами спорить не стану, свое мнение я уже высказал, и Вас переубеждать не буду.
Не стоит цепляться к некоторым мелочам, иначе это может перерасти в "а у меня на компе есть линукс, поэтому я крут".

2 kuzulis & gogi:
Как-бы спасибо. Лично я не против, но вроде маленько не по теме?.. Или я чего-то не совсем понимаю? ;)

Прошу прощенья, понесло! :)

Просто всё ИМХО, сводится к тому, что код генерируемый BC компилятором не очень хорош (по крайней мере в старых его версиях).
Думаю, что и в BCB (Delphi) v > 6.x всё аналогично.

µarbius, извините конечно. Но раз вы не против...

попробую ответить моему собеседнику. Уверяю, мы долго не будем и скоро разойдёмся.

То что вы выбрали по сочетанию цена/производительность/надёжность/энергопотребление явно будет в аутсайдерах.

Их(фирмы) заставят обстоятельства, потому что они не смогут купить процессоры. А ради этого крошечного спроса ни intel, ни производитель ПЛК не будет продолжать производство, не надейтесь. Дураков покупать неадекватные предложения мало.

Ну во всяком случае близкое значение для ядра системы получить вполне реально, я уверен в этом. Что может быть ядром ПЛК? МК+несколько ЦАП/АЦП, возможно внешняя память+внешний флеш. Современные МК потребляют в некоторых режимах микроамперы. Если всё это взять изготовленное на современном техпроцессе, а не 20-ней давности, то будет жрать немного.

Да и не надо вам внутрь системы лезть. Вам может понадобится выходом подрыкать, считать напряжение с аналогового входа или написать обработчик прерывания от того же таймера. Это вы примерно на c++ и делаете, это же сможете и на более крутом ПЛК. Ну и в чём проблема?

Да можно называть сии устройства как угодно. Но факты говорят, что их применяют в весьма разнообразных устройствах. Вам не надо, а кому-то надо. Что плохого в том, чтобы подойдя к устройству смотреть на экран вместо светодиодов и видеть в каком режиме работает устройство, что происходит с объектом управления и т.д.

Ну, понеслась, родимая...

Опять же повторюсь: для нашей (моей) специфичной задачи эти ПЛК ( ADAM5510x, ICP DAS ) самый оптимальный вариант.
И то что у него на борту стоит ROM-DOS это даже огромный плюс.
Для наших целей нам не нужны ни клавиатурки, ни дисплейчики ни флешки.
Необходимы только RS232/485 + Ethernet + локальные модули ввода/вывода.
И иметь возможность фиксировать события (поступающие на модули ввода) с точностью до 1мс.

И ВСЁ!

Вот если вы мне предложите свободно программируемый ПЛК с аналогичным функционалом/модульностью/ценой чтобы оно было лидером,
тогда, может быть я бы еще и поспорил с вами, а то всё голословно заявляете.
Я даже спорить на эту тему не хочу и не буду.


Интел и так уже не производит те процессоры которые стоят в этих ПЛК, эти ЦПУ являются аналогами интеловских! В чем проблема то?

Не получите, там много чего ещё. И кто говорит о техпроцессе 20-ти летней давности, с чего вы взяли?  ;D

Имея в ПЛК операционную систему вы не сможете так просто обработать прерывание, как в обычных микроконтроллерах.
т.е. многое зависит еще от типа ОС и других факторов.
И это еще при условии, что ПЛК является свободно программируемым!

То о чем вы говорите применяется для мелких и простых объектов автоматизации типа лифта и т.п и т.д.
Для крупных же распределенных АСУ ТП все ПЛК устанавливаются в шкафы (стойки, УСО) и закрываюцца железными дверями на ключ.
Иногда в двери шкафа вырезают отверстие в которое вставляют графическую "тачскрин" панель, которая связана с контроллером по Ethernet к примеру  :) .
Чтобы можно было потыкать в неё и посмотреть что и как "по месту".
Но эта панель является отдельным самостоятельным устройством и используют этот подход не всегда.  

В основном для того чтобы посмотреть " а что там и как работает" служат Автоматизированные Рабочие Места операторов и т.п. с которых операторы производят контроль и управление ТП.

Видать, это вы еще мало в теме, но не расстраивайтесь, пусть это будет вам маленьким ликбезом  ;)

ЗЫ: Заканчиваю флейм. Надоело, скучно.  :(