std::cout is thread-safe but because of the concatenation-based API parts of the message may interleave. C++23 std::print is safe (and the output doesn't interleave).
> Using these accessors, the VMs become able to do anything that JS can do.
In fact the source language is likely to be JS itself; a JS-to-some-sort-of-vm-bytecode-to-JS compiler is made. I know that Tencent has a similar VM; an interesting aspect of that VM is that the instruction set is dependent on the code being compiled (and the opcodes are dynamically generated and shuffled when compiling), so unused instructions are not generated.
Another reason to use `void 0` is that "void 0" takes only 6 characters while "undefined" takes 9, saving some bandwidth. It is common practice for JavaScript minifiers to use this substitution.
It’s really more that there is no reason not to do it. Void is marginally safer as well as shorter, so any minifier/transpile step etc will make this substitution.
Microsoft (at least used to) require account passwords to not include the part before @ in email addresses. My email address was a@(domain).net, and therefore I was prevented from using any password including the letter "a".
The character 囍 means "double happiness" literally, and is often used in wedding ceremonies among other places here in China. It is also included in the Xinhua dictionary, the semi-official dictionary in mainland China.
> The character 囍 means "double happiness" literally, and is often used in wedding ceremonies among other places here in China.
It's used by being hung on the wall, like a painting[1]. Like I said, it has no linguistic use, and thus it is not part of a writing system, which puts it outside the stated scope of Unicode. It is the exact equivalent, for weddings, of the upside-down 福 character that is hung for New Year's, or the wreath that Americans hang for Christmas.
But it does not correspond to anything in any language; there is no Chinese sentence whose spelling would include 囍. Note that the 新华 dictionary entry says "Double 喜. Generally used at happy occasions such as weddings.", and there are zero examples of the character being used. ( https://zidian.aies.cn/NDQ4MA==.htm )
The wording of the 新华 entry is almost identical with the beginning of the 汉语大词典 entry, and it's instructive to quote the rest of the entry:
> Character used at happy occasions. Commonly called "double 喜"[2]. Generally used at occasions such as weddings. Often cut from red paper (or gold leaf), or written on red paper, [then] pasted onto a door, window, or wall, in order to indicate a happy occasion.
[1] Actually, a much closer comparison would be the traditional magical talismans that use elements from the writing system in a freeform way to express various desired goals. https://en.wikipedia.org/wiki/Fulu
[2] This dictionary is nice enough to make the fact completely explicit that 双喜 is the name of the character rather than a definition. 汉语大词典 doesn't even attempt to provide a definition for this character.
> it is not part of a writing system, which puts it outside the stated scope of Unicode.
Literally all emojis are not part of a writing system nor have proper linguistic use. Who on the earth write emoji by hand or even spoke it? Unicode already broaden the scope for so long, whether it is good or bad, nobody cares now. And beside that, a lot of symbols are also culture dependent. If you are not used to live at there, you just have no idea what it actually means.
> Literally all emojis are not part of a writing system nor have proper linguistic use.
Yes, that's true, and they've been a constant source of problems for Unicode ever since the decision was made to let them in. They stand in violation of Unicode's declared principles and purpose.
Note that 囍 is not considered an emoji by the Unicode standards, though that's what it is in fact.
> Who on the earth write emoji by hand or even spoke it?
But there is an example of this - the name of https://en.wikipedia.org/wiki/I_Heart_Huckabees [wikipedia title uses the word "heart", but the actual title uses the symbol] was frequently spoken aloud.
I think the problem of emoji are more about they are in extended plane and they are colorful. The 'utf8' in sql assume we will never use extended plain and we actually used, which is the cause of former problem. Some of the chinese characters are also suffer from the form problem. And a lot of old system just can't draw the symbol in other color because it is designed prior to the exist of emojies.
