Переход на Qt5?

Можно переводить, 5 - это продолжение развития 4ки, ничего сверхстрашного там нету. КДЕ, на сколько я знаю, на 5ке уже собирается.

перевод серьезного проекта под Qt5

imho это называется перевод проекта на QML. Если оставаться в рамках QWidget то разницы практически нет - так, суета одна.

Правда ли в том что native C++ проекты под пятеркой работают быстрее, стабильней?

неправда. Они работают вдоль :) Qt и «native C++» какбэ разные вещи

Правда ли в том что native C++ проекты под пятеркой работают быстрее, стабильней?

Это зависит только от твоего компилятора, а не от версии Qt :)

Qt 4.8.х продолжает обновляться багфиксами.

Правда ли в том что native C++ проекты под пятеркой работают быстрее, стабильней?

С чего бы это? Все изменения в этой области бекпортировались в 4-ю ветку.

Думаю, что пока рано. Тем более, в дистрибутивах его еще нет (арч и гента не в счет).

Qt 4.8.х продолжает обновляться багфиксами.

Будем надеяться, что 4.8.4 не последний релиз 4-й ветки.

пока лучше остаться под Qt4.8?

Пока лучше остаться на Qt 4.7

4.8.5 скоро выйдет, инфа 100%

С чего бы это? Все изменения в этой области бекпортировались в 4-ю ветку.

Далеко не все. Например, в Qt 5 QCoreApplication быстрее и менее ресурсоёмкий, нежели в Qt 4. Также в Qt 5 лучше поддержка C++11. Qt Quick 2.0 использует v8 вместо QScriptEngine. И т.д.

Если использовать некоторые фишки C++11, то да.

Единственное серьезное изменение для Линукса состоит в том, что произошел переезд с xlib на xcb и пока мелкие косяки не все пофикшены.

В 5-ке вроде QtSvg выкинули?

Поперхнулся хлебом

что произошел переезд с xlib на xcb и пока мелкие косяки не все пофикшены.

как будто они собираются фиксить мелкие косяки которые сами добавили в ветке 4.8 своим герритом.

это какие? и что мешает тебе их поправить?

https://bugreports.qt-project.org/browse/QTBUG-28601

зачем я должен чинить то что работало в 4.8.1 и перестало в 4.8.4, что сломал кто-то своим gerrit комитом, как проверяли аппруверы? под веществами очевидно

С чего бы это? Все изменения в этой области бекпортировались в 4-ю ветку.

а вот и нет. система сигналов/слотов, например, теперь использует указатели на функции вместо сигнатур в QString, что уже даёт прирост производительности

нет

А как же QMetaObject::invokeMethod, которому все также передается имя метода строкой?

В 5-ке вроде QtSvg выкинули?

Пока оставили, как и QFtp.

А как же QMetaObject::invokeMethod, которому все также передается имя метода строкой?

не понял вопрос. Qt обладает хорошо продуманной и организованной мета-объектной системой. дело в том, в каком контексте понадобится доступ к свойствам: если ты пишешь плагин QML, то без этого не обойтись. если соединяешь сигналы/слоты своих QObject'ов, то оно в принципе не нужно.

Qt5 пока отсутствует в дистрибутивах. В принципе Linux-only проблема, если релиз программы где-то через пол года, то можно сейчас переходить смело.

Много мелких косметических изменений, но есть и существенные, в стиле «забудьте всё, что вы знали».

1. Если у вас проект на CMake, то новость в том, что CMake-скрипты для Qt это теперь часть самого Qt5. Config-скрипты здесь: lib/cmake, документация здесь: doc/src/development/cmake-manual.

2. Убрали QX11Info, прийдётся пользовать Xlib руками.

3. Убрали QAbstractFileEngine, замены нет, будущее туманно.

4. Продублировали классы QGL* в QtOpenGL*, при этом в последних отсутствует работа с форматом — пользуйтесь QSurfaceFormat, и окном — пользуйтесь QWindow + QOpenGLContext.

5. Продублировали QDeclarative* в QQml*. Полностью отвязали его от QGraphics*.

6. Появилась абстракция QWindow, с которой работают новые классы. Как оно связывается со старыми QWidget и связывается ли вообще для меня загадка.

7. C++11, помните, что хоть какая-то реализация на OSX будет доступна в Clang 3.3, так что рекомендуется пользоваться макросами типа Q_DECL_CONSTEXPR. Или забить и погрузиться в о дивный новый мир C++11 с головой, как сделал ваш покорный слуга.

