Which is why Iran never went to war with Iraq.

Oh, wait.

There was an ice age 10K years ago. So there are definitely longer term weather patterns on this planet. That's not evidence for or against global warming, but to claim we understand the climate well is disingenuous at best.

It didn't put either of us at a disadvantage. We had enough to destroy them 10x over. Being able to do it 20x over doesn't make us any more powerful. Now when you start getting down towards the 1x threshold you might have a point.

In what world do PCs have a standard hardware model?

Case size/shape- nope.
Cpu socket- nope.
RAM type- nope.
Peripheral bus- nope.

The only thing that all PCs have in common is a CPU instruction set. And not even 100% on that (x86-64 or IA64 was a battle not too long ago).

-You seem intent on sticking to your view regardless of all the evidence to the contrary
-You call everybody else "shitty programmers" for using auto yet you can't explain what you don't like about it.

Pot. Kettle.

You look stupider every time you post.

Yup that too.

The reason they're useful for iterators is that they fucked up iterators. There should have been a base abstract iterator class with child classes for the various types/classes. Then you could have just declared it as an iterator* and not worried. Rather than providing bad patches they should fix the initial problem. Patching on mistakes just leads to problems.

If you want to use auto, go to a dynamically typed language. Strong typing is a feature, it prevents bugs and saves time and effort in maintenance. If you use auto, you're a shitty programmer. Auto solves NO problems except the number of characters you need to type when declaring stl iterators. Its a bad feature used to patch over other poorly designed features. Which basically describes almost all of the additions in the last 10 years to C++.

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.