Здравствуйте, Anton Batenev, Вы писали:
AB>Смотря что ты подразумеваешь под "обработкой текстов".
Типичные операции, вроде поиска символа в строке вперед/назад, поиска/замены подстроки, разбора строки, регулярных выражений и т.п.
AB>Для большинства программ нет никакой разницы в какой кодировке у тебя лежат данные в char* потому что тебя интересует только размер буфера памяти и работа ведется с абстрактными байтами.
Это лишь в том случае, когда строка представляет собой лишь текст для хранения/сравнения — идентификатор, название и подобное. А в той же файловой системе обработка имен/путей/шаблонов идет массово.
Здравствуйте, rean, Вы писали:
R>То, в каком виде сейчас пребывает web — следствие постепенных приспособлений к текущим потребностям, которые плавно нарастали все эти годы.
То, что рядовым пользователем востребованы "интерактивные сущности" в виде сперва Flash-, а потом и JS-скриптов, стало понятно еще пару десятков лет назад. То, что большая часть сайтостроителей совершенно невоздержана в ресурсах, и способна сожрать все, что дадут, было понятно тогда же. О том, что не стоит делать из браузера среду исполнения произвольного кода, тоже говорили давно, но эта идея почему-то не нашла отклика у разработчиков браузеров и ОС.
R>Так что веб сейчас — большой неудобный костыль на костыле. Все плюются, но альтернативы нет и соскочить нельзя, потому что на него завязаны все.
На кой хрен тогда существует W3C?
R>Подобная фигня сложилась практически везде, куда ни ткни вокруг компьютеров.
На локальном компьютере и проблемы в основном локальные, и альтернативы есть.
Здравствуйте, rean, Вы писали:
R>Но в винде 2 байта эту проблему не решают, потому как юникод в два байта не умещается.
И что же решает эту проблему в винде? Она внутри вся на фиксированном двухбайтном юникоде. Или Вы о каких-нибудь экзотических языках, которые используются максимум в нескольких тысячах компьютеров на всю планету?
R>Ну или молиться и думать, что все работает, уповая на то, что у юзера вряд-ли затесется какой-нибудь случайный расширенный символ, да и еще он не окажется важным с точки зрения бизнес-логики.
Какова, по-Вашему, удельная доля программ, которым могут потребоваться такие символы? Хоть 0.1% наберется? Стоят ли они того, чтобы поддерживать кодировку с переменной шириной символа во всех системных API?
R>случайно символы разделения путей и т.п. никак не появляются.
Да, пример с ФС был не совсем удачным. Но те же регулярные выражения, которые в унихах чуть более, чем везде?
R>Поэтому для программиста это эквивалентно работе с ASCII
Только в самых простых случаях. Например, весьма типичная операция — по позиции символа в строке определить его знакоместо. В ANSI/UNICODE делается элементарным вычитанием, а в линуксах для этого потребуются специальные функции? Вывод таблицы на консоль уже должен выглядеть нетривиально.
Здравствуйте, rean, Вы писали:
R>М̺͕̝̹̙͓̜ͨͤ̈́̆н̵͔̦ͮͮ̒̒е̼̭̬͋ ̮̟̣̀͐ͯ̑̕к̠͎̘̩͈̺̄ͩ̃ͪ̅ͯ̿͘ͅ
Сколько человек в мире хотело бы использовать перечисленные символы в именах устройств/файлов/каталогов, подписях к значкам, названиях профилей и подобных общесистемных текстовых объектах, но не может этого сделать из-за ограничений на реализацию Unicode в винде? А то ведь кто-то может захотеть оформить разные части имени файла шрифтами разных типов и кеглей — может, и это тоже поддерживать на уровне системных API?
R>PS. Проблемы с юникодом начинаются даже для немецкого языка: R>https://docs.microsoft.com/en-us/windows/desktop/intl/using-unicode-normalization-to-represent-strings
Эти проблемы есть для любого языка, письменность которого не исчерпывается чистой латиницей. Только вот как они решаются с помощью кодирования в UTF-8 вместо двухбайтового Unicoide?
V>3. Разработан небольшой набор собственных API, которые общаются с операционкой (все строковые параметры и результаты функций тоже UTF8). Например для Windows внутри API идет конвертация в wstring и обратно. V>4. Для GUI выбрали QT, с которым пришлось немного пот...ся при разработке стилей под разные операционки (подогнать отступы в виджетах и т.п.), но это разовый гемор.
скажите пожалуйста как вы решали вопрос с лиицензией Qt
купили лицензию
или готовы показать исходник если кто то начнет настойчиво требовать
Здравствуйте, drVanо, Вы писали:
V>Хочу поделиться нашим опытом в разработке кроссплатформенных приложений: в свое время писали продукты на Delphi, от которого стало дурно пахнуть, и решили переписали свой флагманский продукт на C++, причем изначально в архитектуру были заложена кроссплатформенная архитектура:
Странно, что в описании на сайте это вообще не упоминается. Везде говорится только про Windows.
Ссылки на MacOS/Linux увидел только на странице скачивания, без пояснений.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> AB>Смотря что ты подразумеваешь под "обработкой текстов". ЕМ> Типичные операции, вроде поиска символа в строке вперед/назад, поиска/замены подстроки, разбора строки, регулярных выражений и т.п.
Скорость данных операций аналогична скорости при работе с однобайтовыми кодировками с поправкой на увеличение размера памяти, который требуется для юникода, и необходимость анализировать старшие биты для вычисления смещения до следующего символа. Другими словами, overhead будет незаметен пока тебе не требуется обрабатывать терабайты/петабайты информации.
Это при условии, что под словом "символ" ты понимаешь unicode code point (т.е. без процесса нормализации, смены регистров / капитализации и вот этого всего веселья).
ЕМ> AB>Для большинства программ нет никакой разницы в какой кодировке у тебя лежат данные в char* потому что тебя интересует только размер буфера памяти и работа ведется с абстрактными байтами. ЕМ> Это лишь в том случае, когда строка представляет собой лишь текст для хранения/сравнения — идентификатор, название и подобное. А в той же файловой системе обработка имен/путей/шаблонов идет массово.
В большинстве файловых систем (в linux) имя файла — просто набор байт (удовлетворяющий условию типа отсутствия '/' и 0x00). В какой они кодировке — это исключительно вопрос предпочтений пользователя.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>То, что рядовым пользователем востребованы "интерактивные сущности" в виде сперва Flash-, а потом и JS-скриптов, стало понятно еще пару десятков лет назад. То, что большая часть сайтостроителей совершенно невоздержана в ресурсах, и способна сожрать все, что дадут, было понятно тогда же. О том, что не стоит делать из браузера среду исполнения произвольного кода, тоже говорили давно, но эта идея почему-то не нашла отклика у разработчиков браузеров и ОС.
Когда-то анимированная гифка была пределом мечтаний у рядового пользователя. Сейчас я как рядовой пользователь веба умоляю веб-деятелей "Астана... Астанавитесь!!111" но они вошли в раж как новый русский на 600 мерседесе. Всё улучшают и улучшают там, где всё и так уже хорошо. Скажем, тот же gmail — он даже на нынешних JS-движках уже давно вынужден рисовать прогресс-бар загрузки. И "пользователем имени меня" это очень невостребовано.
ЕМ>На кой хрен тогда существует W3C?
Стандарт на костыли лучше, чем костыли без стандарта. Но растущая монополизация хром-движка имеет все шансы превратить W3C в чисто номинальную структуру, куда Google будет присылать сведения исключительно уведомительным характером, постфактум. И то не все.
Здравствуйте, drVanо, Вы писали:
V>Qt нужно только в GUI версии (ессно с использованием Qt-ных строк). Само ядро, с которым работает GUI и консольная версии, написано на std::string.
Qt, поддерживаемое Qt Company, это ведь как раз и есть общий знаменатель зачем же в ядре уходить от него?
Вы, уважаемый drVanо, как я понял, предлагаете делать ядро на чистом STL? Верно?
Или только с поддержкой стандартных строк (где всё не просто с Unicode)?
Я поясню мою мысль подробнее:
Qt — он и в Африке Linux есть Qt.
В то же время, версия STL редакции MSVC, хоть незначительно, но отличается от версии gcc/g++
P.S. Знаком с проблемами не понаслышке — относительно недавно портировал некоторые мои разработки с Windows на Linux/Ubuntu.
Здравствуйте, AlexGin, Вы писали:
V>>Qt нужно только в GUI версии (ессно с использованием Qt-ных строк). Само ядро, с которым работает GUI и консольная версии, написано на std::string.
AG>Qt, поддерживаемое Qt Company, это ведь как раз и есть общий знаменатель зачем же в ядре уходить от него? AG>Вы, уважаемый drVanо, как я понял, предлагаете делать ядро на чистом STL? Верно?
Для того чтобы выкопать ямку глубиной 30 см совершенно необязательно покупать экскаватор Набора лопат из STL соседнего хозяйственного магазина хватит на многие годы вперед.
AG>Или только с поддержкой стандартных строк (где всё не просто с Unicode)?
У вас сложилось неправильное представление, что у нас "всё не просто с Unicode". Скорее наоборот — все очень просто, если изначально отказаться от использования std::wstring (к слову сказать для компиляторов под OSX/Linux wchar_t имеет размер 4 байта и не имеет ничего общего с wstring под Windows) и использовать только std::string. В нашем случае преобразования UTF8 в UTF-16 нужны только при вызовах виндовых API, поэтому в качестве стандартного контейнера под хранения строк был выбран std::string, а платформозависимый слой был вынесен в отдельный набор API, где уже делаются (или не делаются) необходимые пребразования.
AG>Я поясню мою мысль подробнее: AG>Qt — он и в Африке Linux есть Qt. AG>В то же время, версия STL редакции MSVC, хоть незначительно, но отличается от версии gcc/g++
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну не должен браузер выполнять роль виртуальной машины для приложений с заранее неизвестным поведением и неограниченными требованиями к ресурсам. В HTML давно надо было оставить какой-нибудь среднефункциональный огрызок JS, с жестким ограничением по ресурсам, чтоб не мешал серфингу, а веб-приложения исполнять в отдельном VM Executive, навроде Dalvik/ART, хоть встроенном в ОС, хоть ставящемся сбоку.
и разрешать установку и запуск только за подписью цифровой лично БГ
у вас пардон мышление извращенного драйверо-писателя
Все пошло совершено против вашего направления и это очень хорошо.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, paradoks, Вы писали:
P>>у вас пардон мышление извращенного драйверо-писателя
ЕМ>Угу, а у Вас — мышление типичного хомячка.
P>>Все пошло совершено против вашего направления и это очень хорошо.
ЕМ>Для хомячков оно пошло исключительно хорошо — "тыц, и работает". А какие технические и идеологические извращения за этим стоят — им по барабану.
и это правильно, вам против течения не удастся плыть...
Набора лопат из 
