LINUX.ORG.RU

История изменений

Исправление Moisha_Liberman, (текущая версия) :

Какой нативный строковый тип данных в линукс

В С (Linux) нет аналогов CString или QString. В C нет вообще ничего похожего на string, если честно. Т.е., так, чтоб содержало длину строки + содержимое строки как минимум, а как максимум ещё и функции по работе с такого рода «строками». В С есть только «массив (array) символов». А уж какой он будет… Это дело десятое. Может представляться как int *, может как char * и в системе, которая полностью UTF-8 (ну, то есть там всё – и консоль и DE utfнутые), там совершенно пофиг. Все ф-ии, работающие с массивами, типа snprint()/printf()/sprintf()/read()/write/…, короче, все ф-ии ввода-вывода (точнее, все функции, без уточнения для ввода-вывода они или нет) будет работать с UTF-8 и можно не париться особо по данному поводу. Даже ф-ии по работе с регулярными выражениями, и те будут вести себя «прилично».

Исходная версия Moisha_Liberman, :

Эмм...

Какой нативный строковый тип данных в линукс

В С (Linux) нет аналогов CString или QString. В C нет вообще ничего похожего на string, если честно. Т.е., так, чтоб содержало длину строки + содержимое строки как минимум, а как максимум ещё и функции по работе с такого рода «строками». В С есть только «массив (array) символов». А уж какой он будет… Это дело десятое. Может представляться как int *, может как char * и в системе, которая полностью UTF-8 (ну, то есть там всё – и консоль и DE utfнутые), там совершенно пофиг. Все ф-ии, работающие с массивами, типа snprint()/printf()/sprintf()/read()/write/…, короче, все ф-ии ввода-вывода будет работать с UTF и можно не париться особо по данному поводу. Даже ф-ии по работе с регулярными выражениями, и те будут вести себя «прилично».