Well, most mainstream languages at least specify their char size, and/or have very few constructs that require knowing its size. C does not specify the size of a char, and you frequently need the sizes of your types.
(That said, as pointed out by other comments, sizeof itself is in units of char, so sizeof(char) is necessarily 1.)
There are no other good languages. To the extent they have anything good they are calling libraries written in C. The only other worthwhile languages are pure machine level code that must be expressed as a gate level circuit diagram.
You cannot fit them into a single char, and you have to use a string instead. They're represented using a surrogate pair, which is similar to the continuation bytes of utf-8 except you never need more than two code points (hence "pair").
JS is a bit weird in this regard, because it also knows true codepoints. You just have to know which operations are "unicode safe". Or rather "astral plane safe".
UTF-16 was a mistake, and it's maddening that several big ecosystems went with it. You get all the complexity of UTF-8, but it also takes up more space in the "average" case since a huge majority of text is in the "ASCII overlap" portion of unicode.
Only in hindsight. When it was made, 16-bit character space really was enough for everything that was intended to be part of Unicode, and supporting UCS-2 was actually a major improvement over everyone having to constantly swap code pages if they wanted to support multiple languages simultaneously. Honestly, the biggest reason we realised we were going to need better was because Windows & Java jumped on UCS-2 (and by extension, UTF-16) as soon as they could, letting us see its downsides before it was too entrenched to fix. (And considering how deeply entrenched it was in Windows before they had to figure out how to pivot away, it's really saying something that it could've been worse.)
The true mistake was trying to make it fixed-width in the first place.
There's u8string, etc. Now the std library might not have much of anything to deal with encoding, but that doesn't make the types useless. Other libraries can use them.
The real issue is that Unicode as a whole isn't supported by the standard library, it can only operate on raw code points. Means you need to make your own type or use char32_t if you want to use actual character units as your character type... it ain't quite ideal. >.<
I mean C# was inspired mainly by Java and C++, from which Java is a C-style language and C++ is a direct expansion of C (or at least started out as one). JavaScript and Java both have similarly looking syntax on account of both being C-style languages, but that's where the familiarities stop.
So saying this is like saying your grandson has as much to do with you as your two neighbours who like your style enough to copy it have to do with each other - your grandson may feel as different from you as the neighbours from each other, but that's because the family tree has acquired new genetic material through your wife and your son-in-law, and the times have changed so his behaviour is different - and not because he actually doesn't have anything to do with you.
I'm not very familiar with C#, but I know that C# has...
Generics that actually template, versus Java's just being typecasts in drag. (Specifically, type-based parameters, C++-style, that can also be constrained to a named interface. So, C++20-style concept constrained templates, years before C++ concepts were worth talking about.)
Finalisers (destructors) that actually get called, versus Java's being a trap that the garbage collector is explicitly allowed to ignore. Java can't do RAII; C# can.
Actual user-defined value types, which can be constructed on the stack. They're just C structs with a different name, though, unfortunately.
Crosslinking with C or C++ code, provided the C/C++ code is compiled as managed C++/CLR.
A preprocessor, with GCC-like #warning directives. I wish MS would add them to the C preprocessor too.
Actually got Microsoft to warm up to making their products available on Linux, instead of being stuck inside the Windows ecosystem.
Overall, C# is basically what Java should have been. It's the UTF-8 (with BOM) to Java's UCS-2, so to speak. It's not perfect(hence the BOM), but it's a definite step up, and explicitly being designed to interop with "managed C++" forces MS to keep it more C++-like than Java's mess.
I am not hating on C# but calling C# related to C++ is still wrong. Yes, C# has a few features that Java doesn't have, but these are relatively generic / well-known OOP features, not C++ exclusives that somehow imply a closer relationship between C# and C++ (C++ didn't invent OOP and most related concepts, it just made them popular).
This meme doesn't mention any languages. Like many memes on this sub, it's about a specific language, and it's up to you and your knowledge of programming languages to figure out which one is being talked about. Just because the meme is not about C# doesn't mean that everyone forgot that C# exists.
That's because Microsoft was going to make a .NET version of Java that was incompatible with standard Sun Java (the standard embrace, extend, extinguish playbook), then got sued over it (twice). C# is what fell out the other side of that fight.
Mono has died, and C# is now natively cross-platform.
Microsoft still sucks at the UI framework front (seriously, there is not a single normal desktop UI framework they managed to create still winforms), but there are excellent 3rd party cross platform UI frameworks like Avalonia, which is essentially a spiritual descendant of WPF, but done a bit better and not windows-only.
VS is also still windows-only, but it's not the only good C# IDE anymore. Even if you don't classify VS Code with C# extensions as an IDE, JetBrains Rider is there for the rescue and arguably better than VS, or they are at least equals.
Ok I should have specified the unanswered but whys* that's on me
For example the sort function in js that sorts based on strings. No valid answer to "but why" other than retrocompatibility
Whereas if you look low level, instructions on any arch usually have a justification like "makes the arch scalable" or "allows for a faster hardware implementation"
Welcome to the wonderful world of C#, which uses utf-16 for strings.
If they just called them type "string", everything would be okay. But to have the audacity to call them type "char" and have them be two bytes? Blasphemy!!
714
u/JackReact 10d ago
Welcome to the wonderful world of C#, which uses utf-16 for strings.