Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Apr 23, 2019 11:45 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 236 posts ]  Go to page Previous 110 11 12 13 1416 Next
Author Message
PostPosted: Sun Dec 04, 2016 2:21 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
Так, ладно, это обсуждение длится достаточно долго чтобы продемонстрировать, почему я люблю сначала делать, а разбираться потом.
Все проходящие - голосуйте мнением.


Top
   
PostPosted: Sun Dec 04, 2016 3:44 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
0CodErr wrote:
Ну с таким же успехом и от мьютексов можно отказаться тогда. У нас приложения могут быть многопоточными.
При чём здесь мьютексы. Ты, образно говоря, предлагаешь дать возможность одному потоку в многопоточном приложении считать в миллиметрах, а другому в дюймах. Это ещё один способ выстрелить себе в ногу.
0CodErr wrote:
ОДИН раз ты переключился, и дальше работаешь в юникоде. Если когда-нибудь захотел обратно в ASCII, то также только ОДИН раз вызываешь.
И весь этот геморрой с переключением только ради файловых функций. Вангую массу вопросов от новичков почему у них крякозябры в заголовке окна, в BOARD и т.п.


Top
   
PostPosted: Sun Dec 04, 2016 3:58 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Pathoswithin
Да, всё начало вырождаться в пустой трёп. Моё мнение:
1. Путь в приложение передавать в utf-8. Предупредить о проблемах с именами директорий в русской кодировке.
2. Добавить utf-8 подфункции к ф.70 и ф.30. Никаких ASCII/UNICODE режимов приложения в ядре не городить.


Top
   
PostPosted: Sun Dec 04, 2016 9:46 pm 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 455
Согласен с Serge. Где можно, новые подфункции в utf8, где нельзя - только utf8. Минимум несовместимостей, даи потом проще будет убирать устаревший ascii из ядра.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Top
   
PostPosted: Mon Dec 05, 2016 1:14 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
На самом деле делать подфункции к ф.70 не желательно, так как параметр передаётся в структуре и редактировать его нельзя. Я планирую сделать две копии ф.70: для UTF-8 и UTF-16. Одна из них будет 80, а другая - 79, 81 или 32. Выбирайте.
Остальное ограничится новыми подфункциями.


Top
   
PostPosted: Tue Dec 06, 2016 2:32 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Serge wrote:
Ты, образно говоря, предлагаешь дать возможность одному потоку в многопоточном приложении считать в миллиметрах, а другому в дюймах. Это ещё один способ выстрелить себе в ногу.
Ну это ты уже из пальца проблему высосал. :lol: Так как, это отнюдь не мешает устанавливать различные маски событий(event_mask) или режим ввода с клавиатуры(keyboard_mode), например.
Serge wrote:
Вангую массу вопросов от новичков почему у них крякозябры в заголовке окна, в BOARD и т.п.
Ровно такие же кракозябры, как и в первом сообщении этой темы. Вообще, таких переключений может и не быть: сначала encoding устанавливается в заголовке приложения, затем, если приложение грузит библиотеки, то там нужно ASCII, также, возможно, при обработке CmdLine. Всё! Больше переключаться не нужно!
Pathoswithin wrote:
Я планирую сделать две копии ф.70: для UTF-8 и UTF-16.
Serge wrote:
Ядро не безразмерно.
:mrgreen: Но лучше уж хотя бы так. Только ещё надо будет GetAppPath и GetCommandLine сделать для разных кодировок. Если, конечно, не планируется использовать поле encoding в заголовке.
UTF-8 это прежде всего тормоза. Очень странно хотеть её использовать в такой системе, как KolibriOS. Она и была разработана ради совместимости с ASCII, но только в KolibriOS нет такой проблемы в силу отсутствия большого количества приложений, нуждающихся в такой совместимости. Так что, такую кодировку стоит использовать просто как ещё одну, не более.

Как я понял, вместо добавления одной сисфункции для переключения кодировки будут продублированы все. Ну что ж, так, конечно, лучше, ведь это не раздует ядро :lol: :mrgreen: Сами себе противоречите!


Top
   
PostPosted: Tue Dec 06, 2016 5:33 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
Так как, это отнюдь не мешает устанавливать различные маски событий(event_mask) или режим ввода с клавиатуры(keyboard_mode), например.
Тяжёлое наследство тёмного прошлого. Хотя в различных масках событий может быть смысл.


Top
   
PostPosted: Tue Dec 06, 2016 5:41 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Serge wrote:
в различных масках событий может быть смысл.
Ну, разумеется, он там есть. Например, браузеру нужны сетевые события. Но при этом меню браузера в них совершенно не нуждается.


Top
   
PostPosted: Tue Dec 06, 2016 5:45 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
Ты не поверишь, но всё это займёт в ядре несколько десятков байт.
Как UTF-8 связана с тормозами (даже не учитывая скорость работы дисковой системы)? В UNIX это основная кодировка.


Top
   
PostPosted: Tue Dec 06, 2016 5:50 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Тем не менее индивидуальные маски событий не оправдывают индивидуальны режимы кодировки. Кстати, некоторые длл могут создавать свои потоки. Например console. В этом случае индивидуальные режимы ascii/unicode сделают всё ещё запутанней.


Top
   
PostPosted: Tue Dec 06, 2016 5:56 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Pathoswithin wrote:
Ты не поверишь, но всё это займёт в ядре несколько десятков байт.
Добавление только одной функции займёт ещё меньше.
Pathoswithin wrote:
Как UTF-8 связана с тормозами (даже не учитывая скорость работы дисковой системы)? В UNIX это основная кодировка.
Как я писал уже выше, во всех строковых функциях потребуется больше проверок, так как символ может быть представлен 1|2|3|4 байтами. В то время как UTF-16 2|4, UTF-32 4, а ASCII 1. Вот и выходит, что UTF-8 самая тормозная из них.
Да, и у нас вовсе не UNIX. Нет смысла равняться на это. Если тебе нужен UNIX, бери UNIX и используй его в своих целях.

Serge wrote:
Тем не менее индивидуальные маски событий не оправдывают индивидуальны режимы кодировки.
Конкретика?

Serge wrote:
В этом случае индивидуальные режимы ascii/unicode сделают всё ещё запутанней.
Запутанней для кого? Приведи пример проблемы, я скажу тебе, как её можно решить.


Top
   
PostPosted: Tue Dec 06, 2016 6:12 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
Копеечные расходы тормозами не называются.
Вообще-то я сейчас как раз POSIX ублажаю. Если тебе не нужен UNIX, то чем тебе маркеры не нравятся? Тоже вполне чёткий стандарт.


Top
   
PostPosted: Tue Dec 06, 2016 6:18 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Pathoswithin wrote:
Если тебе не нужен UNIX, то чем тебе маркеры не нравятся?
А зачем их лепить к каждой строке, если можно проверить только APPDATA.Encoding?

Pathoswithin wrote:
Копеечные расходы тормозами не называются.
Только здесь не про копеечные речь. Дополнительные проверки на каждый символ.


Top
   
PostPosted: Tue Dec 06, 2016 6:35 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
А затем, что с таким стандартом можно было бы иметь дело с разными кодировками одновременно, но вообще не задумываться об этом.

Ты собираешься проверять миллиард символов?


Top
   
PostPosted: Tue Dec 06, 2016 7:06 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Pathoswithin wrote:
иметь дело с разными кодировками одновременно
А зачем это надо? Пример можешь привести?
Pathoswithin wrote:
Ты собираешься проверять миллиард символов?
...и даже больше, вот и посчитай насколько это медленнее будет


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 236 posts ]  Go to page Previous 110 11 12 13 1416 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited