qserialport теперь под лицензией LGPL

1) Для Qt родной язык всё же C++ (в стандартной библиотеке которого нет возможности работы с последовательными портами) , плюс в неродных тоже не обязательно во всех есть. А ты предлагаешь переходить на язык более высокого уровня, который не всегда подходит для тех задач, для которых используется C++.
2) А чем интерпретатор tcl в данном плане («Потом еще удивляются почему у них приложения рамером в чемодан») лучше Qt?

Даже Python куда легче Qt.

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

> А чем интерпретатор tcl в данном плане («Потом еще удивляются почему у них приложения рамером в чемодан») лучше Qt?

Как для меня , код написан один раз - работает всегда и везде,
Хотя это обещают и не делают другие, а в tcl тихо молчат в тряпочку и все работает.

>Даже Python куда легче Qt.

В каком месте? По производительности быстрее? По размеру интерпретатора и runtime-библиотек? Если и есть разница в размере, то некритична, разницу в несколько мегабайт вряд ли сейчас кто заметит.

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

прежде всего , Python нестабилен для таких вещей.
на этом можно базар и закрывать.

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

Ссылки и указатели — вообще-то элементы языка C++, а не набора библиотек Qt. — К. О.

Ну вот, один предлагает Python, другой — tcl, третий ещё что-нибудь. А если кто-то считает более целесообразным написать какую-либо конкретную программу именно на C++? Почему он не имеет право так считать?

«Мы говорим Ленин, подразумеваем - партия, мы говорим партия, подразумеваем - Ленин» (с)

Ха ха, я тоже лет десять назад страдал этим.
Потом приперли сроки, послал нахрен вантуз,
успел таки обнаружить tcl в linux и решил задачу за два дня (и для вантуза в том числе)
И код арбайтен и по сей день.
А за это время что-то там усохло , отвлилось, обьявили навозом, начали трахать мозг MVC , ... да гори все оно синим пламенем.
Быстрее чем биты станут в UART ничего не будет и все зависит от буферизации.

Ну указатели и ссылки — это изобретения создателей языков C и C++, а не троллей. А тролли используют их в Qt, т.к. как в C++ по другому передать в функцию не копию объекта, а оригинал?

эти изоборетения нужны постольку поскольку плюсы близки к железу во имя высокого быстродействия.
а в том же питоне все что не сделано все для людей - ссылки органичны изначально )

меня лично кьют прельстил изобилием платформ в первую очередь, сотнями возможностей во вторую )
например то, что там из коробки есть всякие кинетик и прочие мейнстримные плюшки меня покорило вмомент

> Даже Python куда легче Qt.
Язык легче библиотеки. Brutal facepalm.

Почитай уже вот это наконец: http://www.riverbankcomputing.com/static/Docs/PyQt4/pyqt4ref.html

В каком месте? По производительности быстрее? По размеру интерпретатора и runtime-библиотек?

В обоим местах в большинстве случаев.

И? Ты сначала попиши на этом PyQt, а потом выпендривайся. И да, Python - не только язык, но и библиотека к нему. Внезапно, да? Поэтому и советуют сначала узнать, а потом говорить.

Писал и немало, так что мимо.

> Ну указатели и ссылки — это изобретения создателей языков C и C++, а не троллей. А тролли используют их в Qt, т.к. как в C++ по другому передать в функцию не копию объекта, а оригинал?

Есть на самом деле способы, использующие простую статическую обёртку над динамическим объектом. Описаны у Коплиена. Помимо прочего позволяют в 99% процентах случаев забыть про конструкторы и деструкторы и использовать указатели только когда надо действительно на что то указывать.

Готоваяь реализация такого счастья, кстати, имеется. В Ultimate++, этакий конкурент Qt, тоже GUI-фреймвок, пытающийся заменить собой все остольные C++ либы. Правда последовательного порта туда вроде никто ещё не написал. И не такой он гламурный, как Qt. Зато U++ — достаточно компактный и весьма шустро компилится, производя при этом весьма шутрые программы. С удобным синтаксисом и без moc-. Есть и своя, заточенная под U++ IDE, правда она немножечко для инопланетян, но привыкнуть можно.

И что? Теперь ты можешь объяснить, к чему твой комментарий? Или это так, к слову?

Кстати, PyQt наконец-то научился делать incref для виджетов? Или всё ещё падает, если ссылку на виджет специально не сохранить где-нибудь в питоновском коде?

Это то, про что в журнале OpenSource несколько выпусков писали? И как оно, пробовали?

Оно родимое. Судя по первым эксперминетам — весьма хорошая библиотека, грабли под ноги пока не попадали. Компилится (и само, и приложения под него) по сравнению с Qt — просто со скорстью света. Общий уклон в статику, даже .lay файлы с визуальной раскладкой виджетов, это на самом деле такой корректный C++ код (с учётом добавленых б-кой макросов) который тоже (как правило) компилируется статически.

Для чего нибудь маленького и утилитистого — садись и пиши, тех же статей в Open Source (и русского тутора на оф сайте) достаточно, чтобы включится в процесс. Как делать что0то динамическое и настраиваемое, пока не разбирался. Но как и в qt — есть свой скриптовый язык,

Я сейчас от C++ несколько отошёл, но когда пощупал Ultimate++ сразу захотелось использовать его по крайней мере «для дома для семьи».

TheIDE конечно штука странноватая, но привыкнуть можно. Судя по тому, что ни у кого так и не дошли руки написать улучшенный вариант этой среды — все привыкают.

Спасибо, поизучаю.

Кто пишет на плюсах - пишет на плюсах, а не Qt. А переносимость работы с последовательными портами - бред. в рамках Posix они вполне переносимы, а если на винду лезть, там нюансов многовато вылезает. Есть смысл заворачивать в библиотеку, говорящую на языке Application Domain, и уже её использовать в кроссплатформенной разработке.

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

Так что единственное, где есть смысл эту штуку применять - это в разработке какого контроллера с гуем из соображений «быстро наваять этот самый гуй». И то веб-интерфейс там смотрится логичнее - получаешь почти и морду, доступную откуда надо, и API удалённого автоматизированного управления. почти нахаляву.(отличающееся от морды в основном ясными сообщениями и заворотом в какой-нибудь XML-RPC).

Но для полноты тулкита - почему бы и нет...

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

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

Ну, насколько я знаю, GPS-навигаторы взаимодействуют с ГИС по последовательному интерфейсу. Ну и, например, POS-система не обязательно является конкретным программно-аппаратным комплексом.