Board.KolibriOS.org

А у приложения прикомпилированная или подгруженная либа, которую писал совсем другой человек. И у которого совсем другие представления о том, в какой кодировке указан путь.

Serge wrote:подгруженная либа, которую писал совсем другой человек

Ну так и что это меняет? Пусть либа читает кодировку из заголовка. Или ты собрался внезапно затереть заголовок?

0CodErr
А какая нибудь GLib имеет понятие о кодировке в заголовке ? Или LLVM или ещё терабайт опенсорсного кода ? Будешь все их проверять ?

Serge, ты лучше приведи конкретный пример, и я объясню тебе как можно сделать.

Библиотеки, они не сами по себе живут.
В любом случае должна быть согласованность между приложением и библиотекой.
Если твоя библиотека хочет, например, UTF16, то ты просто говоришь ядру посредством поля в заголовке приложения, что ты хочешь UTF16.
После этого ядро кладёт тебе путь\параметры в UTF16.
Затем ты передаёшь свои путь\параметры в UTF16 в библиотеку.
Ну и для ASCII\UTF8 аналогично.

Проблемы абсолютно никакой. Ещё раз, приводи пример, а я объясню тебе.


Pathoswithin, я всё же не понимаю, что должен означать ноль вот тутТы говорил, что это нужно для поддержки префиксов. Ну а кодировка-то какая будет? Если ASCII, то для него префикс не обязателен, и можно указать тогда 1, а не 0.
Я потому и писал ранее, что лучше было оставить как и было до твоих правок

Я тебе долго пытался объяснить зачем там префикс, но похоже, что это невозможно viewtopic.php?f=2&t=3429&start=88
Кстати, ты так и не привёл конкретный пример обработки 100 ГБ символов в UTF-8.

В данном случае default = cp866, но может зависеть от той настройки, которую ты планировал реализовать.

0CodErr wrote:Библиотеки, они не сами по себе живут.
В любом случае должна быть согласованность между приложением и библиотекой.
Если твоя библиотека хочет, например, UTF16, то ты просто говоришь ядру посредством поля в заголовке приложения, что ты хочешь UTF16.
После этого ядро кладёт тебе путь\параметры в UTF16.
Затем ты передаёшь свои путь\параметры в UTF16 в библиотеку.
Ну и для ASCII\UTF8 аналогично.

...а потом оказывается нужно использовать две библиотеки, одна из которых хочет UTF-8, а другая UTF-16.
Мы не боимся трудностей, которые сами себе и создаём (c)

Pathoswithin wrote:Так, вам осталось сделать свой вклад - выбрать номера двух новых функций для UTF-8 и UTF-16 (например 80 или 32).

Без разницы, я их всё равно со временем удалю.

А что ты планируешь сделать?

Останутся старые функции, которые будут принимать UTF-8.

CleverMouse wrote:...а потом оказывается нужно использовать две библиотеки, одна из которых хочет UTF-8, а другая UTF-16.

А давайте вообще 10 библиотек и 10 разных кодировок

CleverMouse wrote:Мы не боимся трудностей, которые сами себе и создаём (c)

Вот-вот, не нужно лишних проблем создавать. Хотя, при работе с разными кодировками 99,99% что понадобится конвертер. А значит, проблемы снова никакой. Только вот далеко не всем нужно несколько библиотек и несколько кодировок.

Pathoswithin wrote:В данном случае default = cp866, но может зависеть от той настройки, которую ты планировал реализовать.

Ну и какой смысл тогда? 0 = 1 в данном случае. Зачем тогда ты сделал изменения? Ничего не улучшилось, удобнее не стало.

Pathoswithin wrote:Кстати, ты так и не привёл конкретный пример обработки 100 ГБ символов в UTF-8.

А я тебе говорил уже, что ты узко мыслишь. Ладно, вот тогда пример не от меня, от постороннего человека, только там уже не гигабайты, а терабайты http://www.linux.org.ru/forum/talks/9406274

CleverMouse wrote:Без разницы, я их всё равно со временем удалю.

CleverMouse wrote:Останутся старые функции, которые будут принимать UTF-8.

Это тогда сломает обратную совместимость. Вообще при такой тенденции есть вероятность, что KolibriOS просто переедет отсюда в другое место. А товарищи, без конца ломающие обратную совместимость, могут и дальше продолжать разрабатывать свою OS, только теперь уже based on KolibriOS. В KolibriOS обратная совместимость ломаться не будет. И, кстати, GPL не запрещает при желании использовать ещё чей-то код.

0CodErr wrote:понадобится конвертер. А значит, проблемы снова никакой

Необходимость конвертирования - это и есть проблема. Карфаген должен быть разрушен Кодировка должна быть одна.

0CodErr wrote:Это тогда сломает обратную совместимость.

Если всё будет в UTF-8, то большая часть, если не все, существующих программ вообще не заметит разницы.

CleverMouse wrote:Необходимость конвертирования - это и есть проблема.

Ты сама себе противоречишь!

CleverMouse wrote:...а потом оказывается нужно использовать две библиотеки, одна из которых хочет UTF-8, а другая UTF-16.

Если всё будет в UTF-8, то большая часть, если не все, существующих программ вообще не заметит разницы.

Они и так не заметят, потому что по умолчанию ASCII. UTF8 это лишние тормоза, которых можно избежать, если не ограничиваться только одной этой кодировкой.

0CodErr wrote:

CleverMouse wrote:Необходимость конвертирования - это и есть проблема.

Ты сама себе противоречишь!

CleverMouse wrote:...а потом оказывается нужно использовать две библиотеки, одна из которых хочет UTF-8, а другая UTF-16.

Так это же ты предлагаешь каждой библиотеке свою кодировку. Я как раз и говорю, что Карфаген должен быть разрушен кодировка должна быть везде одна.

CleverMouse wrote:Так это же ты предлагаешь каждой библиотеке свою кодировку.

Это где это я такое говорил??? Ну-ка, ну-ка покажи-ка!!!

Вон там viewtopic.php?f=2&t=3429&p=67721#p67721 я говорил

Но для обработки внутри программы советуют UCS2/UTF-16/UTF-32.

А ты хочешь искусственно ограничиться одной только UTF8.

Ну вот прямо на этойпредыдущей странице:

0CodErr wrote:Но её можно будет(надеюсь ) задавать в заголовке приложения.

0CodErr wrote:Если твоя библиотека хочет, например, UTF16, то ты просто говоришь ядру посредством поля в заголовке приложения, что ты хочешь UTF16.

Если кодировка по всей системе одна, её нельзя задавать в заголовке приложения, и библиотека не может "хотеть" какую-то другую.