Посоветуйте ЯП

Или Rust

Нет, тут все правильно.

Чего правильного? Давай посчитаем вместе. П - 1, е - 2, н - 3, и - 4, с - 5. Всего 5 символов, а strlen сказал 10.

Про широкие символы вспомни, лол.

#include <stdio.h>
#include <wchar.h>

main()
{
    printf ("%d\n", wcslen(L"Ололо"));
}

5

Так, а теперь как из utf-8 получить вчары и наоборот?

Сторонними либами какими-нибудь. В WinAPI можно и без них вот.

Или без либ можно обойтись. man mbstowcs/wcstombs.

wchar_t (комментарий)

Ага, как и было до явы. Прогресс на лицо.

Гугл в помощь. Можно стандартными средствами.

std::codecvt

Python, Go

Питошка.

Go, java.

Про широкие символы вспомни, лол.

Проще не стало: они ОЧЕНЬ некроссплатформенны (они могут быть по 1 байту), локалезависимы в пределах платформы и не решают никаких проблем.

Посчитай число символов в строке L"Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞". Плюсы/сишка — не язык для работы со строками.

http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries — то, что обычно имеют в виду под «посчитать символы». strlen ещё нужен для подсчёта размера буфера. А wcslen() — образец ненужности.

В c++ есть utf8, utf16 и utf32 строки. libicu существует миллион лет. Что вам нужно-то?

С icu не так просто работать, как с обычными ASCII string'ами (да и с char* -строками в пределах ASCII). В других языках абстракции над строками мощнее и (что важно) все сторонние библиотеки понимают, чего от них хотят, если им скормить такие строки. В плюсах же зачастую каждая реализация строк тащит с собой все нужные функции.

Впрочем, я больше о ненужности wchar, чем о плюсах.

Однако именно на плюсах проблем никаких нет, да и вообще, можно использовать ту реализацию, которая нужна. А вот в том же Питоне, например, проблемы определённые были(сейчас, к сожалению не вспомню уже).

В других языках абстракции над строками мощнее

Да ну? std::basic_string<...> с инстансами в виде байтовых строк, расширенных символов, utf16-строк, utf32-строк. Есть возможность не только делать все, что в других языках, но и задавать разные наборы «характеристик» символов, управлять распределением памяти для строк. Для конвертации строк есть std::codecvt.

Я уже не говорю о библиотечных плюшках - icu, строки Qt и т.д. и т.п.

До явы кросскомпиляция была гемором, а деплой этого бинарника требовал копирования левых библиотек, когда go-бинарнику по большому счёту нужен только libc.

Бинарник он и есть бинарник. Никакой принципиальной разницы у go и c в этом плане нет. Кстати, я давно не смотрел, в go сочинили динамические библиотеки или догмат о ненужности динамической типизации принят окончательно?

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

SNOBOL.

Говорю же: никакие расширенные символы в basic_string не положишь, только кодпойнты (которые бесполезны если ты не разработчик библиотек). В других языках естественнее делается перебор по графеме.

icu-строки в сях/плюсах, емнип, выглядят как utf-16 строки с определёнными кастомными функциями для работы с ними.

управлять распределением памяти для строк

Руками? Говорю же: неудобно.

никакие расширенные символы в basic_string не положишь

Расскажи это std::wstring, std::u16string и std::u32string. Приведи конкретный пример, если видишь проблему.

Руками? Говорю же: неудобно.

Что руками? std::basic_string сам управляет освобождением памяти, если ты об этом. А для распределения памяти, если тебя не устраивает стандартное поведение, ты можешь написать свой аллокатор и скормить его std::basic_string.

Млин, я уже устал объяснять одно и то же 10 раз в треде. wchar — не символ и вообще undefined behaviour при попытке использовать его применительно к любому юникоду. codepoint в utf16 — не символ. codepoint в utf32 — не символ.

В строке «Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞» 6 символов. В какой std:: мне положить это, чтобы получить такую длину?

ты можешь написать свой аллокатор

А могу не писать?

В какой std:: мне положить это, чтобы получить такую длину?

Код ты можешь показать на том же Go или еще на чем?

А могу не писать?

Естественно

Может в каком-то хэш-виде, а то у меня редакторам башню сносит?

