QT-C ++ и Generic C ++ и STL [закрыто]

В последнее время я проверял мой C ++, Ubuntu QQ. Я люблю фреймворк Qt для всего, особенно для создания GUI. Я стал довольно знаком с ним при использовании PyQt за последние несколько лет.

При использовании PyQt у меня были некоторые проблемы, которые сейчас более выражены при использовании C ++ с Qt: Qt имеет много расширений для C ++, которые специфичны для Qt - QString является лишь одним из распространенных примеров, не говоря уже об автоматизированной сборке мусора. Можно писать приложения на Qt, используя C ++, совсем не зная о C ++ и STL.

Возможно, мне скоро придется снова выходить на рынок труда, и я хотел бы иметь возможность рассмотреть позиции C ++ - но я боюсь, что слишком сильная привязанность к Qt ограничит мои способности работать с универсальным C ++, который когда-то был довольно грозным, но сейчас долго спят и ржавые.

Должен ли я избежать Qt? Буду ли я лучше использовать WxWidgets или GTK ++ для создания GUI?

Какая структура графического интерфейса лучше всего использовать, которая позволяет / требует наибольшего использования универсального C ++ и STL? Как сделать себя наиболее привлекательным программистом на C ++, когда дело доходит до каркасов GUI и т. Д.?

Я бы не стал воздерживаться от использования Qt только по этим причинам. Вы не обязаны использовать все служебные классы Qt; для тех, которые заменяют STL, вы по большей части будете вынуждены использовать QString и, возможно, QStringList. Кроме того, в программе обычно гораздо больше, чем в графическом интерфейсе. Вы всегда можете использовать исключительно универсальный C ++ для остальной части вашей программы и использовать Qt только для GUI.

По моему мнению, работа с STL больше связана с пониманием того, какие базовые структуры данных используются и их сложности, и, следовательно, в какое время вам следует использовать каждый контейнер. И когда речь идет о программировании на C ++, особенно важно знать, как использовать очень важный заголовок <gorithm>, который также должен работать с контейнерами Qt, поскольку они STL-совместимы.

Я не вижу большого вреда в использовании всех этих расширений, предоставляемых Qt, если вы знаете (или хотя бы имеете общее представление о том), как они реализованы внутри. Убедитесь, что вы знаете, что такие вещи, как Q_OBJECT, SIGNAL (), SLOT (), foreach (), не волшебство, а макросы, которые расширяются до допустимых операторов C ++. Например, не так уж сложно понять, как реализованы неявно разделяемые классы и отношения родитель-потомок, которые делают Qt более похожим на Java. Вы всегда можете попытаться воссоздать некоторую функциональность в отдельном проекте, просто чтобы посмотреть, сможете ли вы сделать это с помощью универсального C ++, и тогда вам не будет плохо от использования их в Qt.

Также взгляните на библиотеки Boost. Они предоставляют дополнительные утилиты, которых нет в стандартной библиотеке C ++, и являются действительно хорошим способом приблизиться к универсальному C ++, поскольку они по сути следуют тем же соглашениям, что и универсальный C ++. Некоторые из библиотек имеют довольно сложные шаблонные классы, и просто попытка понять, как они работают, само по себе является хорошим изучением в C ++. У Boost есть много утилит, которые не могут быть найдены в Qt, и другие, которые реализуют те же или подобные концепции, что и некоторые классы Qt, и могут использоваться вместо них.

Если вы попадаете на рынок труда, работая с C ++, скорее всего, вы собираетесь работать с Qt или другим фреймворком, который, подобно ему, будет иметь свои собственные служебные классы, которые пытаются упростить C ++.

Я согласен с большинством похвал Qt, но вопрос был в том, что является лучшей структурой графического интерфейса для использования, которая позволяет / требует наибольшего использования универсального C ++ и STL? В этом отношении Qt немного шизофреничен: он дублирует контейнеры и алгоритмы STL со своими особенностями. Он также предоставляет контейнеры, которые отличаются от STL. Совместимость между Qt и STL не всегда гладкая. В некоторых случаях требуется несколько вызовов функций, чтобы добраться std::stringдо QStringи обратно.

У wxWidgets есть опция для сборки STL, которая использует исключительно контейнеры STL - не существует параллельной вселенной с заменителями собственного производства, как в случае с Qt. Он также компилируется стандартным компилятором C ++, не требуя нестандартных расширений. Это качественный графический интерфейс, заслуживающий внимания.

Вы также можете взглянуть на gtkmm, который является оболочкой C ++ для GTK +. Это ближе к выполнению вашего первого требования, чем Qt.

Я бы не стал слишком беспокоиться о том, чтобы не использовать определенные библиотеки STL, такие как std :: string или std :: iostream или std :: vector. QT-эквиваленты бывают разных вкусов, но они не так далеки, чтобы создавать какие-либо проблемы.

На мой взгляд, более идиоматическим отличием является стиль программирования, который тяжело использовать newдля распределения. В то время как для программы QT это может быть хорошо для части Gui, преимущество C ++ и RAII в том, что вы можете фактически хранить много данных в стеке, а не в куче. При переходе на написание кода без GUI вы должны помнить об этом.