Ответ на »сообщение 223« (DRON)
___________________________
А в данный момент на юникод можно перейти только с помощью каких нибудь TNT, что потребует довольно сильных изменений в программах. UTF8 предлагается как компромиссное решение, не требующее больших переделок в НЕ VCL коде.
А мне так никто и не сказал в чём сложности у борланда добавления работы со string как с widestring?
Как мне кажется, там работы-то, грубо говоря, на месяц... И проблемы с переменной длиной строки нет. И переписывать ничего не надо, просто добавить глобальный переключатель для string на ansistring<->widestring и для pchar на pansichar<->pwidechar, добавить этот переключатель в windows.pas для экспортируемых функций.
Для тех кто читает строку по-символьно, т.е. p:=phar(str); while (p^<>#0) do inc(p); также не надо ничего переделывать, т.к. если в данном случае pchar=pwidechar, то не будет проблемы с тем что ты передвинулся на 1байт вместо двух...
В чём я ошибаюсь?


И ещё, все эти кодировки utf, ucs,... это как бы переходные к widestring. Не в часности дельфи а вообще, т.е. widestring - это итоговая цель? или и для widestringов есть различные кодировки?

Об объемах продаж...
Вряд ли мы сейчас сможем получить конкретные цифры, но некоторые выводы можно сделать по отдельным фразам... В нижеприведенных цитататах из ньюсов нам интересна только одна строка, а в этой строке - только дно слово. Надеюсь, слово "tsunami" в переводе не нуждается? :)

Jennifer-Ashley:
"Does anyone know how SA will be distributed? Do I get an email or something?
I did get my D2K7 and D4PHP today, but not any notification on SA."

Charles Odinot [CodeGear]:
"Hello Jennifer,

I'm responsible for that side of the business.
We have had a 'tsunami' of incoming SA contracts, and my team is working
overtime to enter all details in our sadly antiquated system. (moving to a
new system by the end of Q2..)
You will receive a confirmation from Support Admin, be assured we're working
our way through a stack of new stuff to set up
..."

Ответ на »сообщение 221« (Aleg Azarousky)
___________________________
Кроме того, врядли возможно подменить функцию Length или обращение по индексу, ну и PChar'овские функции.
Вот это действительно проблематично подменить. Вообще при использовании UTF8 вместо ANSI основной проблемой будет отлов багов, потому что навскидку сложно сказать будет та или другая функция безопасно работать с UTF8, как раньше работала с ANSI.

Ответ на »сообщение 219« (riff)
___________________________
или нельзя отбрасывать?
Для программы отличной от HelloWorld скорее всего нельзя. Стандартные функции во многих случаях приводят к очень медленному коду с большим числом пересылок и выделений/освобождений блоков памяти, поэтому совершенно обычным приёмом является переход к PChar (а то и к ассемблеру) с посимвольной обработкой.
Конечно хорошим стилем является ограничение количества таких функций и их выделение в отдельный модуль, а не CopyPast куда попало в тело "высокоуровневых" функций, но с наследуемым от старых проектов кодом не всегда везёт.
так не лучше сразу всё на widechar писать?
Лучше конечно. Но это не к нам, а к Borland-у (хотя как всегда виновата MS не сделавшая поддержку Unicode в 9x), это у него VCL на ANSI, а не на Unicode.
Я уже писал в этой теме, что было бы интересно узнать каким именно методом будет реализован Unicode в Highlander и знать это желательно уже сейчас, чтобы представлять где и какие переделки придётся вносить в существующий код.
А в данный момент на юникод можно перейти только с помощью каких нибудь TNT, что потребует довольно сильных изменений в программах. UTF8 предлагается как компромиссное решение, не требующее больших переделок в НЕ VCL коде.

Ответ на »сообщение 221« (Aleg Azarousky)
___________________________

ладно, поглядим)

Ответ на »сообщение 215« (Banderas)
___________________________

Неуж-то разработчики будут подменять вызовы ко всем функциям из Windows, SysUtils, которые работают со строками как Ansi? Кроме того, врядли возможно подменить функцию Length или обращение по индексу, ну и PChar'овские функции.
Вы не поверите, именно это они и делают. :) Подменяют все вызовы Windows API функций xxxA на xxxW, паралельно конвертируя строковые параметры UTF-8 <--> Wide.

Ответ на »сообщение 219« (riff)
___________________________
А, и ещё: почему тут многие говорят об utf; utf8vcl, ссылку на которую давали не давно, пишут для utf, если всё равно всё конвертируется в widechar... так не лучше сразу всё на widechar писать?
И ещё почему utf8vcl пишут только для utf8, почему не сделали вместо ConvertFromUTF8, какую-то универсальную функцию для других кодировок?

Ответ на »сообщение 218« (DRON)
___________________________
Работа с юникодом (уж точно с UCS-2) ничем не сложнее чем с однобайтным ANSI, а все проблемы в "тяжёлом наследии" в виде уже написаного кода. Речь идёт о проблемах перехода, а не реализации с нуля. А, если говорить об vcl, то какие "тяжёлые наследия" можно привести в пример, если исходить из того что основные функции для работы со строками научили работать с, например, utf-8 (pos, length, replace, str[i], ...), и не "стандартные" обращения со строкой как с массивом байт отбросить пока из рассмотрения(или нельзя отбрасывать?)?
Всё остальное-то в vcl, где задействована строка должно после этого работать...

Ответ на »сообщение 214« (riff)
___________________________
Работа с юникодом (уж точно с UCS-2) ничем не сложнее чем с однобайтным ANSI, а все проблемы в "тяжёлом наследии" в виде уже написаного кода. Речь идёт о проблемах перехода, а не реализации с нуля.
А у PHP как я понимаю такой проблемы просто нет, там уже изначально Unicode.

Я просто как раз недавно занимался тем что переводил свои приложения на юникод. Сейчас оно все конечно работает (и рег выражения и ввод/вывод и анализ текстов и хранение и работа с юникодными урлами, именами файлов, и т.д.) просто времени на перосмысление ушло очень много. Но скажу, что на UCS-2 перейти легче чем на utf-8. А вот на utf-16 абсолютно равносильно что на utf-8.

Ответ на »сообщение 214« (riff)
___________________________

Может кто-нибудь в двух словах объяснит? Некоторые жители КД спорят о том нужен или нет unicode(utf и т.д.), трудно или нет будет заставить работать некоторые функции со строками "переменной" длины...
А как это всё работает, например, в php, ведь и длины строк определяются, и поиск и рег.выражения работают... Почему в php смогли всё это воплотить, а в delphi с таким скрипом пытаются его прикрутить, в чём разница или причина?

[i]Мне уникод не критичен, поэтому вникать в эту тему желания особого нет, просто ради интереса.[/i]

Да нет прикрутить не проблема собственно, если бы не было миллардов строк уже написанного кода, которые работают с string'ами как Ansi (SBCS).