As you might see in the example, connecting to QAbstractSocket::error is not really beautiful since error has an overload, and taking the address of an overloaded function requires explicit casting.
Some macro could help (with c++0x or typeof extensions)
The best thing is probably to recommend not to overload signals or slots …
… but we have been adding overloads in past minor releases of Qt because taking the address of a function was not a use case we support. But now this would be impossible without breaking the source compatibility.
Не знаю, насколько проблема актуальна на данный момент, но случай вполне себе из реальной жизни и использование нового синтаксиса превращает код в тотальный треш, угар и содомию. Хорошо, что это хоть чуть-чуть компенсируется возможностью использовать лямбды в качестве слотов.
Ну, в новом синтаксисе можно будет соединять сигналы и слоты с разными типами параметров, если параметры сигнала имеют возможность неявного приведения к типам параметров слота.
Пишем ПО для государственных систем, то есть не предполагается какая-то международность в разработке. Поэтому в коде проекта комментарии только на русском.
НО! Есть целый ряд компонентов, превращающихся в небольшие библиотеки под свободными лицензиями. Там все комментарии и документация только на английском.
QPA (ну, точнее Qt Lighthouse), насколько я помню, начали делать гораздо раньше. Его, конечно, внедрили, но слегка сбоку. Полноценным запуском QPA, думаю, можно считать выход Qt 5.0 :)
Многопоточность OpenGL — может быть, хотя я не уверен, что это самый широко используемый и популярный модуль в Qt.
С HTTP там другая проблема. Они, конечно, сделали его многопоточность (причём, насколько я понимаю, это была работа одного или двух разработчиков длиной в месяц). Но при этом значительно сломали внутреннюю логику работы, причём так, что фиг поправишь. Если чуть подробнее, QNAM начал некорректно работать с отвалившимися по таймауту соединениями с Keep-Alive, причём так хитро, что хрен воспроизведёшь и хрен покроешь тестами. Но в нашем проекте в одном из мест на Qt 4.8 стабильно ошибка 99 :(
Вообще цикл релизов у Trolltech сильно затормозился после их покупки. Не в последнюю очередь из-за усилий, затраченных на адаптацию под Symbian/Harmattan, создание SDK и так далее. Для сравнения, версию 4.7 готовили около 9 месяцев, а версию 4.8 (в которой, по большому счёту, нет принципиальных новшеств) — почти 15.
Буквально на прошлой неделе был очень удивлён, что в таком специализированном сервисе как Dropbox этот самый Drag&Drop не работает, хотя в том же GMail он работает уже очень давно. Хорошо, что сделали наконец-то.
Есть ещё такая корзина от Chieftec. Хотя её хрен купишь, конечно. Используем четыре таких в самосборном файлохранилище (на основе корпуса Antec Twelve Hundred). В итоге во вполне обычном (хоть и большом) корпусе уместилось 20 дисков :)
Ну, это уже не ноутбук, а какой-то терминал получается. Мне он для того и нужен, чтобы при плохой или просто посредственной связи иметь возможность полноценно работать :)
А в случае если есть хорошая связь и сервер для сборки под рукой обычно под рукой же есть и нормальный компьютер. И проблема сама собой отпадает.
Зависит от профиля использования. У меня по причине работы (я C++-программист) ноутбук используется с очень высокой нагрузкой на процессор (компиляция во много потоков), что при слегка подсохшей термопасте на многих ноутбуках может приводить к перегреву. К сожалению, немногие производители нынче делают систему охлаждения с запасом под высокую нагрузку, в результате чего на моём годовалом Asus начались отключения по причине перегрева. 10 минут компиляции Qt и всё — 95 градусов на CPU :(
С ASUS поаккуратнее только. У них вроде бы всё прилично с сервисом, но к сборке в последнее время есть большие вопросы. По отдельным экземплярам ощущение вообще странное: они совершенно не подлежат обслуживанию. Грубо говоря, без потери гарантии поменять, например, термопасту, не представляется возможным.
Реализуемо, хоть и затруднительно. Как такое на qmake сделать — не знаю, но я с ним вообще довольно поверхностно знаком, необходимости не было :)
У нас в принципе не стояло задачи сделать поддержку кросс-компиляции. Мы же здесь ведём речь о бизнес-приложениях, для них такая цель вообще ставится редко (у нас платформа сборки вообще по большому счёту одна).
На CMake делается без проблем. Можно делать так, что исходные файлы для одной из целей проекта будут генерироваться утилитой, собираемой вместе с проектом в рамках другой цели. Он сам разрулит зависимости и установит правильный порядок сборки.
Мы делаем ещё хитрее: у нас ряд функций ПО выносится в выполнение в отдельных процессах (a-la chromium). Сделано не столько из-за соображений безопасности, сколько из-за нестабильности ряда сторонних компонентов. Отдельный привет здесь передаю реализации Mico ORB :)
В удалённых модулях пишутся классы для экспорта через D-Bus, из них генерируются XML-файлы с описанием с помощью утилиты qdbuscpp2xml, для вызывающей стороны из этих XML генерируются классы интерфейсов через qdbuscpp2xml.
Главная проблема, на которую сейчас напоролись — QtDBus ужасно тормозит на передаче больших (порядка 1-2 Мб) блобов через шину. На девелоперской машине (Core i7-2600K) на блоб весом в 2 Мб уходит порядка секунды :(
Комментарий к примеру оттуда же:
Не знаю, насколько проблема актуальна на данный момент, но случай вполне себе из реальной жизни и использование нового синтаксиса превращает код в тотальный треш, угар и содомию. Хорошо, что это хоть чуть-чуть компенсируется возможностью использовать лямбды в качестве слотов.
НО! Есть целый ряд компонентов, превращающихся в небольшие библиотеки под свободными лицензиями. Там все комментарии и документация только на английском.
Многопоточность OpenGL — может быть, хотя я не уверен, что это самый широко используемый и популярный модуль в Qt.
С HTTP там другая проблема. Они, конечно, сделали его многопоточность (причём, насколько я понимаю, это была работа одного или двух разработчиков длиной в месяц). Но при этом значительно сломали внутреннюю логику работы, причём так, что фиг поправишь. Если чуть подробнее, QNAM начал некорректно работать с отвалившимися по таймауту соединениями с Keep-Alive, причём так хитро, что хрен воспроизведёшь и хрен покроешь тестами. Но в нашем проекте в одном из мест на Qt 4.8 стабильно ошибка 99 :(
А в случае если есть хорошая связь и сервер для сборки под рукой обычно под рукой же есть и нормальный компьютер. И проблема сама собой отпадает.
Только теперь придётся ждать, когда свежая версия компилятора доедет до мейнстримовых дистрибутивов и немного стабилизируется.
У нас в принципе не стояло задачи сделать поддержку кросс-компиляции. Мы же здесь ведём речь о бизнес-приложениях, для них такая цель вообще ставится редко (у нас платформа сборки вообще по большому счёту одна).
Проверено на людях :)
В удалённых модулях пишутся классы для экспорта через D-Bus, из них генерируются XML-файлы с описанием с помощью утилиты qdbuscpp2xml, для вызывающей стороны из этих XML генерируются классы интерфейсов через qdbuscpp2xml.
Главная проблема, на которую сейчас напоролись — QtDBus ужасно тормозит на передаче больших (порядка 1-2 Мб) блобов через шину. На девелоперской машине (Core i7-2600K) на блоб весом в 2 Мб уходит порядка секунды :(