icu VS utfcpp

If you want graphemes, something lile libgrapheme might suit you. If just code points, then the utf8.h from ICU can work, but you can also roll your own if needed.

OP, is this money in the context of storing and counting money, or money in the context of internationalization and localization? For the latter, you probably want bindings to icu or the x/text/currency package.

https://github.com/unicode-org/icu/pull/2213

This affects all packages that have icu as a dependency, one of them being Node.js.

https://github.com/nodejs/node/issues/37271

I discovered this the hard way when some code malfunctioned shortly after daylight savings time kicked in.

No clue! It seems like a very deep rabbit hole to go down. You can start here: https://github.com/unicode-org/icu Version 72 I believe is when this was changed.

Installing icu4c from https://github.com/unicode-org/icu/releases/tag/release-71-1 and put the path in "--with-icu-lib"

wget https://github.com/unicode-org/icu/archive/release-58-3.tar.gz

You need something like icu. https://github.com/unicode-org/icu

ICU, which ships as part of the core internationalization and localization frameworks of every major operating system, has a facility for transliterating keyboards! This is how you can type in Roman characters and get Devanagari in text, or enter pinyin and get Han characters. You can compose a Hiragana to Latin transliteration — but it’s a stretch to get actual English words this way.

std::string is simply a string of bytes, so can already contain utf-8 encoded text. The only problem is when you want to interact with OS (Windows) API and other library APIs that don't expect utf-8 and when you need to count number of characters etc. For that you can look into existing libraries, e.g. the official Unicode ICU or whatever you can find that others have made, e.g.: https://github.com/nemtrif/utfcpp

Suffice it to say, this is a mess. However, there are libraries that make this easier.

> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age.

You don't need a UTF-8 type for that, you just need routines that handle UTF-8 strings, like utfcpp (https://github.com/nemtrif/utfcpp).