Yes "clever" operator overloading comes up high in my list. Scripting languages are full of it like in Pike: str/" " Divide a string by space to get an array of the words. But I dislike it way more when operator overloading abuse is done in user code than when it is a language construct.
So, if you take that array of words and multiply it back by " ", do you get the original string? Because that would make it cool.
That's a really dumbass lexer. Glad that shit got fixed.
Or should I say... a really dumbass parsing layer to go and use a lexer that doesn't understand the local context when it constructs a lexeme from the input stream.
Namely, the >> symbol. Because templates use angle brackets for template parameters, if you had a nested template such as T<int, T1<double> >, you HAD to put the space between the two closing angle brackets. Otherwise the lexer would interpret the two angle brackets as the shift operator.
That's a really dumbass lexer. Glad that shit got fixed.
They should of used:
s/of/have/
I know one game shipped with buggy AI because somebody forgot to use two equal signs inside an if statement!
That's not C's fault. That's the developer's fault for ignoring the compiler warning about it. (Or for not having enabled the warning.)
Documentation for sizeof would have told you that it's for telling you the size in bytes of datatypes on a particular system.
s/bytes/chars/
example: uint32 is a 32-bit unsigned integer,
s/uint32/uint32_t/ (unfortunately)
The core problem is that Java was never indented as a mainstream language, but for embedded programming.
s/never/not originally/
FTFY
No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and
Oh my god. Excuse me, but you are so very wrong. Yes, it DOES work and is a GOOD THING to compare references sometimes. For example, if you are implementing your own general hash-based collection class, you will find that your lookup code runs significantly faster if you first compare object references for equality before comparing the object's hash followed by comparing the objects themselves for equality. That is to say: (1) First compare object references using ==. If equal, you're done immediately because your key matches, and you can go fetch the object associated with the key. If not equal, proceed to next step. (2) Next, compare object hashes using ==. If not equal, you have a mismatch and you look at the next key/value pair, if present in the bucket or linear addressing cycle; if equal, proceed to next step. (3) Finally, assuming you get this far, compare contents of objects. If equal, then you have a key match; if not equal, you have a mistmach and you either continue for the next key or fail with no object found.
So you see, sometimes is makes perfectly good sense to compare object pointers. Comparing references instead of values is NOT logically wrong — as long as you use the comparison as an early-out test before performing the more expensive actual comparison of value. Hope that clears things up.
I don't like to put trust in people who write "Gates's"
And three times in the same sentence!
(Legal, but annoying.)
Relax, you'll be in good hands soon. The wambulance has been called and should be arriving shortly.
Gates's is the clearest form of the possessive nominative.
[...] It gave us the notion of an "app" and an idea of apps could achieve in the Internet era.
Applet actually.
The notion of an "app" didn't come until 2008 with the iPhone.
[...] Java was only sold as a silver bullet for portability, not speed, not efficiency, not scalability, but solely for it's ability to be shifted from one vendor's platform to another's.
Your memory is partially correct. What it was actually touted as was:
“Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language.”
So which symbol would you pick??
Well I would pick b, because it isn't a hexadecimal digit.
{ 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F } are hexadecimal digits.
If all else fails, lower your standards.
