Есть ли жизнь на lua

для декстопных приложений

Первым будешь, дорогой.

luakit.

Достаточно прочитать в Reference Manual этого языка следующее: «Strings in Lua can contain any 8-bit value» чтобы понять, что этот язык не имеет встроенной поддержки юникода и, следовательно, не имеет права на существование в XXI-м веке.

для декстопных приложений

Adobe вроде использует.

Кстати, да, это очень печально. С точки зрения использования lua как general purpose языка, конечно.

не имеет встроенной поддержки юникода и, следовательно, не имеет права на существование в XXI-м веке

C, C++ тоже не имеют встроенной поддержки юникода, и?

Для скриптов в Premiere,Prelude,Fireworks и т.д(не все прграммы) + расширения для Адобе софта (погуглите я точно не знаю)

C, C++ тоже не имеют встроенной поддержки юникода, и?

Да ладно?

К луа тоже юникодокостыли имеются.

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

пишу на нем всякую вспомогательную скриптоту.

В каком месте стандарт C++ это костыль?

Ты дал линк на литералы. А остальное (всякие там конкатенации и подстроки) делаются через то же место, что и много лет назад.

использую lua для программирования «черепашек» из мода computercraft для minecraft. так что жизнь есть!

всякие там конкатенации и подстроки

Для multibyte конкатенаций и подстрок вообще никакой поддержки не нужно. А для действительно корректных посимвольных операций, форматирования и вывода не обойтись без ICU (которого нет почти ни в каких языках со «встроенной поддержкой юникода»). Так что разговоры о «поддержке/неподдержке юникода» в ЯП почти всегда ламерский бред.

Достаточно прочитать в Reference Manual этого языка следующее: «Strings in Lua can contain any 8-bit value» чтобы понять, что этот язык не имеет встроенной поддержки юникода

ЩИТО?

может ты про UTF-16, который принят в Windows?

Достаточно прочитать в Reference Manual этого языка следующее: «Strings in Lua can contain any 8-bit value»

и как это мешает использовать UTF-8 в строках?

Ты дал линк на литералы. А остальное (всякие там конкатенации и подстроки) делаются через то же место, что и много лет назад.

Да ладно, std::wstring - вполне себе стандартный тип, со всеми базовыми строковыми операциями. И уже давно.

и как это мешает использовать UTF-8 в строках?

Да хотя бы попробуй подстроку взять от строки символов. Не зная про UTF-8 это не получится. Потому что позиция и длина подстроки будет задаваться в символах, а не в байтах, а в случае юникода - это не одно и то же (и не только UTF-8, в UTF-16 и UTF-32 также существует возможность задать расширенный код символа, поэтому нельзя полагаться на его ширину).

А для действительно корректных посимвольных операций, форматирования и вывода не обойтись без ICU (которого нет почти ни в каких языках со «встроенной поддержкой юникода»). Так что разговоры о «поддержке/неподдержке юникода» в ЯП почти всегда ламерский бред.

Сам-то понял какой ты ламерский бред написал?

Да хотя бы попробуй подстроку взять от строки символов. Не зная про UTF-8 это не получится. Потому что позиция и длина подстроки будет задаваться в символах, а не в байтах, а в случае юникода - это не одно и то же (и не только UTF-8, в UTF-16 и UTF-32 также существует возможность задать расширенный код символа, поэтому нельзя полагаться на его ширину).

Именно такого ответа я и ожидал. А теперь включи голову и расскажи откуда у тебя возьмётся начало и длина подстроки в _символах_, а не байтах. И ты сможешь привести только искусственный пример «я так хочу - со 2 по 5 символ» что есть бред, тогда как в реальном мире позиции ты получаешь от strstr и аналогов, которым пофиг с чем работать - ASCII, 8bit или utf-8. А теперь возьмём язычок который якобы знает о юникоде и якобы сможет даже вернуть тебе с 2 по 5 символ на-гора. И что же - скармливаем ему пачку combining characters, и он вместо 4 символов вырезает тебе полтора.

Теперь тебе должно быть понятно что для подержки операций с юникодными строками либо не нужно ничего, либо нужен ICU. Всё остальное не работает, и C/C++/lua тут ничем не отличаются от «юникодных» питонов.

Да ладно, std::wstring - вполне себе стандартный тип, со всеми базовыми строковыми операциями. И уже давно.

