Comments 20
Неужели Qt наконец перестала изобретать велосипеды? Молодцы
-5
По-моему, Qt'шные велосипеды как-то проще и понятнее.
+15
Я не пытаюсь кого-то уязвить, Qt — лучшая из графических библиотек. Однако еще в самом начале пути они сознательно отказались от использоания шаблонов, потом — стандартных контейнеров, потом POSIX потоков, в конце концов сделали замену для абсолютно всего. Если не ошибаюсь, это первый шаг Qt навстречу стандартному языку и библиотекам.
+4
В самом начале её пути и шаблоны то не всеми компиляторами поддерживались.
+2
Извините, а можете напомнить — когда Qt отказалась от шаблонов? Я сам застал только Qt 3 и более поздние, и там шаблоны использовались везде, где это было необходимо и возможно, может я что-то упускаю?
0
Примерно в 95-96 году они набирали волонтеров для разработки и примерно в то же время была активная дискуссия об использовании шаблонов. Речь шла именно об архитектуре ядра библиотеки и было принято решение от шаблонов отказаться в пользу named object model. Аргументом было как раз то что шаблоны еще плохо поддерживались многими компиляторами. Я до сих пор считаю что это была ошибка.
+1
Класс сожержащий Q_OBJECT не может быть шаблоном. Можете проверить это, еще на стадии moс'а вы увидите примерно такое:
И сделано это не из-за глубокого велосипедизма Qt разработчиков как тут высказывались, а ненужного усложнения генерируемого moc'ом кода. Если посмотрите в moc_файлы, то поймете масштаб. В любом случае Qt явно дали понять, что они выбрали путь динамического полиморфизма, что не хорошо и не плохо, просто «есть».
Error: Template classes not supported by Q_OBJECT
И сделано это не из-за глубокого велосипедизма Qt разработчиков как тут высказывались, а ненужного усложнения генерируемого moc'ом кода. Если посмотрите в moc_файлы, то поймете масштаб. В любом случае Qt явно дали понять, что они выбрали путь динамического полиморфизма, что не хорошо и не плохо, просто «есть».
+1
ЗЫ: но это, само собою, не значит, что в коде использующем Qt, не может быть шаблонов априори :)
0
И сделано это не из-за глубокого велосипедизма Qt разработчиков как тут высказывались, а ненужного усложнения генерируемого moc'ом кода.
Не совсем верно, это сделано из-за того, что современные компиляторы не умеют экспорт символов шаблонных классов и, как следствие, все сгенерированные moc'ом кишки придется вытаскивать в публичные header'ы, что в свою очередь приводит к конфликтам при повышении версии moc'а.
0
А никто не уязвлён. Я честно признаюсь, что использую C++ только в рамках разработки на Qt и, соответственно, очень плохо знаю его за этими пределами. Как-то не было нужды.
+1
Есть ещё proof-of-concept Qt без moc, с использованием compile-time reflection из одного из proposal'ов.
+6
Вот такая штука есть, сами кишки рефлексии то еще мясо, но результат весьма удобен.
woboq.com/blog/reflection-in-cpp-and-qt-moc.html
Жаль только, что наверняка все навелосипедят свою рефлексию и будет куча своих моделей.
woboq.com/blog/reflection-in-cpp-and-qt-moc.html
Жаль только, что наверняка все навелосипедят свою рефлексию и будет куча своих моделей.
+1
Я думаю, они их давно не изобретают. Главная причина того, что в Qt так много всякого QList, QSharedPointer, QMutex, qMax в том, что Qt 3.0 зарелизилась в 2001 году и в том, что они не желают взять и задеприкейтить всё, что не умеет C++11 и новую стандартную библиотеку. Может в Qt6 так и будет.
А привязывать ли Qt к версии библиотек из какого-нибудь Boost — это религиозный вопрос. Qt тоже как минимум позиционировалась как «единая библиотека, чтобы разрабатывать всё».
А привязывать ли Qt к версии библиотек из какого-нибудь Boost — это религиозный вопрос. Qt тоже как минимум позиционировалась как «единая библиотека, чтобы разрабатывать всё».
0
Использовать Qt в Boost как минимум плохо из-за того, что Boost, в отличие от Qt, постоянно ломает API/ABI, а Qt гарантирует обратную совместимость ABI/API внутри мажорной версии. На данный момент я могу вспомнить только один случай, когда они его все-таки поломали — в Qt 5.2 и только для arm платформы.
+2
Всегда любил Qt за то, что они знают грань между использованием новых фич и обратной совместимостью!
P.S.
А где бы про это почитать? Я отвлекся от развития C++ на немного, и уже упустил новую фичу, которая в умелых руках может быть очень полезной!
P.S.
Квалификаторы ссылок для методов классов
А где бы про это почитать? Я отвлекся от развития C++ на немного, и уже упустил новую фичу, которая в умелых руках может быть очень полезной!
+1
Например здесь akrzemi1.wordpress.com/2014/06/02/ref-qualifiers/.
В целом читать особенно нечего, если вы знаете, что такое cv-qualifier у функции-члена, то и ref-qualifier вы поймете бе запинки. Единственный нюанс — если хоть одна из перегрузок функции имеет ref-qualifier'ы, то и другие перегрузки тоже должны их иметь.
В целом читать особенно нечего, если вы знаете, что такое cv-qualifier у функции-члена, то и ref-qualifier вы поймете бе запинки. Единственный нюанс — если хоть одна из перегрузок функции имеет ref-qualifier'ы, то и другие перегрузки тоже должны их иметь.
+2
Sign up to leave a comment.
C++14 для Qt программистов