Обновить
30
0
Boris Moiseev @cyberbobs

CTO

Отправить сообщение
На самом деле, не всё с новым синтаксисом сигналов и слотов так хорошо. В статье на Qt-project есть такой вот адский пример:

QTcpSocket *socket = new QTcpSocket;
... 
QObject::connect(socket, static_cast<void (QTcpSocket::*)(QAbstractSocket::SocketError)>(&QAbstractSocket::error), [socket] (QAbstractSocket::SocketError) {
    qDebug()<< "ERROR " << socket->errorString();
    socket->deleteLater();
});


Комментарий к примеру оттуда же:
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.
Просто обычно все C++ бинарники по крайней мере на production прицельно пострипаны и особо полезной информации из такого стектрейса не извлечёшь.
Буквально на прошлой неделе был очень удивлён, что в таком специализированном сервисе как Dropbox этот самый Drag&Drop не работает, хотя в том же GMail он работает уже очень давно. Хорошо, что сделали наконец-то.
Кроме Highcharts (использую его же, во многом по историческим причинам) есть ещё amCharts и Google Chart Tools.
Есть ещё такая корзина от Chieftec. Хотя её хрен купишь, конечно. Используем четыре таких в самосборном файлохранилище (на основе корпуса Antec Twelve Hundred). В итоге во вполне обычном (хоть и большом) корпусе уместилось 20 дисков :)
Честно говоря, мне показалось, что на PhoneGap то же самое можно сделать существенно проще и без всяких хаков…
Ну, это уже не ноутбук, а какой-то терминал получается. Мне он для того и нужен, чтобы при плохой или просто посредственной связи иметь возможность полноценно работать :)

А в случае если есть хорошая связь и сервер для сборки под рукой обычно под рукой же есть и нормальный компьютер. И проблема сама собой отпадает.
Зависит от профиля использования. У меня по причине работы (я 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 Мб уходит порядка секунды :(
Хотел сначала повозмущаться на тему суеверий, а потом внезапно осознал, что сейчас работаю на служебном Lenovo ThinkPad T420 :)
Могу как-нибудь на досуге рассказать о своём жёстком разочаровании в бренде Asus по результатам эксплуатации ноутбука U41JF :(

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность