C++14 для Qt программистов

[degs]

Неужели Qt наконец перестала изобретать велосипеды? Молодцы

[e_asphyx]

По-моему, Qt'шные велосипеды как-то проще и понятнее.

[degs]

Я не пытаюсь кого-то уязвить, Qt — лучшая из графических библиотек. Однако еще в самом начале пути они сознательно отказались от использоания шаблонов, потом — стандартных контейнеров, потом POSIX потоков, в конце концов сделали замену для абсолютно всего. Если не ошибаюсь, это первый шаг Qt навстречу стандартному языку и библиотекам.

[Hertz]

В самом начале её пути и шаблоны то не всеми компиляторами поддерживались.

[degs]

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

[EuroElessar]

Извините, а можете напомнить — когда Qt отказалась от шаблонов? Я сам застал только Qt 3 и более поздние, и там шаблоны использовались везде, где это было необходимо и возможно, может я что-то упускаю?

[degs]

Примерно в 95-96 году они набирали волонтеров для разработки и примерно в то же время была активная дискуссия об использовании шаблонов. Речь шла именно об архитектуре ядра библиотеки и было принято решение от шаблонов отказаться в пользу named object model. Аргументом было как раз то что шаблоны еще плохо поддерживались многими компиляторами. Я до сих пор считаю что это была ошибка.

[semlanik]

Учитывая дешевизну памяти в настоящее время возможно Вы и правы. Но тогда я думаю мало кто мог предугадать…

[semlanik]

Класс сожержащий Q_OBJECT не может быть шаблоном. Можете проверить это, еще на стадии moс'а вы увидите примерно такое:

Error: Template classes not supported by Q_OBJECT

И сделано это не из-за глубокого велосипедизма Qt разработчиков как тут высказывались, а ненужного усложнения генерируемого moc'ом кода. Если посмотрите в moc_файлы, то поймете масштаб. В любом случае Qt явно дали понять, что они выбрали путь динамического полиморфизма, что не хорошо и не плохо, просто «есть».

[semlanik]

ЗЫ: но это, само собою, не значит, что в коде использующем Qt, не может быть шаблонов априори :)

[EuroElessar]

И сделано это не из-за глубокого велосипедизма Qt разработчиков как тут высказывались, а ненужного усложнения генерируемого moc'ом кода.

Не совсем верно, это сделано из-за того, что современные компиляторы не умеют экспорт символов шаблонных классов и, как следствие, все сгенерированные moc'ом кишки придется вытаскивать в публичные header'ы, что в свою очередь приводит к конфликтам при повышении версии moc'а.

[e_asphyx]

А никто не уязвлён. Я честно признаюсь, что использую C++ только в рамках разработки на Qt и, соответственно, очень плохо знаю его за этими пределами. Как-то не было нужды.

[Hertz]

Есть ещё proof-of-concept Qt без moc, с использованием compile-time reflection из одного из proposal'ов.

[Gorthauer87]

Вот такая штука есть, сами кишки рефлексии то еще мясо, но результат весьма удобен.

woboq.com/blog/reflection-in-cpp-and-qt-moc.html

Жаль только, что наверняка все навелосипедят свою рефлексию и будет куча своих моделей.

[Hertz]

Именно про эту статью я и писал выше. По крайней мере compile-time рефлексия будет стандартизирована.

[ilammy]

Я думаю, они их давно не изобретают. Главная причина того, что в Qt так много всякого QList, QSharedPointer, QMutex, qMax в том, что Qt 3.0 зарелизилась в 2001 году и в том, что они не желают взять и задеприкейтить всё, что не умеет C++11 и новую стандартную библиотеку. Может в Qt6 так и будет.

А привязывать ли Qt к версии библиотек из какого-нибудь Boost — это религиозный вопрос. Qt тоже как минимум позиционировалась как «единая библиотека, чтобы разрабатывать всё».

[EuroElessar]

Использовать Qt в Boost как минимум плохо из-за того, что Boost, в отличие от Qt, постоянно ломает API/ABI, а Qt гарантирует обратную совместимость ABI/API внутри мажорной версии. На данный момент я могу вспомнить только один случай, когда они его все-таки поломали — в Qt 5.2 и только для arm платформы.

[QtRoS]

Всегда любил Qt за то, что они знают грань между использованием новых фич и обратной совместимостью!
P.S.

Квалификаторы ссылок для методов классов

А где бы про это почитать? Я отвлекся от развития C++ на немного, и уже упустил новую фичу, которая в умелых руках может быть очень полезной!

[Hertz]

Например здесь akrzemi1.wordpress.com/2014/06/02/ref-qualifiers/.
В целом читать особенно нечего, если вы знаете, что такое cv-qualifier у функции-члена, то и ref-qualifier вы поймете бе запинки. Единственный нюанс — если хоть одна из перегрузок функции имеет ref-qualifier'ы, то и другие перегрузки тоже должны их иметь.

[QtRoS]

В принципе достаточно хорошее пояснение, чтобы не особо сильно не углубляться, можно для себя кратко выделить — «Мысленно подставляем квалификаторы после функции для this, вести себя они будут так же, как перед параметрами функции». Спасибо!