LINUX.ORG.RU

Ответ на: комментарий от cdshines

на микроконтроллерах

На сях пишут все, что угодно. При чем здесь МК?

// кстати, на МК тоже кириллица нужна, когда отображаешь текст на LCD

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Я знаю, что что угодно, просто там, где нужно сказать пользованель не fuck off, а пнх, можно обойтись и каким-то езычком с юникодом. КАК ПУТХОН БУГАГА (это я так троллю поддержку юникода в путхоне)

cdshines ★★★★★
()
Ответ на: комментарий от cdshines

Все от задачи зависит. Если тебе компьютер нужен только для гуевых приложений, юникод — самое оно. А вот когда у тебя уйма функционала только через консоль — лучше однобайтную кодировку. Или придется только в ASCII работать.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от cdshines

А мне больше нравится, когда набираю я «тралала -h», а оно мне на родном языке списочек выдает. Правда, лукавлю я: я и в консоли gettext использую, а он через enca делает преобразование (русские строки в юникод, затем поиск по БД, затем из юникода в русские строки).

Кстати, надо будет попробовать ключи на родном языке делать. Типа «моя_программа --вывод-по-полной --запись-всего --нафиг».

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от z00ke
#include <stdio.h>

int main(int argc, char const *argv[]){
	char *buf = "123АБВ_ABC";
	for(;*buf;buf++) 
		putchar(*buf);
	putchar('\n');
	return 0;
}

не вариант т.к. уже простое сравнение

char *buf = "123АБВ_ЯЯЯЕЕЕ";
	for(;*buf;buf++)
		if (*buf == 'Я') putchar(*buf);
	putchar('\n');

не работает

sadavod
() автор топика
Ответ на: комментарий от shty

Да. wchar_t фиксированной ширины (32 вроде как), а утф8 - переменной. Нужны специальные телодвижения для работы со строками.

svu ★★★★★
()
Ответ на: комментарий от cdshines

Как будто есть разница между

run_my_pretty_program --first-key=раз --second-key=два --ignore-others
и
запустить_мою_любимую_программку --первый-ключ=раз --второй-ключ=два --нафиг-остальное

второй даже симпатичней

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

cdshines ★★★★★
()
Ответ на: комментарий от Eddy_Em

Мы там давно уже. Вот все вас ждем :)

svu ★★★★★
()
Ответ на: комментарий от svu

wchar_t фиксированной ширины (32 вроде как), а утф8 - переменной. Нужны специальные телодвижения для работы со строками.

да, костыли (а всё проклятые хиппи виноваты), но не страшные, и для мелких задачек, на крайняк, и так сгодится

но если нужно что-то серьёзное со строками делать или просто долго, или переносимое, я взял бы ICU

shty ★★★★★
()
Ответ на: комментарий от svu

4. wchar_t не годится для UTF-8

А в каком стандарте описан этот тип? В винде он 2 чара, в линуксе 4. Под андроидом 1.
Этот тип в кроссплатформенном приложении вообще не стоит использовать.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

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

Harald ★★★★★
()
Ответ на: комментарий от Harald

в C99 вполне себе описан.

Покажите, как он там описан. А потом попробуйте портировать приложение на Android.

andreyu ★★★★★
()
Ответ на: комментарий от svu

wchar_t фиксированной ширины (32 вроде как), а утф8 - переменной. Нужны специальные телодвижения для работы со строками.

Ты хочешь сказать, что wchar_t подходит только для UTF-32? Ведь UTF-16 тоже переменной длинны.

Кроме того телодвижений с wchar_t при использовании многобайтных кодировок всё таки меньше, чем с char.

kim-roader ★★
()
Ответ на: комментарий от andreyu

А в каком стандарте описан этот тип?

В C99 описан. И там сказано

3.7.3
wide character
bit representation that fits in an object of type wchar_t, capable of representing any character in the current locale

kim-roader ★★
()
Ответ на: комментарий от shty

но не страшные, и для мелких задачек, на крайняк, и так сгодится

