Float for autos- someone used the wrong version of a library function that returned float to initialize the auto. Kid was new, he didn't know the effects it would have. Auto wasn't the bug, but without auto the bug wouldn't have existed- the problem would have been minimized to a single call and caused a compiler warning that we would have caught and fixed. Auto made the bug worse.

No, I've used C++ in a very normal environment. STL container classes- used all over the place. The algorithms library? More complicated, harder to understand, and much harder to maintain. Very few places use that. And they shouldn't- while min and max aren't too bad, I would always prefer to see an explicit loop with the code embedded in the loop than a function call where I have to hunt down a functor (another thing that should never have come to be) to find out what the fuck is actually being done.

If you want to write Ruby- use Ruby. Keep that shit out of C++.

I'm cool with nullptr for 0. But auto absolutely causes bugs. I've seen it, where programmers assume the auto datatype is one thing and it turns out to be another. It was a major performance issue in a program I debugged. Turns out the compiler assumed they were using floating point where they wanted to use int, and the processor didn't have a floating point unit, so it was all emulated in software. Unfortunately it wasn't found until after release.

In addition, it decouples the data type from the code in maintenance. Want to know what that auto loop is actually doing? You need to find and check wherever the container was defined. This takes time, and leads to bugs when maintainers forget or make the wrong assumption. For saving 10 characters at writing time you cost orders of magnitude that when maintaining the code.

Furthermore- the reason for auto was they fucked up the STL by adding too many features (allocators) and insisting on their algorithms library (which in 15 years of writing C++, I have never seen used) being compatible with pointers as well without using a wrapping class. Stupid, stupid ideas. You don't perpetuate mistakes with new features which add new problems- you correct them.

I completely understand the new features of C++- I just think the vast majority are a bad idea.

Then you're extremely lucky, I've had iOS hard lock when dogfooding apps fairly frequently (although that was a few years ago, maybe they're better). But I don't trust ANY device without a real pull the plug option, not after years of doing firmware and mobile development. If a device needs batteries, I will not buy it unless those batteries are removable.

If the phone is locked up, yes. Same thing for your computer and everything else. Hardware off switches are a rarity these days.

I wish people would stop adding to C++. C++ as it stood in 1998 was a good, if somewhat complex, language. The new additions (except for a few of the libraries) make the language way too complex and lead to unreadable code.

You need to learn that concise != good. If it did, everyone would be programming in perl 1 liners. Auto is the most braindead addition in history, it causes bugs, loses all the advantages of a typed language, and only needs to exist because they fucked up the STL by not using proper inheritance. Any code review that uses them is an auto bounce and fix. Templates are the most abused language concept in history- if you're using it for anything other than a container class, odds are 98% that you're writing hard to follow, hard to maintain code that should be rewritten

C== was better when it was treates as C++98.

No, we want a quick way to do a 100% reboot if the phone is in a bad state.Without that your only option is to wait 1 day until the battery is dead. Or longer if the radio is off in that state.

Or buy a competing product that does do what you want. Like one of the gadzillion other android devices out there.

That's not nearly as true as you'd think. Besides which, there's a difference between Oracle's database (which is widely used), and Oracle's consultancy arm which while used has never put out a decent project in their history.

Beep... Beep... Beep...

You think being responsible for the literal lives of your passengers for 8 hours a day, needing to be alert the entire time is *less* responsibility and stress? You're out of your fucking mind.

Those applications are all *drumroll* web pages. They are not video conferencing or any of the other crap Mozilla has been putting in there lately. Anyone who thinks those belong in a browser is a fucking idiot.

Define "default android browser". Each OEM ships their own- Google has one, but so does Samsung. If you have a Samsung phone you've never used the default Android browser.

In *browser*? Abso-fucking-lutely. If Mozilla Foundation wanted to write the Mozilla Videoconfrencing app, that would be fine. But there is 0 reason to put it in the browser, and it only decreases security of everyone involved by having it in there. A browser should display webpages- period.

I read several novels a month. But I wouldn't read a technical book on an ereader if you gave it to me for free and paid me to do it. And I've tried- I originally bought it thinking it would be great for tech books. But the slow speed of page switching, the inability to flip through pages rapidly, the reduced area per page all make it an unbearable experience. Ereaders are good for fiction reading, they're completely unsuitable for anything that isn't read beginning to end with no branching or backtracking.

Tablets are a horrible replacement for books. Lets ignore the fact they have massive amounts of distractions built in. They're harder to read, worse for your eyes, run out of batteries, are harder to take notes on, and worst of all hard or impossible to skim. I own over a thousand books on my kindle, but almost 0 technical books. Its just not a good medium for it.