Убрать UTF8 напрочь, как было в 0.9.24

[qivi]

Когда всё прогрессивное человечество идёт вперёд, к единообразию кодировок в виде UTF8, некоторые несознательные товарищи тянут весь прогрес на порочный путь развития...

Правильно, потому как помимо перевода среды и компонентов на UTF8, надо ещё все функции работающие со строками перевести то же на UTF8... а то получается графика работает с UTF8, а обработка строк в коде (строковые функции) нативна для АНСИ... а для основной кодировки нужно подключить альтернативную библиотеку, с альтернативными функциями и та ещё не всё умеет... мож правильнее если надо АНСИ подключать альтернативно?

[NTFS]

Пусть прогрессивное человечество ответит на простой вопрос: зачем мне UTF8, если я пишу GUI только для Windows? Для Linux я работаю в чистом FPC, для Windows же кодировка UTF8 не нужна абсолютна, ибо все (включая WinAPI) работает на cp1251.

Теоретически, проблема может быть, только если я захочу перенести свое приложение на Linux, но в этом случае кодировки будут как бы не наименьшей из проблем. Да и не вижу я ситуации, когда мне потребуется разработать GUI под Linux - все-таки это не для десктопа среда.

[qivi]

Linux - все-таки это не для десктопа среда.

А я её именно для этого использую и более чем доволен.

[Mr.Smart]

NTFS
Адекватное отображение в системе отличной от локали приложения.
Написание мульти-языковых приложений.

[Alexx2000]

для Windows же кодировка UTF8 не нужна абсолютна, ибо все (включая WinAPI) работает на cp1251.

Вообще-то Windows давно уже использует Unicode (UTF-16), а Ansi (cp1251 для русской Windows) оставлена для совместимости со старыми приложениями. Последние версии Delphi тоже уже не используют Ansi.
Проблема как уже писали в том, что FPC все еще использует Ansi, a Lazarus уже UTF-8.

[NTFS]

Понимаете, все дело в реалиях применения. 95% процентов моих клиентов сидят на Windows, 90% из них используют именно русскую раскладку. А так как я пишу не сферического коня в ваккуме, а приложения для конкретных бизнес-процессов (грубо - чтобы тетя Клава могла вбить свой товар и распечатать свой список дел), то мне можно не думать о высоком. А утыкивать код лишними функциями, когда 100% (!) баз моих клиентов хранят данные в cp1251, как раз непозволительно. Ибо отнимает время и увеличивает риск ошибки.

[alexs]

ибо все (включая WinAPI) работает на cp1251.

Неправда ваша - винда давным давно (ещё с 4-й NT) использует USC16, вернее использовала - сейчас им приходится всё переводить на UTF16. А всё потому, что сразу пошли не туда.
А win1251 там точно также эмулируется - внутри все вызовы из A-версии переводятся в W-версию.
И лучше сразу уже идти нормальным путём, тем более и сам FPC к этому в конце концов прийдёт. По крайней мере р

А утыкивать код лишними функциями, когда 100% (!) баз моих клиентов хранят данные в cp1251

абота со строками там потихоньку допиливается до ума.

А утыкивать код лишними функциями, когда 100% (!) баз моих клиентов хранят данные в cp1251

Это пока не столкнёшся с данными, в кодиовках отличных от русской и англиской. Я тоже раньше базы делал в win1251 - и обжёгся на этом. Сейчас только в UTF8.
Мои программы также работают только в России, в моём регионе.

[and]

Луше сразу писаь правильно - а не как удобно.

Гениальная фраза! Я плакалЪ!
То есть, по-Вашему, _правильно_, присваивая строке строку, думать, чьи это строки и соответственно не нужна ли обёртка в какие-нибудь конвертирующие функции?
Или сразу "писаь правильно" и ждать, когда FPC "дорастёт" до UTF-8 и станет способен дать работающую программу из "правильно написанного" кода? Потому что когда (если?) он "дорастёт", обёртки станут не просто не нужны - они сломают.

Проблема как уже писали в том, что FPC все еще использует Ansi, a Lazarus

...побежал впереди паровоза. В результате работа с типом string стала сильно напоминать программирование на brainfuck'е.

[alexs]

Гениальная фраза! Я плакалЪ!

Плакать будем, когда проект большой будем переделывать.
Ошибки проектирования - самые дорогие.

[Padre_Mortius]

То есть, по-Вашему, _правильно_, присваивая строке строку, думать, чьи это строки и соответственно не нужна ли обёртка в какие-нибудь конвертирующие функции?

Думать особо не нужно, нужно понимать где ваша программа взаимодействует с системой и делать переконвертацию при необходимости. В итоге не так уж и много лишнего кода получается.

[and]

Думать особо не нужно, нужно понимать где ваша программа взаимодействует с системой

Не-не-не! При нынешнем положении дел "понимать" приходится, где Lazarus взаимодействует с FPC.
Взаимодействии моей программы с ОС - это, например, OEMToAnsi при чтении dbf в кодировке DOS-866.
Та работа с string'ами, которую мы имеем сейчас - это _НЕ_ПАСКАЛЬ_! Будь Вирт (долгая ему лета!) мёртв, вертелся бы сейчас волчком.
Интересно, в D2009/2010 с переходом на Unicode работа со строками тоже стала настолько <censored>? Знающие, просветите меня plz: я остановился на D5. Можно в личку.

Плакать будем, когда проект большой будем переделывать.

Точно! Я об этом же: когда FPC "вырастет из коротких штанишек", мы, дружно рыдая, ринемся вычищать из "проекта большого" костыли-конверторы.

[alexs]

Детский лепет - честное слово.
Все эти проблемы с костылями,преобразованиями и прочей ерундой решается правильным проектированием приложения и группировкой функционала.
Достаточно собрать в одном месте обращение к файлам на диске - и всё, проблема с именами файлов решена.
Работа с БД - там вобще быть не должно проблем - нормальные СУБД поддерживают перекодировку данных (если они в ней ханятся по какойто причине не уникодах.
Какие ещё проблемы?

[qivi]

Быть или не быть...
Заметил, темы не касающиеся каких либо конкретных проблем (вопросов связанных с кодом), обязательно превращаются в споры где непримиримые противоборствующие приверженцы своих точек зрения категорично и неотступно их отстаивают... да пусть каждый пишет как он хочет...

А UTF однозначно нужна, Лазарус написан не для одной винды (какая б в конечном счёте там не была кодировка), а как кросплатформенная среда разработки. За то время сколько я пользуюсь Лазарус'ом заметил что он очень стремительно развивается (вместес ФПЦ), осмелюсь предположить что ФПЦ "дорастёт" (как было сказано выше) до УТФ очень скоро... чего я ему искренне и желаю.

[v-t-l]

ФПЦ "дорастёт" (как было сказано выше) до УТФ очень скоро

UTF-8 удобна для исходников и нужна для вывода на не-win-платформах, но UTF-16 удобнее для обработки.
Я полностью за юникодизацию FPC/Lazarus, но пока не будет автоматического преобразования WideString (или UnicodeString) в Utf8String и обратно, программирование в FPC/Lazarus будет головоломкой.

[eevee]

alexs, я бы руками и ногами ЗА UTF-8, но то, что он вытворяет сейчас (Лазарь) - ну ни в какие ворота...
Вот один из примеров (мой собственный опыт) тут