> element->getAttribute(L"href", 2, &variant)
Тут еще один баг, IHTMLElement::getAttribute в качестве аргумента ожидает BSTR, а не wchar_t*. На моей практике этот метод не падает, но думаю только потому, что в MS написали дебилоустойчивый код.
Было бы очень интересно почитать о проблемах, с которыми вы столкнулись при разработке как API так и клиента. Наверняка кто-то сломал голову, думая о разрешении конфликтов, к чему Вы в итоге пришли и какие планы? Как и какие проблемы решали и решили ли при отслеживании изменений файлов и папок. Как происходит процедура синхронизации с учетом того, что пользователь в этот момент может сделать что угодно как с файлами, так и убить приложение. И так далее.
Конечно не заметили. Вы же статью прочитали «по диагонали». И тут же не к месту набросились со своим С++.
Во-первых, тон статьи говорит о том, что посмотрите как это легко в Scala и как сложно в C++ или Java, там уж точно придется написать две стриницы кода. Я же, сомневаюсь в такой категоричности. Во-вторых, это не я придумал сравнивать с C++, а автор статьи.
Спасибо за комментарий, но ни о чём таком ни в статье, ни в переводе не написано.
— Насколько я помню, в конце 2011 года auto уже было.
— В C++ есть ключевое слово const, пожалуйста, пусть будет
Извините, я совершенно не знаком с Scala, в итоге, пробежав по вашей статье, никаких преимуществ не заметил. Вижу, что перевод, оригинал так же не содержит ничего внятного.
Вывод типов
Scala:
val aGuy = "John"
C++:
auto theGuy = "Ivan";
Упрощенное определение классов
Scala:
class Person (val firstName:String, val lastName:String)
C++:
struct Person{ std::string firstName; std::string lastName; }; // мне лично такой стиль форматирования не нравится
Преимуществ не видно.
Объединение методов и операторов
Извините, но я не наблюдаю описанных проблем в С++
Scala:
ListBuffer(1,2,3) append 4
или
ListBuffer(1,2,3) += 4
Вообще говоря, += выглядит сомнительно, в контексте какого-нибудь алгоритма иногда можно понять по-другому.
После примера
"Mary" with "a purse" and "red shoes" should look "nice"
, стало доходить, что может быть на самом деле, речь об отсутствии точек и скобочек. Выглядит круто, но только если очень хорошая подсветка синтаксиса, иначе тяжело разобрать что есть что. Тем не менее чего-нибудь такого или типа linq в C++ не хватает.
С++
сразу после старта или добавления записи имеет смысл их показывать, а то надо постоянно кнопку Ctrl+F давить
-вопрос спорный, если их более 1000, смысл их отображать при запуске?
Плюс в версию того, что не нужно их показывать. Для этого можно иметь отдельную «страничку» с областями, содержащими «самое популярное», «недавно добавленное», «недавно просмотренное». Плюс, если включить в покрываемые файлы документы, то нужен поиск по датам. Для книг, возможно, что достаточно только тегов.
Спасибо за статью, но у меня все равно остались вопросы без ответа
— не ясно как уменьшить время, которое тратится на обзор?
— что делать с недобросовестным обзором?
Я полностью за кодревью, и мы это делаем (в терминах этой стать 95% на github'е), но у меня такое чувство, что что-то не так (дальше в описании крик души). Сборки на каждый пулл-реквест автоматически собираются, все тесты прогоняются, если тесты не работают, то и смотреть как правило пока рано.
— Смотрю на стиль (тут обычно проблем не возникает), выясняю как выглядит картина из далека без деталей, иногда несколько замечаний по API, обсуждаем почему так и решаем как должно быть. Не отнимает много времени, просто прочитать код, оценить что да как.
— смотрю на логику, дебажу тесты. Рассматриваю всякие случаи. Тут начинается «а что если ...», и выясняется, что все плохо. Иногда обсуждаем в переписке, иногда устно, но все равно процесс слияния затягивается, да и такого рода проверка занимает довольно длительное время. Как правило, в таких случаях начинаем думать, как бы это так переписать, чтобы проблема устранялась на уровне архитектуры. В итоге, один пулл-реквест может затянутся на несколько дней или даже неделю. В нормальных условиях у меня рука не поднимается смержить код, когда я точно знаю, что программа может сломаться или работать совсем не так как надо. Это же не на коленке один раз запустить, а отправить юзерам. Обычно в таких случаях вешаю пулл-реквест на себя и объясняю, где баг и никто его не мержит, пока все не исправится.
В общем чувствую себя в эти моменты не по-феншую. Показал коллегам, что их код, простите, говно, затянул разработку и потратил кучу своего времени, в итоге и сам мало сделал или ничего не сделал.
Но я же не все реквесты рассматриваю, бывает даже, что я не успеваю разобраться в каком-нибудь новом модуле, ну а там часто описанный ранее случай. У других членов команды другой подход, и они довольно быстро все мержат, я, честно говоря, не верю, что они разобрались как это работает.
Опять чувствую себя как-то не по-феншую, но засовываю свой перфекционизм до следующего креша.
Получается, что я такой дартаньян, хотя, конечно, и я делаю кучу ошибок опечаток и что-то забываю. В команде отношение ко мне нормальное, наоборот считаем, что, чем раньше нашли проблему, тем лучше, но скорость разработки существенно проседает.
Пробовал поговорить с тимлидом, со всеми вместе и с каждым лично по поводу детализации пулл-реквестов, по поводу времени, как мне уменьшить свои траты, а другие бы лучше все проверяли перед пулл-реквестом. В итоге обсуждения получается, что я делаю все правильно, и менять ничего не надо.
Вариант сменить место работы, конечно, можно рассмотреть, но это кажется слишком кардинально, и, насколько я понял из данный статьи, что ребята решают эти проблемы на одном месте. Возможно, что есть какие-то подходы, которые это все помогают сделать. В утилиты не верю. Можно написать все по всем стайл-гайдам, но в итоге ничего работать не будет. В основном это поведение в многопоточной постоянно работающей программе.
Автор, похоже, просто троллит, во-первых, стиль, во-вторых извечная тема, что «это лучше этого».
Моё субъективное мнение (пишу на 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 выглядит заброшенным, или просто ему приоритет понизили до самого низкого.
element->getAttribute(L"href", 2, &variant)Тут еще один баг,
IHTMLElement::getAttributeв качестве аргумента ожидаетBSTR, а неwchar_t*. На моей практике этот метод не падает, но думаю только потому, что в MS написали дебилоустойчивый код.Показывает ли Ваш анализатор этот момент?
— Насколько я помню, в конце 2011 года
autoуже было.— В C++ есть ключевое слово
const, пожалуйста, пусть будет — Чем помогают геттеры и сеттеры, сгенерированные компилиятором?Scala:
C++:
Scala: C++: Преимуществ не видно.
Извините, но я не наблюдаю описанных проблем в С++
Scala: C++ (Qt5): Вообще говоря,
+=выглядит сомнительно, в контексте какого-нибудь алгоритма иногда можно понять по-другому.После примера , стало доходить, что может быть на самом деле, речь об отсутствии точек и скобочек. Выглядит круто, но только если очень хорошая подсветка синтаксиса, иначе тяжело разобрать что есть что. Тем не менее чего-нибудь такого или типа linq в C++ не хватает.
С++ <troll-mode>Что скажут любители функциональных языков?</troll-mode>
В C++ вопрос контрвариации и ковариантности действительно не прост, возможно, по этому его как-то неявно избегают, и большой проблемы не ощущается.
Не совсем понятно о чем речь, вроде ничего сложного тут нет.
Вообще эта фича «скалы» выглядит страшновато.
Думаю, что программисты C# еще и не такое покажут.
Плюс в версию того, что не нужно их показывать. Для этого можно иметь отдельную «страничку» с областями, содержащими «самое популярное», «недавно добавленное», «недавно просмотренное». Плюс, если включить в покрываемые файлы документы, то нужен поиск по датам. Для книг, возможно, что достаточно только тегов.
— не ясно как уменьшить время, которое тратится на обзор?
— что делать с недобросовестным обзором?
Я полностью за кодревью, и мы это делаем (в терминах этой стать 95% на github'е), но у меня такое чувство, что что-то не так (дальше в описании крик души). Сборки на каждый пулл-реквест автоматически собираются, все тесты прогоняются, если тесты не работают, то и смотреть как правило пока рано.
— Смотрю на стиль (тут обычно проблем не возникает), выясняю как выглядит картина из далека без деталей, иногда несколько замечаний по API, обсуждаем почему так и решаем как должно быть. Не отнимает много времени, просто прочитать код, оценить что да как.
— смотрю на логику, дебажу тесты. Рассматриваю всякие случаи. Тут начинается «а что если ...», и выясняется, что все плохо. Иногда обсуждаем в переписке, иногда устно, но все равно процесс слияния затягивается, да и такого рода проверка занимает довольно длительное время. Как правило, в таких случаях начинаем думать, как бы это так переписать, чтобы проблема устранялась на уровне архитектуры. В итоге, один пулл-реквест может затянутся на несколько дней или даже неделю. В нормальных условиях у меня рука не поднимается смержить код, когда я точно знаю, что программа может сломаться или работать совсем не так как надо. Это же не на коленке один раз запустить, а отправить юзерам. Обычно в таких случаях вешаю пулл-реквест на себя и объясняю, где баг и никто его не мержит, пока все не исправится.
В общем чувствую себя в эти моменты не по-феншую. Показал коллегам, что их код, простите, говно, затянул разработку и потратил кучу своего времени, в итоге и сам мало сделал или ничего не сделал.
Но я же не все реквесты рассматриваю, бывает даже, что я не успеваю разобраться в каком-нибудь новом модуле, ну а там часто описанный ранее случай. У других членов команды другой подход, и они довольно быстро все мержат, я, честно говоря, не верю, что они разобрались как это работает.
Опять чувствую себя как-то не по-феншую, но засовываю свой перфекционизм до следующего креша.
Получается, что я такой дартаньян, хотя, конечно, и я делаю кучу ошибок опечаток и что-то забываю. В команде отношение ко мне нормальное, наоборот считаем, что, чем раньше нашли проблему, тем лучше, но скорость разработки существенно проседает.
Пробовал поговорить с тимлидом, со всеми вместе и с каждым лично по поводу детализации пулл-реквестов, по поводу времени, как мне уменьшить свои траты, а другие бы лучше все проверяли перед пулл-реквестом. В итоге обсуждения получается, что я делаю все правильно, и менять ничего не надо.
Вариант сменить место работы, конечно, можно рассмотреть, но это кажется слишком кардинально, и, насколько я понял из данный статьи, что ребята решают эти проблемы на одном месте. Возможно, что есть какие-то подходы, которые это все помогают сделать. В утилиты не верю. Можно написать все по всем стайл-гайдам, но в итоге ничего работать не будет. В основном это поведение в многопоточной постоянно работающей программе.
Напоминаю, что вопросы в начале комментария.
Вспоминая, что, вроде, иногда люди в комментах добавляют что-нибудь, что им показалось интересным, тоже хочу поделиться.
и в дополнение частичная реализация (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выглядит заброшенным, или просто ему приоритет понизили до самого низкого.