Исправление hobbit, (текущая версия) :
Ставить библиотеку для такой классической задачи как перекодировка текста в один ряд с расчётом паровозных котлов — это ну очень толсто. Кстати, юникоды тоже бывают разные, так что даже похоронив всякие OEM, ANSI и ISO 88**-* (чего у пользователей и близко не наблюдается), мы вопрос перекодировки не закроем.
Но прежде всего речь шла о тех классах, которые не просто не имеют отношения к GUI, а вообще не нужны и которые можно просто выкинуть. К ним в частности относятся разнообразные qtшные контейнеры.
Списки и вектора, возможно, действительно можно не таскать (я, кстати, в каких-то проектах использовал std::vector совместно с кутешными классами, недостатков не нашёл, возможно, плохо искал). А вот если выбросить тот же QString, та же перекодировка, например, подкручиваемая через внешнюю библиотеку, будет более громоздкой.
Чего там кстати, в мире std:: вместо Qt Linguist брать? Gettext прикручивать? Или появилось что-то стандартное?
Исправление hobbit, :
Ставить библиотеку для такой классической задачи как перекодировка текста в один ряд с расчётом паровозных котлов — это ну очень толсто. Кстати, юникоды тоже бывают разные, так что даже похоронив всякие OEM, ANSI и ISO 88**-* (чего у пользователей и близко не наблюдается), мы вопрос перекодировки не закроем.
Но прежде всего речь шла о тех классах, которые не просто не имеют отношения к GUI, а вообще не нужны и которые можно просто выкинуть. К ним в частности относятся разнообразные qtшные контейнеры.
Списки и вектора, возможно, действительно можно не таскать (я, кстати, в каких-то проектах использовал std::vector совместно с кутешными классами, недостатков не нашёл, возможно, плохо искал). А вот если выбросить тот же QString, та же перекодировка, например, подкручиваемая через внешнюю библиотеку, будет более громоздкой.
Чего там кстати, в мире std:: вместо Qt Linguist брать? Gettext?
Исправление hobbit, :
Ставить библиотеку для такой классической задачи как перекодировка текста в один ряд с расчётом паровозных котлов — это ну очень толсто. Кстати, юникоды тоже бывают разные, так что даже похоронив всякие OEM, ANSI и ISO 88**-* (чего у пользователей и близко не наблюдается), мы вопрос перекодировки не закроем.
Но прежде всего речь шла о тех классах, которые не просто не имеют отношения к GUI, а вообще не нужны и которые можно просто выкинуть. К ним в частности относятся разнообразные qtшные контейнеры.
Списки и вектора, возможно, действительно можно не таскать (я, кстати, в каких-то проектах использовал std::vector совместно с кутешными классами, недостатков не нашёл, возможно, плохо искал). А вот если выбросить тот же QString, та же перекодировка, например, подкручиваемая через внешнюю библиотеку, будет более громоздкой.
Чего там кстати, в мире std::string вместо Qt Linguist брать? Gettext?
Исходная версия hobbit, :
Ставить библиотеку для такой классической задачи как перекодировка текста в один ряд с расчётом паровозных котлов — это ну очень толсто. Кстати, юникоды тоже бывают разные, так что даже похоронив всякие OEM, ANSI и ISO 88**-* (чего у пользователей и близко не наблюдается), мы вопрос перекодировки не закроем.
Но прежде всего речь шла о тех классах, которые не просто не имеют отношения к GUI, а вообще не нужны и которые можно просто выкинуть. К ним в частности относятся разнообразные qtшные контейнеры.
Списки и вектора, возможно, действительно можно не таскать (я, кстати, в каких-то проектах использовал std::vector совместно с кутешными классами, недостатков не нашёл, возможно, плохо искал). А вот если выбросить тот же QString, та же перекодировка, например, подкручиваемая через внешнюю библиотеку, будет более громоздкой.