wstring можно смывать в унитаз, потому что программе как ни крути придётся общаться с внешним миром в UTF-8. Код для конвертации в/из multibyte можешь посмотреть на stackoverflow - там страница убожища с сишными mbtowc. Стандартностью и не пахло. В то же время ICU это делает в одну строчку.

А теперь возьмём язычок который якобы знает о юникоде и якобы сможет даже вернуть тебе с 2 по 5 символ на-гора. И что же - скармливаем ему пачку combining characters, и он вместо 4 символов вырезает тебе полтора.

Ну и где пример облажания std::wstring или джавовского String?

wstring можно смывать в унитаз, потому что программе как ни крути придётся общаться с внешним миром в UTF-8

Не вижу связи. Во внешнем мире может быть хоть КОИ-8. Внешний мир - он такой изменчивый. Поэтому wstring и необходим.

Ну и где пример облажания std::wstring или джавовского String?

Вот строка из 3 символов. Я хочу получить второй и третий.

#include <iostream>
#include <locale>

int main() {
    ::setlocale(LC_ALL, "");
    std::wstring s(L">Ь̃<");
    std::wcout << s.substr(1,1) << std::endl;
    std::wcout << s.substr(2,1) << std::endl;
    return 0;
}
---
Ь

---

Для жавы сам напишешь.

Не вижу связи. Во внешнем мире может быть хоть КОИ-8. Внешний мир - он такой изменчивый. Поэтому wstring и необходим.

Прочитай десять раз в слух эту фразу, и пойми что мысли надо выражать ясно, а не бессмысленным набором слов.

А между делом расскажи как ты будешь обрабатывать юникодные (или 8-битные, не важно) argv, и куда тут ты воткнёшь свой wstring.

Вот строка из 3 символов. Я хочу получить второй и третий.

Спасибо, понял что ты имел в виду. И как ты считаешь - это врождённая проблема языка С++ или баг который пофиксится со временем?

Прочитай десять раз в слух эту фразу, и пойми что мысли надо выражать ясно, а не бессмысленным набором слов.

А между делом расскажи как ты будешь обрабатывать юникодные (или 8-битные, не важно) argv, и куда тут ты воткнёшь свой wstring.

Прочитай десять раз в слух свой ответ, и пойми что мысли надо выражать ясно, а не бессмысленным набором слов.

А между делом расскажи в чём ты видишь проблему.

Спасибо, понял что ты имел в виду. И как ты считаешь - это врождённая проблема языка С++ или баг который пофиксится со временем?

Тут нет ни проблемы, ни бага, ни чего-либо специфичного для C++. Есть непонимание у некоторых людей того, что такое юникод и как с ним надо работать. Отсюда и идиотские заявления что-де char*/std::string юникод «не поддерживает», или wchar_r*/std::wstring «поддерживает».

Так, минуточку. Ты что, считаешь что substr в случае wstring так и должен работать?

А между делом расскажи в чём ты видишь проблему.

Дурачка включил? Ожидаемо. Я жду C++ код, который возьмёт argv[1], перевернёт его задом наперёд, и скормит как аргумент в execl(«/bin/echo»). Независимо от локали и используя только std::wstring. Если, как ты утверждаешь, std::wstring - «стандартный» и «со всеми операциями» это будет не более 5 строк кода.

Так, минуточку. Ты что, считаешь что substr в случае wstring так и должен работать?

Конечно.

А почему считаешь что substr в случае wstring так и должен работать? Где в документации это сказано? Я вот открываю мануал и читаю что там всё указано в символах. Следовательно наблюдаемое тобой явление когда ты не получаешь третьего символа строки - это просто баг в реализации, а не проблема, характерная для этого языка вообще.

Дурачка включил? Ожидаемо. Я жду C++ код, который возьмёт argv[1], перевернёт его задом наперёд, и скормит как аргумент в execl(«/bin/echo»). Независимо от локали и используя только std::wstring.

Хмм.. А почему ты ждёшь такой код?

Если, как ты утверждаешь, std::wstring - «стандартный» и «со всеми операциями» это будет не более 5 строк кода.

Во-первых я не нахожу очевидным утверждение «это будет не более 5 строк кода»

Во-вторых когда я говорил про операции, речь шла про с wstring. По-моему это ты дурачка включил и вряд ли сможешь нам объяснить с какого это перепугу wstring вдруг должен знать про все возможные кодировки, которые могут присутствовать в ОС.

