Автор, похоже, просто троллит, во-первых, стиль, во-вторых извечная тема, что «это лучше этого».
Моё субъективное мнение (пишу на C++, полгода назад был в течение полугода на проекте на Qt5, пару лет назад немного трогал c#):
Отдельно пару слов про API: действительно хорош, вообще чувствуется закономерность во всех модулях, довольно удобно. В некоторых случаях бывают недочёты, но жить можно.
Далее по пунктам:
— Core — строки, файлы, асинхронность, метасистема.
— Qt MVVM — QAbstractItemModel
— GUI — QtQuick, Widget, стили, сюдя же локализацая
— Всякие дополнительные модули — работа с сетью, xml, json, базы данных.
— Документация
— Исходники
— Сообщество
— Открытый исходный код и обзоры.
Core: довольно много вспомогательных методов (core), которые в каждом C++ проекте приходится либо откуда-то тянуть, либо делать свои. Если сравнить с boost, то в целом и тут и там присутствует одинаковый функционал. C++11 скорее дополняет, что boost, что Qt.
C#/.NET в этом плане не то что не уступает, а во многом получше.
6+ баллов (по 5 бальной шкале).
Qt MVVM — QAbstractItemModel: после приобретения небольшого опыта кажется очень удобной. Стандартные реализации кроме абстрактной прокси надо забыть, так как они, как уже упоминалось в комментариях только для совсем простых, может даже только демонстрационных, приложений. Все получается и хорошо вписывается в стиль Qt. У нас была и асинхронная загрузка как самих элементов, и их частей, DRY на хорошем уровне, просто выстраивали цепочки из проксей, при этом ничего не тормозило.
К сожалению мало опыта с c#, подскажите, есть ли там нечто подобное, особенно в WPF?
5 баллов.
GUI: QtQuick — может быть это конечно удобно для андроида, но для десктопа очень много негативных впечатлений. Была небольшая путаница в версиях, выяснять зависимость — большой геморрой (уж простите, не припоминается слово лучше), размер, работа на разных системах (это в общем-то к зависимостям). Не так уж и много стандартных контролов, зато можно заанимировать с десятком всяких эффектов что угодно, но мне как пользователю нужна функциональность на привычных элементах, а не анимация, а как программисту не хочется ковыряться в 1000 строчных чужих бажных компонентах, чтобы родить свой, который на мой взгляд должен быть из коробки. Не всегда легко, если вообще можно, поменять/перегрузить что-нибудь «унаследовавшись» от уже готовых компонентов. Читабельность кода весьма сомнительна. В общем все были очень счастливы, когда это дело полностью заменили QtWidget'ами.
Стили в целом неплохи, но всегда чувствовались небольшие проблемы. Я так понимаю, что сейчас модный QML это направления затмил и лучше не станет.
Локализация на наш взгляд показалась немного поломанной, в частности id-based, и усложняется сборка из-за дополнительных lupdate, lrelease, сгенерированные файлы постоянно маячат в гите.
WPF — тоже не идеал, все равно многое надо делать руками. Субъективно в сравнение с Qt значительно лучше.
3 балла. Положительная оценка только из-за виджетов и все таки оно работает.
Всякие дополнительные модули: потихоньку развиваются, есть пара мест где можно улучшить API. Иногда имеет смысл посмотреть что-нибудь стороннее. В любом случае иногда приходится чуть ли не полностью обернуть.
3 балла.
Документация в сравнении с boost получше, в сравнении с C# думаю, что немного похуже.
4 балла.
Исходники: очень хорошо читаемые, boost и товарищи тоже читаемые, но тут субъективно все значительно проще. Про C# ничего не могу сказать.
4 балла.
Сообщество: что-то находилось в интернете, было удобно вначале, потом исходники и отладка внутренностей стали помогать значительно больше и быстрее.
На баг-репорты отвечают быстро, иногда ведётся небольшая дискуссия, присваивают приоритет, но не фиксят. Двоякие чувства, с одной стороны чувствуется активность, но с другой стороны результат не очень быстро появляется.
Сложно оценить.
Некоторые полезные фичи (причем, работающие) висят уже два года, но их никак не включат. Я лично ничего не посылал, но мне показалось, что ревьюверы не всегда хорошо видят картину. Мне, например, никак не понятно, почему лучше иметь только один статический глобальный объект, чем иметь дополнительную возможность его заинджектить.
Динамика развития проекта:
Проект развивается, периодически выходят релизы, иногда с задержками, но впечатления положительные, посмотрим.
Разработка под андроид выглядит очень вкусной. Тут я в качестве диванного теоретика хочу сказать, что на мой взгляд пока ещё сыровата как в реализации, так и в концепции, как это должно быть.
Итог, для модели можно обойтись и без Qt, графику может лучше сделать на чем-нибудь, что ближе к телу целевой платформы. Можно и на Qt, но никто точно не *должен* на него мигрировать.
Полностью поддерживаю. Думаю, что содержимое статьи в большей степени применимо к случаям перемалывания данных. Случай же структуризации всего приложения не освещен.
Мо тоже написали такую утилиту, только для native приложения и вставили её в скрипт, который генерит установщик. Даже на 10-15 сторонних dll уже становится полезно. При сборке установщика на компьютере разработчика можно посмотреть какие dll теперь лишние, и каких именно не хватает.
Вас сейчас роскомнадзор забанит за публикацию материалов доводящих до самоубийства. Все эти люди, «секретари, аналитики, HR'ы, бухгалтера, менеджеры и» тп., и так нестабильные в психическом плане, а вы им еще VBA хотите подсунуть. IDE убогая (чего только стоит то, что только что набранное удаляется), сообщения об ошибках типа «VBA Syntax Error» даже в фале на 100 строк наводят такую тоску.
Предложенный JS намного лучше. Я бы лично посоветовал c#.
По ссылке, считаю, что классическая реализация неверна из-за присутствия гребенки if-else'ов. Механизм выбора метода «посетителя» должен быть возложен на компилятор. Он может быть осонован на прегрузке методов с различными типами аргуметов, или же это могут быть функции с разными именами или как-то по-другому, дело удобства. Это важно, т.к. существенно уменьшается гибкость (подумайте, например, о тестах) и ухудшается поддержка из-за поддержки еще и гребенок.
В целом фича с использованием dynamic покрывает, наверное, больше 90% случаев, но все же это немного другое, т.к. не используется условие, что сами объекты знают о том, что их может “навестить” некий обработчик. Иногда эта дополнительная гибкость может быть очень полезной.
Да, только квадратными скобками.
С некоторых пор в «продакшене» всегда использую квадратные скобки. Они позволяют использовать намного больший набор символов в именах колонок, таблиц и т.п., а так же предотвращают возможные конфликты с зарезервированными словами.
Наследовние от QThread требуется не так уж и часто, а если оно действительно нужно, то нет проблем создать объект внутри перегруженного метода run (текущий тред будет правильный), проинициализировать там все и правильно воспользоваться QEventLoop. Интерфейс внутренного объекта придется обернуть вызовами QMetaObject::invokeMethod(m_internalProcessor, "methodName", Qt::QueuedConnection);, что обезопасит всех пользователей от вопросов о синхронизации.
moveToThread требуется возможно еще реже, например, когда вы хотите иметь много объектов и процессить ивенты для всех объектов только в одном треде.
А вот что действительно нужно, так это для повседневных задач допилить QRunnable, чтобы использовать QFuture. К сожалению, QtConcurrent выглядит заброшенным, или просто ему приоритет понизили до самого низкого.
How do I improve the performance of SQLite? [closed]
Автор замерил производительность различных способов вставки данных. Принципиально ничего нового. Сам процесс тестирования не указан, что снижает уровень достоверности, но все же полезная информация.
SQLite WAL performance improvement
Один странный тип решил переаллоцировать базу, а затем обновлять записи. Решение — увеличить размер единицы роста/уменьшения базы за один шаг (1MB например), используяsqlite3_file_control() и SQLITE_FCNTL_CHUNK_SIZE
Планировщик Запросов Следующего Поколения (NGQP, с версии 3.8.0)
Частичные индексы (partial indexes, с версии 3.8.0)
Ввод/вывод с использованием отображения в память (memory-mapped I/O, с версии 3.7.17)
Multi-threaded Access to an SQLite3 Database
Рассматриваемые случаи: 'Connection sharing', 'Message passing', 'Thread-local connections', 'Connection pooling'. Ничего нового, просто еще раз для каждого случая расписаны важные моменты, которые нужно учитывать.
Приведу свои наблюдения. Например, если нужны одна-две фичи, то сначала они реализуется в рамках текущей архитектуры, конечно без говнокода, все довольно культурно. Если при решении других задач прослеживаются аналогии с уже существующими решениями, выделяются закономерности, общие проблемы и тому подобное, то возникает вопрос о рефакторинге. Основная цель упросить, уменьшить, ускорить и обезопасить код, под кардинально новую функциональность, обычно, начинается новый компонент. В конце концов, кто-нибудь не выдерживает и начинает, делает и заканчивает (тут без фанатизма, как бы ни хотелось) рефакторинг. Дальше все пользуются новым подходом, постепенно подчищая другие места.
По поводу огромного опыта еще хочу добавить про команду. Бывает, что кто-то уже делал подобные вещи, знает подводные камни и может сразу выдать довольно приличную библиотечку. Но остальные члены команды не охотно или вообще не принимают эту библиотеку, какие бы опытные они не были. В итоге все начинается с простого решения, а потом постепенно «велосипедится».
Полностью поддерживаю, такой подход не для продакшена, покрашиться очень легко. Именно поэтому топик в хабе «ненормальное программирование».
Основная идея поста — показать неочевидную особенность ссылок, чтобы предотвратить подобные ошибки и лучше различать r-value и l-value ссылки.
Многие пункты — это общий стиль Qt. После «чистого» С++ очень сложно смотреть на Qt-код. Буквально на прошлой неделе начал участие в Qt-проекте на работе, первые негативные впечатления, судя по справке в интернете и работе коллег:
— namespace — нигде не встретите
— константность — никто не заботиться, практически везде CopyOnWrite, но в некоторых случаях объекты ведут себя как shared_ptr
— указатели — везде сырые, умные использовать довольно сложно, интерфейс qt умные указатели практически не использует
— за памятью вообще никто не следит
— несмотря на довольно хорошую документацию и несложные исходники, если хотите чтобы ваша программа была надежной, приходится много дебажить qt-код и смотреть, когда и что вызывается.
Вспоминая, что, вроде, иногда люди в комментах добавляют что-нибудь, что им показалось интересным, тоже хочу поделиться.
и в дополнение частичная реализация (SugarCpp).
Причем реализовывать ребята начали еще год назад, а статья вот только вышла.
Хороших выходных.
Моё субъективное мнение (пишу на C++, полгода назад был в течение полугода на проекте на Qt5, пару лет назад немного трогал c#):
Отдельно пару слов про API: действительно хорош, вообще чувствуется закономерность во всех модулях, довольно удобно. В некоторых случаях бывают недочёты, но жить можно.
Далее по пунктам:
— Core — строки, файлы, асинхронность, метасистема.
— Qt MVVM — QAbstractItemModel
— GUI — QtQuick, Widget, стили, сюдя же локализацая
— Всякие дополнительные модули — работа с сетью, xml, json, базы данных.
— Документация
— Исходники
— Сообщество
— Открытый исходный код и обзоры.
Core: довольно много вспомогательных методов (core), которые в каждом C++ проекте приходится либо откуда-то тянуть, либо делать свои. Если сравнить с boost, то в целом и тут и там присутствует одинаковый функционал. C++11 скорее дополняет, что boost, что Qt.
C#/.NET в этом плане не то что не уступает, а во многом получше.
6+ баллов (по 5 бальной шкале).
Qt MVVM — QAbstractItemModel: после приобретения небольшого опыта кажется очень удобной. Стандартные реализации кроме абстрактной прокси надо забыть, так как они, как уже упоминалось в комментариях только для совсем простых, может даже только демонстрационных, приложений. Все получается и хорошо вписывается в стиль Qt. У нас была и асинхронная загрузка как самих элементов, и их частей, DRY на хорошем уровне, просто выстраивали цепочки из проксей, при этом ничего не тормозило.
К сожалению мало опыта с c#, подскажите, есть ли там нечто подобное, особенно в WPF?
5 баллов.
GUI: QtQuick — может быть это конечно удобно для андроида, но для десктопа очень много негативных впечатлений. Была небольшая путаница в версиях, выяснять зависимость — большой геморрой (уж простите, не припоминается слово лучше), размер, работа на разных системах (это в общем-то к зависимостям). Не так уж и много стандартных контролов, зато можно заанимировать с десятком всяких эффектов что угодно, но мне как пользователю нужна функциональность на привычных элементах, а не анимация, а как программисту не хочется ковыряться в 1000 строчных чужих бажных компонентах, чтобы родить свой, который на мой взгляд должен быть из коробки. Не всегда легко, если вообще можно, поменять/перегрузить что-нибудь «унаследовавшись» от уже готовых компонентов. Читабельность кода весьма сомнительна. В общем все были очень счастливы, когда это дело полностью заменили QtWidget'ами.
Стили в целом неплохи, но всегда чувствовались небольшие проблемы. Я так понимаю, что сейчас модный QML это направления затмил и лучше не станет.
Локализация на наш взгляд показалась немного поломанной, в частности id-based, и усложняется сборка из-за дополнительных lupdate, lrelease, сгенерированные файлы постоянно маячат в гите.
WPF — тоже не идеал, все равно многое надо делать руками. Субъективно в сравнение с Qt значительно лучше.
3 балла. Положительная оценка только из-за виджетов и все таки оно работает.
Всякие дополнительные модули: потихоньку развиваются, есть пара мест где можно улучшить API. Иногда имеет смысл посмотреть что-нибудь стороннее. В любом случае иногда приходится чуть ли не полностью обернуть.
3 балла.
Документация в сравнении с boost получше, в сравнении с C# думаю, что немного похуже.
4 балла.
Исходники: очень хорошо читаемые, boost и товарищи тоже читаемые, но тут субъективно все значительно проще. Про C# ничего не могу сказать.
4 балла.
Сообщество: что-то находилось в интернете, было удобно вначале, потом исходники и отладка внутренностей стали помогать значительно больше и быстрее.
На баг-репорты отвечают быстро, иногда ведётся небольшая дискуссия, присваивают приоритет, но не фиксят. Двоякие чувства, с одной стороны чувствуется активность, но с другой стороны результат не очень быстро появляется.
Сложно оценить.
Некоторые полезные фичи (причем, работающие) висят уже два года, но их никак не включат. Я лично ничего не посылал, но мне показалось, что ревьюверы не всегда хорошо видят картину. Мне, например, никак не понятно, почему лучше иметь только один статический глобальный объект, чем иметь дополнительную возможность его заинджектить.
Динамика развития проекта:
Проект развивается, периодически выходят релизы, иногда с задержками, но впечатления положительные, посмотрим.
Разработка под андроид выглядит очень вкусной. Тут я в качестве диванного теоретика хочу сказать, что на мой взгляд пока ещё сыровата как в реализации, так и в концепции, как это должно быть.
Итог, для модели можно обойтись и без Qt, графику может лучше сделать на чем-нибудь, что ближе к телу целевой платформы. Можно и на Qt, но никто точно не *должен* на него мигрировать.
Предложенный JS намного лучше. Я бы лично посоветовал c#.
В целом фича с использованием
dynamicпокрывает, наверное, больше 90% случаев, но все же это немного другое, т.к. не используется условие, что сами объекты знают о том, что их может “навестить” некий обработчик. Иногда эта дополнительная гибкость может быть очень полезной.С некоторых пор в «продакшене» всегда использую квадратные скобки. Они позволяют использовать намного больший набор символов в именах колонок, таблиц и т.п., а так же предотвращают возможные конфликты с зарезервированными словами.
QThreadтребуется не так уж и часто, а если оно действительно нужно, то нет проблем создать объект внутри перегруженного методаrun(текущий тред будет правильный), проинициализировать там все и правильно воспользоватьсяQEventLoop. Интерфейс внутренного объекта придется обернуть вызовамиQMetaObject::invokeMethod(m_internalProcessor, "methodName", Qt::QueuedConnection);, что обезопасит всех пользователей от вопросов о синхронизации.moveToThreadтребуется возможно еще реже, например, когда вы хотите иметь много объектов и процессить ивенты для всех объектов только в одном треде.QRunnable, чтобы использоватьQFuture. К сожалению,QtConcurrentвыглядит заброшенным, или просто ему приоритет понизили до самого низкого.Автор замерил производительность различных способов вставки данных. Принципиально ничего нового. Сам процесс тестирования не указан, что снижает уровень достоверности, но все же полезная информация.
Один странный тип решил переаллоцировать базу, а затем обновлять записи. Решение — увеличить размер единицы роста/уменьшения базы за один шаг (1MB например), используя
sqlite3_file_control()иSQLITE_FCNTL_CHUNK_SIZEБез комментариев, просто надо знать.
Ликбез с картинками.
Рассматриваемые случаи: 'Connection sharing', 'Message passing', 'Thread-local connections', 'Connection pooling'. Ничего нового, просто еще раз для каждого случая расписаны важные моменты, которые нужно учитывать.
Было:
dictionary.word LIKE 'абакан%'Стало:
dictionary.word >= 'абакан' AND dictionary.word < 'абаканяяя'Подходит не всем.
Приведу свои наблюдения. Например, если нужны одна-две фичи, то сначала они реализуется в рамках текущей архитектуры, конечно без говнокода, все довольно культурно. Если при решении других задач прослеживаются аналогии с уже существующими решениями, выделяются закономерности, общие проблемы и тому подобное, то возникает вопрос о рефакторинге. Основная цель упросить, уменьшить, ускорить и обезопасить код, под кардинально новую функциональность, обычно, начинается новый компонент. В конце концов, кто-нибудь не выдерживает и начинает, делает и заканчивает (тут без фанатизма, как бы ни хотелось) рефакторинг. Дальше все пользуются новым подходом, постепенно подчищая другие места.
По поводу огромного опыта еще хочу добавить про команду. Бывает, что кто-то уже делал подобные вещи, знает подводные камни и может сразу выдать довольно приличную библиотечку. Но остальные члены команды не охотно или вообще не принимают эту библиотеку, какие бы опытные они не были. В итоге все начинается с простого решения, а потом постепенно «велосипедится».
Основная идея поста — показать неочевидную особенность ссылок, чтобы предотвратить подобные ошибки и лучше различать r-value и l-value ссылки.
— namespace — нигде не встретите
— константность — никто не заботиться, практически везде CopyOnWrite, но в некоторых случаях объекты ведут себя как shared_ptr
— указатели — везде сырые, умные использовать довольно сложно, интерфейс qt умные указатели практически не использует
— за памятью вообще никто не следит
— несмотря на довольно хорошую документацию и несложные исходники, если хотите чтобы ваша программа была надежной, приходится много дебажить qt-код и смотреть, когда и что вызывается.