Путь приложения

Applications development, KoOS API questions
  • 0CodErr wrote::lol: Ну и как эти вот твои цитаты связаны с
    CleverMouse wrote:Так это же ты предлагаешь каждой библиотеке свою кодировку.
    Ммм???
    Ещё раз. Если кодировка по всей системе одна, её нельзя задавать в заголовке приложения.
    Сделаем мир лучше!
  • Поэтому она и не должна быть одна.

    Ответь заодно товарищу Serge
    А у приложения прикомпилированная или подгруженная либа, которую писал совсем другой человек.
  • CleverMouse wrote:Останутся старые функции, которые будут принимать UTF-8.
    Я тоже за utf8. Крякозябры в кириллических именах можно пережить, тем более это решаемо.
    0CodErr
    Вот поэтому в заголовках и не должно быть флагов кодировки.
  • Как-то недемократичненько... Сейчас основная кодировка ср866. Конечно, реально сделать основной UTF-8, но разве другие кодировки помешают? Собственно, идея с маркерами как раз и заключалась в том, что строки могут быть в разных кодировках, но определяются автоматически и не создают проблем. Такой подход доступен в режиме "default".

    0CodErr
    Зачем тогда ты сделал изменения? -> Единый стандарт. Важно.
    Ладно, вот тогда пример не от меня, от постороннего человека, только там уже не гигабайты, а терабайты http://www.linux.org.ru/forum/talks/9406274
    В базах данных "строка" это единица данных, а не обязательно текст. В данном случае это "10 килобайт чисел (по 8 байт на одно число)".

    Не беспокойся, KolibriOS сама никуда не переедет без людей, способных поломать обратную совместимость, а точнее без основных разработчиков.
  • Serge wrote:Крякозябры в кириллических именах можно пережить
    А, ну тогда зачем вообще unicode? Можно любые крякозябры пережить :mrgreen:
    Serge wrote:Вот поэтому в заголовках и не должно быть флагов кодировки.
    Это могут быть дополнительные сисфункции.
    Serge wrote:Я тоже за utf8.
    А я за универсальность. И аргументы я уже приводил. Теперь ваша очередь привести аргументы. Только, пожалуйста, не высосанные из пальца.

    А с разными кодировками всё равно придётся работать, например, в ECMAScript используется UTF16, ID3 tag-и для MP3 допускают UTF-16 и UTF-8. А вы предлагаете взять и искусственно ограничить возможности системы. Причём ограничить то, что уже работает.
    Pathoswithin wrote:KolibriOS сама никуда не переедет
    Ну, конечно же, не сама по себе :)
    Pathoswithin wrote:без людей, способных поломать обратную совместимость
    А такие и даром не нужны. Пусть они и дальше у себя её ломают.
    Pathoswithin wrote:точнее без основных разработчиков
    Всё течёт, всё меняется. Да и по большому счёту ничего сверхъестественного и не требуется. Всего лишь оставлять работающее работающим. И всего-то! Да, GPL позволяет также использовать сторонний код :)
    В базах данных "строка" это единица данных, а не обязательно текст.
    не обязательно текст != обязательно не текст
    Да и вообще, это лишь единичный пример. Думаешь других не может быть?
    Там он дальше пишет
    Ключ - строка ходов вроде «A/B/C/...», в среднем 50-100 байт, значение - матрица чисел с плавающей запятой, около 10 килобайт (для простоты можно закодировать одной строкой).
  • Действительно, MenuetOS остаётся работающей уже больше 10 лет. И зачем они вообще Menuet64 делают? Почему-то всё течёт, всё меняется...

    Правильно, матрица чисел с плавающей запятой, я процитировал его комментарий http://www.linux.org.ru/forum/talks/940 ... nt-9411049
    Если хранить столько данных в текстовом виде, то надо менять не кодировку, а архитектора.
  • Pathoswithin wrote:Действительно, MenuetOS остаётся работающей уже больше 10 лет. И зачем они вообще Menuet64 делают? Почему-то всё течёт, всё меняется...
    Не очень понял, к чему это. Хорошо, когда добавляется что-то новое, также хорошо, когда улучшается что-то существующее. Но плохо хотеть ограничиваться чем-то одним. В то время когда более расширенные возможности уже существуют.
    Pathoswithin wrote:Если хранить столько данных в текстовом виде, то надо менять не кодировку, а архитектора.
    Зачем ты так зациклился на конкретно этой задаче? Неужели думаешь, она единственная в своём роде? Можешь про BigData почитать, например.
    Или вот могу я хотеть обрабатывать чего нибудь 1Mb\sec? Вполне ведь! Через 1 час это уже 3600Mb. Через 10 часов это 36000Mb и т.д. В общем, шире надо мыслить просто. Сейчас, может быть, кому-то с трудом верится, что на KolibriOS можно будет делать что-то серьёзное. Но это возможно! Просто не надо себя искусственно ограничивать. Вот и всё! :)
  • Обработка UTF-8 это вообще не вычисления, говорить о производительности глупо. Переменная длинна в байтах это ерунда, вон в видеокодировании используется экспоненциальный код Голомба или вообще контекстно-адаптивные коды переменной длинный, а битрейт может быть и больше 1Mb\sec, но ничего, считает...
  • Наверно, utf8_strlen() лучше сделать ядерной для упрощения разработки и уменьшения размера приложений.
    Из хаоса в космос
  • CleverMouse wrote:Если всё будет в UTF-8, то большая часть, если не все, существующих программ вообще не заметит разницы.
    Это настолько неудобно, что этого не будет никогда.

    По крайней мере, в остальном мире выглядит именно так.
  • Who is online

    Users browsing this forum: No registered users and 3 guests