Вобщем-то это в тебе ламера и выдаёт, что ты не видишь где кончается ЯП и начинаются функции ОС.

кто нибудь использует lua не для скриптоты, а для декстопных приложений?

Краткий ответ — нет.

Подробно: lua — встраиваемый язык, и практически не встречается в чистом виде. Однако, например тот же textadept написан по большей части именно на lua, кода на си там совсем немного.

в играх сплошь и рядом

А почему считаешь что substr в случае wstring так и должен работать?

Потому что wstring - массив широких символов, и substr должен выдавать заданный его подмассив, не больше и не меньше.

Где в документации это сказано? Я вот открываю мануал и читаю что там всё указано в символах.

Это сказано в N1256 (C99) глава 3 «terms, definitions, and symbols», 3.7.3. wide character, 3.7. character. N3242 (драфт C++11) 21.3. String classes.

Следовательно наблюдаемое тобой явление когда ты не получаешь третьего символа строки - это просто баг в реализации, а не проблема, характерная для этого языка вообще.

Есть хорошее правило - когда хочешь сказать или написать словосочетание «баг в реализации» сначала возьми лист бумаги и напиши на нём развёрнутое доказательство того, что баг не в реализации тебя. Это не наезд, просто правильный подход.

Проблема в том что ты используешь бытовое понимание символа, тогда как машина оперирует низкоуровневыми абстракциями. Так должно быть потому что на низкоуровневых абстракциях можно строить высокоуровневые. Поэтому строка - это просто набор чисел той или иной размерности, а вот вещи, реализующие различные бытовые её семантики уже накручиваются сверху. Это, к примеру, уже упомянутый ICU, умеющий различать свойства отдельных символов юникода и их комбинаций, или freetype, который умеет их рисовать. Это узкие задачи и в ядре ЯП общего назначения им делать нечего. И это, повторюсь, никак не специфично ни для конкретной реализации C++, ни для C++ вообще. Perl и Python, к примеру, абсолютно ожидаемо ведут себя также.

Хмм.. А почему ты ждёшь такой код?

Потому что ты выглядишь как будто хочешь тут что-то кому-то доказать, как минимум что ты не полный профан? Ибо иначе ты обычное анонимное тролльё. В любом случае, с тобой мы закончили.

В современных ЯП для внутреннего представления строк используется UCS, проблема кодировок решается преобразованием.
Но в Си++ нет строк, там есть только массив байтов, причём он может быть любой кодировки.

Потому что wstring - массив широких символов, и substr должен выдавать заданный его подмассив, не больше и не меньше.

А он не выдаёт, вот беда.

Это сказано в N1256 (C99) глава 3 «terms, definitions, and symbols», 3.7.3. wide character, 3.7. character. N3242 (драфт C++11) 21.3. String classes.

Там (я посмотрел второй документ, первого у меня нет) нигде не сказано что substr должна вести себя описанным тобой образом.

Есть хорошее правило бла-бла-бла

Кого волнуют твои личные правила, которые у тебя есть? Символ есть символ, всё очень просто. Если сказано, что речь идёт о символе - символ и должен возвращаться, а не какой-то там фрагмент низкоуровневой абстракции.

Потому что ты выглядишь как будто хочешь тут что-то кому-то доказать, как минимум что ты не полный профан? Ибо иначе ты обычное анонимное тролльё. В любом случае, с тобой мы закончили.

Ты какой-то необычный ребёнок. Сам ворвался в тред с криками «Для multibyte конкатенаций и подстрок вообще никакой поддержки не нужно», а когда до твоих воплей снизошёл анонимус и попытался тебя понять - ты чего-то надулся и внезапно закончил, обзываясь при этом тролльём :)

Кого волнуют твои личные правила, которые у тебя есть? Символ есть символ, всё очень просто. Если сказано, что речь идёт о символе - символ и должен возвращаться, а не какой-то там фрагмент низкоуровневой абстракции.

Ну дальше продолжать нет смысла, теперь дело только за тобой - пошевелить мозгами и понять. До тех пор можешь плакаться родителям что никто не разделяет выдуманного тобой тёплого лампового определения символа, грузит какими-то абстракциями, а wstring не нормализует юникод и не варит кофе, хотя обещал.

что никто не разделяет выдуманного тобой тёплого лампового определения символа