Z\xcd\x91\xcd\xab\xcd\x83\xcd\xaa\xcc\x82\xcd\xab\xcc\xbd\xcd\x8f\xcc\xb4\xcc\x99\xcc\xa4\xcc\x9e\xcd\x89\xcd\x9a\xcc\xaf\xcc\x9e\xcc\xa0\xcd\x8dA\xcd\xab\xcd\x97\xcc\xb4\xcd\xa2\xcc\xb5\xcc\x9c\xcc\xb0\xcd\x94L\xcd\xa8\xcd\xa7\xcd\xa9\xcd\x98\xcc\xa0G\xcc\x91\xcd\x97\xcc\x8e\xcc\x85\xcd\x9b\xcd\x81\xcc\xb4\xcc\xbb\xcd\x88\xcd\x8d\xcd\x94\xcc\xb9O\xcd\x82\xcc\x8c\xcc\x8c\xcd\x98\xcc\xa8\xcc\xb5\xcc\xb9\xcc\xbb\xcc\x9d\xcc\xb3!\xcc\xbf\xcc\x8b\xcd\xa5\xcd\xa5\xcc\x82\xcd\xa3\xcc\x90\xcc\x81\xcc\x81\xcd\x9e\xcd\x9c\xcd\x96\xcc\xac\xcc\xb0\xcc\x99\xcc\x97

Достаточно стандартный вид?

Можно сходить по http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries за примерами из реальной жизни.

Код ты можешь показать на том же Go или еще на чем?

Первое что нашёл в гугле на псевдокод2.7/псевдокод3.

>>> def splitclusters(s):
...     """Generate the grapheme clusters for the string s. (Not the full
...     Unicode text segmentation algorithm, but probably good enough for
...     Devanagari.)
...
...     """
...     virama = u'\N{DEVANAGARI SIGN VIRAMA}'
...     cluster = u''
...     last = None
...     for c in s:
...         cat = unicodedata.category(c)[0]
...         if cat == 'M' or cat == 'L' and last == virama:
...             cluster += c
...         else:
...             if cluster:
...                 yield cluster
...             cluster = c
...         last = c
...     if cluster:
...         yield cluster
...
>>> list(splitclusters(a))
['Z͑ͫ̓ͪ', 'A̴ͫ͗͢', 'Lͨͧͩ͘', 'G̑͗̎̅', 'Ǒ͂̌͘', '!̿̋ͥͥ']
>>> len(list(splitclusters(a)))
6

Ну, т.е. ручками. И что тебе мешает сделать так же в C++?

И сколько строк у тебя уйдёт в плюсах?

Ну и в том же псевдокоде можно лениво работать с получившимся результатом.

>>> list((x.lower() for x in splitclusters(a)))
['z͑ͫ̓ͪ', 'a̴ͫ͗͢', 'lͨͧͩ͘', 'g̑͗̎̅', 'ǒ͂̌͘', '!̿̋ͥͥ']

В перле можно чуть меньше работы руками проводить, но слишком дофига бойлерплейта, чтобы включить это.

И сколько строк у тебя уйдёт в плюсах?

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

можно лениво работать с получившимся результатом.

Ну в данном случае без yield'а в плюсах можно обойтись легко(или заюзать какую-нибудь реализацию stackless coroutine, если очень хочется).

Вообще можно заюзать сторонние регэкспы, умеющие матчить по \X (изкоробочно в новом перле) и получить решение на любом-модном-языке в 1 строку, но мы сравниваем батарейки, а не биндинги (т.к. libicu есть практически везде). Плюс я не уверен, что эти регэкспы будут достаточно быстрыми, с ручными решениями я заранее вижу, на каком уровне поддержки останавливаюсь и что подходит для данного объёма текста (генераторы — для неизвестного потенциально большого).

Аналогично, последняя java умеет многое без ручной работы (1 уровень совместимости в ней точно покрыт), но её до сих пор мало. Поэтому проще показывать на ручных примерах.

Про то, что находится вне юникода (нужно до сих пор в некоторых случаях), говорить сложнее: почти везде всё печально (POSIX-локали — яркий пример) и libicu уже не помогает.

