История изменений
Исправление sena, (текущая версия) :
Ставить библиотеку для такой классической задачи как перекодировка текста в один ряд с расчётом паровозных котлов — это ну очень толсто.
Ну может быть, мне последние лет 10 перекодировкой заниматься не приходилось, возможно где-то это ещё нужно. Замени паровозные котлы на распаковку архива tar.gz или поиск и индексирование файлов либреофиса. Всё это безусловно полезные вещи, но это не основание включать все эти полезные вещи в графический тулкит.
А вот если выбросить тот же QString, та же перекодировка, например, подкручиваемая через внешнюю библиотеку, будет более громоздкой.
С какой стати? Если QTextCodec кому-то полезен, то достаточно его переделать для работы с std::string и всё. А вот QString в qt3, как и другие COW контейнеры никуда не годятся из-за проблем с многопоточностью. Вместо того чтобы переписывать это всё и доводить до ума, гораздо лучше было бы выкинуть и взять рабочее и стандартное. И если аналога для QTextCodec в std нет и этим ещё как-то можно оправдать его существование, то для контейнеров такого оправдания нет. Hекоторые контейнеры таки были выкинуты из qt4 (типа QPtrList, QDict), другие были существенно переделаны (типа QByteArray и QString), но последовательности разработчикам qt не хватило и они продолжают тянуть это из версии в версию.
Чего там кстати, в мире std:: вместо Qt Linguist брать? Gettext прикручивать? Или появилось что-то стандартное?
В бусте появилось boost::locale основанное на gettext. В std вроде нет пока. Однако нет никакой проблемы использовать Qt Linguist QTextCodec и дальше, но важно отказаться от использования QString. И тогда у нас будет выбор - либо Qt Linguist, либо gettext/boost, либо ещё что-то. А пока Qt завязан на QString, у всех кто пользуется Qt будут проблемы с альтернативами и им будет проще пользоваться встроенными библиотеками, завязанными на QString. Выходит замкнутый круг и QString это одно из ключевых звеньев. Если же отказаться от QString, то как для пользователей Qt откроется возможность использовать с удобством альтернативные интсрументы, типа того же gettext, так и для неqtшных пользователей появится возможность использовать инструменты Qt типа Qt Linguist. То есть произойдёт взаимное обогащение.
Исходная версия sena, :
Ставить библиотеку для такой классической задачи как перекодировка текста в один ряд с расчётом паровозных котлов — это ну очень толсто.
Ну может быть, мне последние лет 10 перекодировкой заниматься не приходилось, возможно где-то это ещё нужно. Замени паровозные котлы на распаковку архива tar.gz или поиск и индексирование файлов либреофиса. Всё это безусловно полезные вещи, но это не основание включать все эти полезные вещи в графический тулкит.
А вот если выбросить тот же QString, та же перекодировка, например, подкручиваемая через внешнюю библиотеку, будет более громоздкой.
С какой стати? Если QTextCodec кому-то полезен, то достаточно его переделать для работы с std::string и всё. А вот QString в qt3, как и другие COW контейнеры никуда не годятся из-за проблем с многопоточностью. Вместо того чтобы переписывать это всё и доводить до ума, гораздо лучше было бы выкинуть и взять рабочее и стандартное. И если аналога для QTextCodec в std нет и этим ещё как-то можно оправдать его существование, то для контейнеров такого оправдания нет. Hекоторые контейнеры таки были выкинуты из qt4 (типа QPtrList, QDict), другие были существенно переделаны (типа QByteArray и QString), но последовательности разработчикам qt не хватило и они продолжают тянуть это из версии в версию.
Чего там кстати, в мире std:: вместо Qt Linguist брать? Gettext прикручивать? Или появилось что-то стандартное?
В бусте появилось boost::locale основанное на gettext. В std вроде нет пока. Однако ещё раз, нет никакой проблемы использовать Qt Linguist QTextCodec и дальше, но важно отказаться от использования QString. И тогда у нас будет выбор - либо Qt Linguist, либо gettext/boost, либо ещё что-то. А пока Qt завязан на QString, у всех кто пользуется Qt будут проблемы с альтернативами и им будет проще пользоваться встроенными библиотеками, завязанными на QString. Выходит замкнутый круг и QString это одно из ключевых звеньев. Если же отказаться от QString, то как для пользователей Qt откроется возможность использовать с удобством альтернативные интсрументы, типа того же gettext, так и для неqtшных пользователей появится возможность использовать инструменты Qt типа Qt Linguist. То есть произойдёт взаимное обогащение.