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

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

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

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

5

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

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

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

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

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

std::codecvt

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

Проще не стало: они ОЧЕНЬ некроссплатформенны (они могут быть по 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 и т.д. и т.п.

Говорю же: никакие расширенные символы в 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). Если что.

И вы не правы — нельзя говорить о неспособности решения задач, просто они решаются по-другому (иначе смысла в новом языке нет).

И как go решает, например, задачи построения обобщенных алгоритмов и структур данных с учетом возможностей по управлению распределением памяти? Скажем, я выяснил, что паузы сборки мусора являются для меня критичным и я хочу избавиться от них в своем коде, заменив, скажем, на подсчет ссылок(который в моей задаче, допустим, достаточен) или вообще на простую схему передачи владения? А если одним из узких мест окажется аллокация памяти и мне захочется изменить ее алгоритм? C++(по крайней мере так делаю я) берут как раз в случаях, когда риски подобных вещей высоки. Когда нужно контролировать и производительность и расход памяти и при этом иметь возможность работать со всем этим на достаточном уровне абстракции, не в даваясь на каждом шагу в низкоуровневый код, как это приходится делать на Си.

Вот Rust мне более менее нравится, чем Go. Посмотрим, на что он будет способен после релиза... Брать Go вместо C++ я не стану, но вот на тех задачах, для которых сейчас беру питон, я обязательно Go попробую

А с чего вы взяли, что это вместо кода на C++, а не кода на том же питоне? Для гугла это не очень большая цифра, кстати.

пруф где-то в talks.golang

Пока это не пруф, а ваше высказывание о нем.

http://talks.golang.org/2014/research.slide#5

А с чего вы взяли, что это вместо кода на C++, а не кода на том же питоне?

«There are many millions of lines of software, with servers mostly in C++ and lots of Java and Python for the other pieces. Thousands of engineers work on the code, at the «head» of a single tree comprising all the software, so from day to day there are significant changes to all levels of the tree. A large custom-designed distributed build system makes development at this scale feasible, but it's still big.

And of course, all this software runs on zillions of machines, which are treated as a modest number of independent, networked compute clusters.

In short, development at Google is big, can be slow, and is often clumsy. But it is effective.

The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable. The language was designed by and for people who write—and read and debug and maintain—large software systems.

Go's purpose is therefore not to do research into programming language design; it is to improve the working environment for its designers and their coworkers. Go is more about software engineering than programming language research. Or to rephrase, it is about language design in the service of software engineering.»

Не думаю, что они разграничивают код, мол «python — переписываем, с++ — оставляем», — сомнительный эффект и, опять-таки, на этот счёт тоже есть пруф, сейчас поищу.

Это все ни о чем не говорит, к сожалению. Ладно, тут спорить бессмысленно. Будем смотреть на результат. Религиозных убеждений у меня нет, так что я даже буду рад, если go будет полезнее, чем я думаю. Но пока я просто не вижу в Go замену C++, поскольку он не умеет то, зачем C++ вообще выбирают.

Кстати, они где-то объясняют, зачем зашили csp в язык, а не включили в стандартную библиотеку, например?