Да-да, сгодятся. А потом какой-нибудь тролль подаст на вход й, состоящий из 2-х кодпойнтов. Вот веселья-то будет.

Поэтому и приходится юзать ICU, хучь и тяжелое оно.

Macil ★★★★★
()
Ответ на: комментарий от andreyu

Этот тип в кроссплатформенном приложении вообще не стоит использовать.

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

ЗЫ: Это вообще отличительная черта всех сишников: делать предположения, когда не твое собачье дело.

Macil ★★★★★
()
Ответ на: комментарий от Macil

А потом какой-нибудь тролль подаст на вход й, состоящий из 2-х кодпойнтов. Вот веселья-то будет.

«кикасс» успешно лечит троллей, инфа 100%

и если мне надо по быстрому чой-та там слепить, на демонстрацию proof of concept, я даже задумываться не буду

Поэтому и приходится юзать ICU, хучь и тяжелое оно.

да само ICU4C (например) не тяжёлое, там просто надо с API 1 раз поковыряться-разобраться в «евойной» логике и всё станет на свои места

shty ★★★★★
()
Ответ на: комментарий от Eddy_Em

Держать юникод только из-за символа «евро» — маразм!

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

shty ★★★★★
()
Ответ на: комментарий от shty

да само ICU4C (например) не тяжёлое

Вообще-то libicudata/icudt занимает примерно 17 метров. Хотя, наверное если уметь его готовить...

Macil ★★★★★
()
Ответ на: комментарий от Eddy_Em

Вот кстати я тоже тут на днях пацанов убеждал что юникод и всякие мудрёные utf-8 - не нужны. Не верят и всё. Я говорил, нафига нам эти азиаты со своими иероглифами, нахрена нам всю эту эзотерику тащить. Но нет же, пусть будет, ибо свят юникод и всё такое.

Hertz ★★★★★
()
Ответ на: комментарий от Macil

Вообще-то libicudata/icudt занимает примерно 17 метров.

о да, в 1991 с винтом на 20 Мб это была большая проблема

shty ★★★★★
()
Ответ на: комментарий от Hertz

К счастью, наши так не думают ☺

И вообще, никому и в голову не придет переводить наши сервера на некошерную кодировку: это же придется все заново переписывать. А там такое, что черт ногу сломит. Я сегодня ковырялся в матобесе ПЗСки, решил добавить запись в шапку фитсов всяких разных полезных данных (по поводу этого я уже ругался): оказалось, что каким-то чудом (видимо, что-то где-то в инклюдах мешало) один и тот же заголовочный файл в простеньком демоне работает (и на тип uint ругани нет), а в «камерном» матобесе — фигвам. Пришлось строить бешеный быдлокод из #pragma GCC diagnostic ignored, чтобы матюгов не было.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от andreyu

Компиляторо-платформо-зависимо. В стандарте не описано.

С90?

dimon555 ★★★★★
()
Ответ на: комментарий от andreyu

Покажите, как он там описан. А потом попробуйте портировать приложение на Android.

это же зависит от того, кто тулчейн портировал на андроид, если там заявлена поддержка c99, то всё ок для кода, который придерживается c99 и posix.2001 по-моему.

конечно, если разрабатывать в стиле - я в вищуал студии(эклипсе) проект открыл, ф9 нажал, через дебаггер отладил, какие ещё линкер, отладочная печать, консоль и прочее устаревшее posix. то так ничего не получится

dimon555 ★★★★★
()

Либо выбрать язык, который знает что такое utf-8, либо научиться работать с юникодом в си.

Наверняка в треде (который я не читал дальше заголовка) выступает местный клоун в защиту убогой кои8, не слушай его, всячески игнорируй, а если не получается, то гноби его и унижай.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox
package main

import "fmt"

func main() {
    строка := "В go нет проблем с юникодом"
    for _, אָס := range строка {
        fmt.Printf("%c_", אָס)
    }
    fmt.Print("\n")
}

Простите, не удержался.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

Наверняка в треде (который я не читал дальше заголовка) выступает местный клоун в защиту убогой кои8.

В точку же.

z00ke
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.