Ну в россии какбе сейчас тоже кассовые аппараты отображают цены в рублях с двумя разрядами (ща специально на чеке из супермаркета посмотрел), не вижу и тут особенной разницы.
Евро делится на сто частей, одна сотая часть официально называется «Euro Cent» (см. картинку ниже), цен в евро с тысячными не бывает (если не брать в расчет упомянутых криворуких программистов). Это и есть эквивалент копейки, во всех смыслах.
Товарисч знатный вирусный маркетолог, вы не ленитесь в следующий раз хотя б первый абзац сочинить помощнее, там, «нашел в мешке с картофельными очистками на заднем дворе Прохорова», или, я не знаю, «спер из нижнего стола ящика Яковлева», а то что это такое, «не скажу откуда, но у меня есть скриншоты»…
Я отвечу на вопрос 1: возникает, это 8 байт на символ, поэтому очень большие строки лучше как binary держать (но с другой стороны, с большими строками редко надо производить какие-то нетривиальные строковые операции).
Не, на самом деле там есть функции в xmerl (только они в документации не описаны ;) которые utf-8/16/32 что угодно парсят в список юникодных символов и обратно, и дальше с ним можно работать как с обычными строками.
Ну у каждого символа в юникоде есть номер, логически, без ограничения на разрядность, он называется code point.
А для того чтобы эти номера хранить в памяти, они каким-то образом кодируются (UTF-8, UTF-16, UTF-32..) в бинарную форму. В UTF-32 вот тупо номер code point'а записывается как 32-битный unsigned int, например.
Не все так ужасно, на самом деле, есть сторонние библиотеки для юникода, и даже в стандартных библиотеках можно найти функции преобразующие utf-8 binary в список unicode code points, дальше с ним можно нормально работать уже как с обычным списком. Особенных велосипедов не требуется изобретать. Хотя, конечно, хотелось бы чуть более серьезную поддержку юникода «из коробки», и вроде как это скоро обещают.
Сишные либы, конечно, можно прикрутить, правда пока нету для этого таких удобных инструментов, как для питона.
> «исправно платив за квартиру 15 лет, можно не дотянуть пару лет и потерять всё. „
Ну какбе не совсем все, останешься с приличной суммой денег (цена квартиры через 15 лет за вычетом недовыплаченной части кредита).
Нет, в эрланге нету специального объекта для юникода, и это иногда не очень удобно (по сравнению с питоном). Эрланг вообще очень минималистичный такой язык, авторы его специально делали попроще, чтоб порог вхождения снизить как можно сильнее.
По мне, кстати, идеально было бы иметь удобный способ интеграции его с питоном (все хочу сам как-нибудь написать, но времени не хватает) — и на эрланге делать всю распределенную/управляющую часть, а на питоне всякую сложную обработку данных, куча полезных питонских библиотек очень пригодилась бы тут.
Евро делится на сто частей, одна сотая часть официально называется «Euro Cent» (см. картинку ниже), цен в евро с тысячными не бывает (если не брать в расчет упомянутых криворуких программистов). Это и есть эквивалент копейки, во всех смыслах.
Незачет!
В конце концов все эти «ведущие аналитеги», действительно, такие забавные парни временами.
Ко второму вопросу присоединяюсь :)
print "%s \n" % (repr(A)),
Т.е. массив этот — это строковое представление A, а пробел и \n идут как есть в stdout.
io:format это аналог print, а если нужен sprintf то надо использовать io_lib:format().
А для того чтобы эти номера хранить в памяти, они каким-то образом кодируются (UTF-8, UTF-16, UTF-32..) в бинарную форму. В UTF-32 вот тупо номер code point'а записывается как 32-битный unsigned int, например.
Сишные либы, конечно, можно прикрутить, правда пока нету для этого таких удобных инструментов, как для питона.
Ну какбе не совсем все, останешься с приличной суммой денег (цена квартиры через 15 лет за вычетом недовыплаченной части кредита).
По мне, кстати, идеально было бы иметь удобный способ интеграции его с питоном (все хочу сам как-нибудь написать, но времени не хватает) — и на эрланге делать всю распределенную/управляющую часть, а на питоне всякую сложную обработку данных, куча полезных питонских библиотек очень пригодилась бы тут.