Reputation
29,932
Next tag badge:
272/100 score
19/20 answers
Badges
3 49 118
Newest
 Announcer
Impact
~1.3m people reached

Aug
20
awarded  Announcer
Aug
19
answered Checking array size in C/C++ to avoid segmentation faults
Jun
27
comment JIT compiler for C, C++, and the likes
@JohnMudd: I suspect the reasoning is security. E.g., modify the cached code, then the next time the VM starts, it executes code I put there instead of what it wrote there.
Jun
8
awarded  Nice Question
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.