В пятерке работает быстрее рендеринг текста у Qt особенно под вендой. И ещё благодаря этому быстрому рендерингу тайский язык не тормозит :)) я серьезно

C++11, помните, что хоть какая-то реализация на OSX будет доступна в Clang 3.3

«Хоть какая-то» была в Clang 2.9, а в 3.2 очень даже неплохая. Например, constexpr был реализован еще в 3.1

Сам бы проверял. Добавь себе в вотч-лист интересующие проекты/калаоги в сорсах, и следи, кто туда что коммитит

Кого мне проверять? Я вообще не интересуюсь разработкой самого Qt. Там сидят аппруверы которые за это получают деньги от дигии не иначе.

Смотри какая картина там в баге как было 3 vote так и осталось, то есть ни ты ни готхерус ни кто либо ещё не плусанул, почему? Конечно от лени и от «оно мне не нужно».

В принципе да: http://clang.llvm.org/cxx_status.html

Но некоторый код вызывает ошибки, вот сделал маленький пример:

template <typename T>
class Value
{
public:
	static constexpr Value<T> create();

private:
	constexpr Value( T value ) : value_( value ) {}

private:
	T value_;
};

template <typename T>
constexpr Value<T> Value<T>::create()
{
	return Value<T>( 0 );
}

GCC проглотил нормально, да и вроде соответствует стандарту, если я ошибаюсь — поправьте где.

Смотри какая картина там в баге как было 3 vote так и осталось

«The problem is not a missing vote, but missing code. So instead of a vote, provide code, and the problem's gone.» (c)

Хорошая отмазка бро, это на багтрекере так написано? или в irc так отвечают :)

Там сидят аппруверы которые за это получают деньги от дигии не иначе.

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

В рассылке. И это не отмазка, это опенсорс, бро

Да, похоже на багу

Так вот как не оттестированный код ломает хорошие продукты.

А что за ошибки?

Вон я там сократил до примера. Согласно стандарту, если я и разработчики GCC всё верно понимаем, предварительное объявление constexpr валидно, главное требование — чтобы определение было ДО первого использования. Иначе гарантирована ошибка во время компиляции. Clang же выдаёт:

dendy@linux-hl26:~/projects/tmp/constexpr> clang++ --std=c++11 main.cpp 
main.cpp:18:30: error: conflicting types for 'create'
constexpr Value<T> Value<T>::create()
                             ^
main.cpp:8:28: note: previous declaration is here
        static constexpr Value<T> create();
                                  ^
1 error generated.

Даже если убрать шаблоны его плющит. И такого кода у меня полно. Посмотрим, что будет в 3.3.

7.1.5:

If any declaration of a function or function template has constexpr specifier, then all its declarations shall contain the constexpr specifier. [ Note: An explicit specialization can differ from the template declaration with respect to the constexpr specifier. — end note ]

3.1:

A declaration is a definition unless it declares a function without specifying the function’s body (8.4), it contains the extern specifier (7.1.1) or a linkage-specification25 (7.5) and neither an initializer nor a function- body, it declares a static data member in a class definition (9.2, 9.4), it is a class name declaration (9.1), it is an opaque-enum-declaration (7.2), it is a template-parameter (14.1), it is a parameter-declaration (8.3.5) in a function declarator that is not the declarator of a function-definition, or it is a typedef declaration (7.1.3), an alias-declaration (7.1.3), a using-declaration (7.3.3), a static_assert-declaration (Clause 7), an attribute- declaration (Clause 7), an empty-declaration (Clause 7), or a using-directive (7.3.4).

Спасибо. Как я понимаю, таки пример выше соответствует стандарту. Вообще я читал N2235.

7.1.6

A constexpr specifier used in a function declaration declares that func- tion to be a constexpr function. Similarly, a constexpr specifier used in a constructor declaration declares that constructor to be a constexpr constructor. Constexpr functions and constexpr constructors are im- plicitly inline (7.1.2). A constexpr function shall not be virtual (10.3).

The definition of a constexpr function shall satisfy the following con- straints: — its return type shall be a literal type; and — its parameter types shall be literal types; and — its function-body shall be a compound-statement of the form { return expression; } where expression is a potential constant expression (5.19); and — every implicit conversion used in converting expression to the func- tion return type (8.5) shall be one of those allowed in a constant expression (5.19).

N2235 - какой-то очень старый. Могу кинуть финальный (который уже не Nxxxx, а ISO/IEC 14882:2011).

Да, там по сути вся переписка предложений к стандарту, включая ранние вбросы «никаких рекурсивных вызовов в constexpr!». Мне тут один хороший товарищ уже скинул PDF стандарта 2011, на днях почитаю.