29,569 reputation
349116
bio website coderscentral.blogspot.com
location Colorado Springs, CO
age 50
visits member for 4 years, 8 months
seen May 22 at 14:04

Started programming on a Control Data mainframe in FORTRAN IV, back when that was still a new thing. Was apparently quite masochistic, because I kept programming anyway. For that matter, I still do...

Gold C++ badge #20
Gold C badge #12
Legendary badge #35


May
20
awarded  Nice Answer
May
18
awarded  Great Answer
May
13
awarded  Nice Answer
Apr
21
comment Do you ever read language specs?
The question specifically talks about knowing "all its dusty corners", which implied to me that it was about really studying the spec in a great deal of detail, not just reading some parts. At the same time, I doubt anybody fully understands the entirety of the C++ spec. It's too big and too complex.
Mar
15
awarded  Scholar
Mar
15
accepted What mistakes in managing software products must be avoided to keep people from hating the vendor?
Mar
12
revised Advice for an ambitious student on building your own kernel
added 9 characters in body
Mar
8
revised Is Bubble Sort the slowest sorting algorithm?
added 704 characters in body
Mar
4
answered In ifs inside for loops, prefer checking for true, or for false and continue?
Mar
3
revised Bad sign if nobody can comprehend one's code?
added 514 characters in body
Mar
3
revised Bad sign if nobody can comprehend one's code?
added 223 characters in body
Mar
3
revised Bad sign if nobody can comprehend one's code?
added 800 characters in body
Mar
2
comment How can frond-end developer support different encoding (UTF-8 , UTF-16,..)other than ASCII?
@Deduplicator: I doubt there would be a strict 1:1 mapping from code points to tokens, but if you were going to use Unicode at all, it seems to me there are enough sufficiently obvious direct mappings like these that (as I've said all along) UTF-32 would make (by far) the most sense.
Mar
2
comment How can frond-end developer support different encoding (UTF-8 , UTF-16,..)other than ASCII?
@Deduplicator: I guess I'm a bit lost here. Even just checking equality between one code point and some known code point becomes non-trivial if you deal directly with UTF-8. Let's say we decide to support things like U+221a for square root, and U+2265 for "greater than or equal to". With UTF-32, this is something like switch (input_codepoint) { case 0x2265: ...; case 0x221a ...;} With UTF-8, this simplicity is lost, and just figuring out what we've read becomes a non-trivial exercise.
Mar
2
comment How can frond-end developer support different encoding (UTF-8 , UTF-16,..)other than ASCII?
@Deduplicator: Again, it seems to me that precisely the opposite is true. Essentially the only rational way to deal with UTF-8 is to start from UTF-32, convert to UTF-8, then on the other end convert back to UTF-32. In this case, there's simply no meaningful motivation to convert the data to UTF-8 for storage in that buffer. For a file or network transfer, you can make a minimal case based on reduced storage/bandwidth, but (IMO) even there it's pretty minimal (and if it matters, better served by a compression algorithm).
Mar
2
comment How can frond-end developer support different encoding (UTF-8 , UTF-16,..)other than ASCII?
It sounds to me an awful lot like you're starting from the conclusion that UTF-8 is the right answer, and you're just groping for any excuse you can come up with to justify that conclusion.
Mar
2
comment How can frond-end developer support different encoding (UTF-8 , UTF-16,..)other than ASCII?
@delnan: As you undoubtedly already know, extracting the Nth code point in constant time (without pre-indexing) is an obvious one. Consider it from the other direction though. If you turned every text file on your hard drive to UTF-32, would that consume a whole dollar's worth of extra space? Fifty cents? Even for files using only US-ASCII, does the savings from using UTF-8 justify any complexity at all? Short answer: no! Not even close.
Mar
2
comment How can frond-end developer support different encoding (UTF-8 , UTF-16,..)other than ASCII?
Yes ftp and quite a few things that manipulate files on Windows are basically broken. As for leaking file system details: no. All I'm saying is that the language spec shouldn't address how the transcoder learns the encoding at all. As far as the language spec cares, all input as just UCS-4. The transcoder is just an external tool that turns raw input (in whatever format, detected in whatever way) into a form acceptable to the lexer.
Mar
2
comment How can frond-end developer support different encoding (UTF-8 , UTF-16,..)other than ASCII?
@delnan: I have read it. It's a giant mistake. And no, being able extract a code point quickly does not mean you're mistaking that for a grapheme cluster. That's simply a fantasy that's been made up to support a position that can't be supported by real facts.
Mar
2
comment How can frond-end developer support different encoding (UTF-8 , UTF-16,..)other than ASCII?
It should go into a (more or less) dedicated place provided by the file system. For example, on NTFS it could be written into an alternate file stream. Unfortunately, most Unix-like file systems fail to provide a good way to do this.