В го есть тип rune, отвечающий за unicode code point.
Твой аргумент некорректен.

Вообще тут дело такое, что вопросами локали и трансляции заведует ОС. В ней это всё равно должно быть реализовано. Поэтому совершенно избыточно и неэффективно реализовывать поддержку этих вещей на уровне каждого языка программирования, хуже того - это в общем случае и невозможно. Язык просто должен знать что это - юникод и уметь скармливать его системе. И всё.

С другой стороны поддержка юникода на уровне ОС пока ещё представляет из себя сплошной баг. Например строку «>Ь<», которую пострадавший привёл в своём примере выше по треду, из-под венды вижу с тильдой над знаком «Ь», а если взглянуть из-под линукса, то в той же строке, чем ни смотри эту страницу, а тильда располагается над символом «<».

Следовательно в одной из ОС средства для работы с юникодом глючат (конечно не в стабильном линуксе,а наверняка в кривой венде, гы) и возможно автор просто тестировал свою программу в неправильной ОС и решил, что так и надо :)

На практике же ОС ничего не умеет, и нужно или транслировать ввод/вывод, или использовать UTF-8, полагаясь на то, что никто в XXI веке не будет использовать какой-нибудь KOI8-R.
Но в любом случае, строки в юникод-совместимом ЯП имеют одит формат, и функции стандартной библиотеки обязаны корректно работать с ними.

То, что некоторые ОС на практике работают с юникодом както иначе нежели предполагается - это проблемы ОС, а не языка. Язык должен понмать, что ему дали юникод и как его скормить системным вызовам на конкретной платформе - и всё. Сам по себе юникод тоже вещь не статичная и развивается, в т.ч. и алгоритмы работы с ним развиваются и пишут их возможно на тех же сишечках - поэтому в стандарте языка просто технически быть не может ещё и стандарта юникода.

или транслировать ввод/вывод, или использовать UTF-8, полагаясь на то, что никто в XXI веке не будет использовать какой-нибудь KOI8-R.

Наоборот, я предполагаю, что в системе теоретически может оказаться своя самодельная уникальная и неповторимая кодировка что сразу делает перекодировку в программе бессмыссленной. Да и вообще, глупо же каждую программульку уровня хелловорлда снабжать таблицами перекодировки, таблицами сортировки по правилам языка, библиотеками для взятия n-го символа и т.п.? Эту функциональность должна предоставлять система.

Но в любом случае, строки в юникод-совместимом ЯП имеют одит формат, и функции стандартной библиотеки обязаны корректно работать с ними.

Да, но делать они это могут так же как они работают с устройствами ввода-вывода например. Т.е. вызывая функции платформы.

Более того, не все из наиболее распространенных операционных систем имеют одинаковую кодировку файловой системы и локали. Мак например всегда хранит имена файлов в корректном UTF-8 (емнип NFD), независимо от текущей локали. Perl кстати, зная такой расклад, возвращает и принимает вместо строк неперекодированные октеты в функциях типа readdir, -X и т.п., даже если use encoding/utf8; use feature 'unicode_strings'; use open ':locale'; — то есть даже при полном объюникоживании рантайма.

Я использую lua для автоматизации запуска расчетного кода (как и Tcl, кстати). Сам суди, скриптота это или нет.

Perl кстати, зная такой расклад, возвращает и принимает вместо строк неперекодированные октеты в функциях типа readdir, -X и т.п., даже если use encoding/utf8; use feature 'unicode_strings'; use open ':locale'; — то есть даже при полном объюникоживании рантайма.

Это разве не дефолтное поведение? В никсах до сих пор живо бессчётное количество утилит, которые про юникод слыхом не слыхивали, но за счёт того, что UTF-8 с их точки зрения представляет из себя корректную ASCIIZ-строку никто и не замечает их кривизны.

Кстати, я недавно попытался послать сообщение на русском языке используя штатную команду линупса «wall». Как оказалось, она не просто посылает байты, а пытается замены букв в тексте делать, в результате чего на выходе получается мусор.

Ты удивишься, но wchar_t тоже ни что иное как code point. go'шные rune и package utf8 это прямые аналоги wchar_t и mb*towc*/wc*tomb* функций.

Есть UTF8, все остальное не имеет права на существование в XXI-м веке.

http://industriousone.com/premake - большая часть кода на Lua