Я в любом случае не понимаю, что ты хотел сказать. Подобные задачи одинаково геморно будет решать на любом языке. C++ же это не си, а вполне нормальный язык вполне высокого уровня. А возможностей там больше, чем в go.

А возможностей там больше, чем в go.

Это костылей, что ли?

В Go нужные и многократно проверенные возможности лидерами индустрии. Костыли С++ можно и нужно урезать в порядки раз, но поскольку он говно - больше пользы от этого не станется. С++ применяется, к сожалению, ещё будет применяться - но не потому что он хорош (ровным счётом наоборот), потому что ультраконсервативные взгляды обученных говну кукаретиков идут в разрез здравомыслию. Здравомыслие заключается в поиске компромиссов: Go один из компромиссов.

Прогресс: Asm -> C -> C++ -> Go -> … Деградация: Asm -> C -> C++ -> !Go -> C++.

http://play.golang.org/p/sYWakOqaRY

Если совсем упороться то можно и на C, только ismark определить правильно. =)

В Go нужные и многократно проверенные возможности лидерами индустрии.

В го нет обобщений, и этим всё сказано.
Если нужно что-то, действительно способное заменить c++ — есть rust. Он, кстати, более заточен на системное программирование.

В го нет обобщений, и этим всё сказано.

4.2

Если нужно что-то, действительно способное заменить c++ — есть rust.

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=...

Ну да.

4.2

http://golang.org/doc/faq#generics
Будешь спорить с официальной документацией?

Ну да.

http://www.reddit.com/r/rust/comments/1xcq1q/c_gcc_vs_rust_wtf/
Ущербность extra::bigint стандартной библиотеки. На первых порах стоило всё-таки сделать привязку в gmp.

Будешь спорить с официальной документацией?

И чё? Ты утверждал, что их вовсе нет, но: «Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.»

Он, кстати, более заточен на системное программирование.

http://talks.golang.org/2014/go1.3.slide#1

Совершенствуется уж куда лучше, чем ненужно этот ваш Rust.

Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.

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

Совершенствуется уж куда лучше, чем ненужно этот ваш Rust.

Говоря проще: развитие реализации вместо развития языка.

Ущербность extra::bigint стандартной библиотеки. На первых порах стоило всё-таки сделать привязку в gmp.

Делается любым студиозом на коленке за пару дней. Можно взять готовую (не адаптированную под 0.9) и за несколько дней допилить вместе с изучением rust-а. Никакого отличия от использования стандартной библиотеки не будет. И вообще - это далеко на самая большая проблема rust.

В Go нужные и многократно проверенные возможности лидерами индустрии

Но ведь многих из них нет - ооп, дженериков/шаблонов, исключений. Это все «многократно проверенные возможности лидерами индустрии». В любом проекте все это есть. Так что не надо выдавать желаемое за действительное.

У вас какие-то религиозные убеждения. Мой вам совет - избавляйтесь от них и бегите от тех, кто им вам внушает. C++ применяется потому, что он позволяет успешно решать поставленные задачи. Более успешно, чем какие-то другие инструменты. И это касается и других широкоприменяемых инструментов.

Go способен выйти в широкоиспользуемые языки, но не за счет C++, а скорее за счет php и python. И не потому, что какие-то «кукаретики» не захотят переходить. А потому, что go не способен решать задачи, которые решает C++, но при этом легко может заменить php и python.

задачи, которые решает C++

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

Евгений Ваганович, перелогиньтесь.

В любом проекте все это есть. Так что не надо выдавать желаемое за действительное.

А потому, что go не способен решать задачи, которые решает C++, но при этом легко может заменить php и python.

Не совсем. Большие проекты чаще всего избавляются от оверхеда и пилят свои решения. Так, например в ВК, реализовав kPHP, полностью избавились от ООП (который, по их словам, им и не нужен); Google нуждался в быстрой компиляции — результат golang.

Но вы отчасти правы: Go не решает задачи так, как это делают X- & Y-языки, он решает их по-своему и довольно-таки неплохо решает. И вы не правы — нельзя говорить о неспособности решения задач, просто они решаются по-другому (иначе смысла в новом языке нет).

А потому, что go не способен решать задачи, которые решает C++, но при этом легко может заменить php и python.

10 000 000+ строк кода гугл на неспособном go (пруф где-то в talks.golang). Если что.