What Happens When Your Phone Falls into the Ocean

Short answer: It'll stop working.

But have you wondered, why? What happens to the insides of the phone?

We've all heard that salt water conducts electricity and "fries" your electronics, but what does that mean? Will the phone rust? Will the battery melt? Today we get to find out!

In this blog post we'll look inside my Black 16GB iPhone 5 (yes, that's an affiliate link) that took a swim in the Pacific. Where possible, iFixit's iPhone 5 teardown pictures will model what iPhone 5 internals should look like.

The Initial Opening

This is how an iPhone 5 looks like after swimming in the Pacific.

This is how iPhone 5 innards should look like, courtsey of iFixit.

Right away, there's a huge difference. There ocean phone is full of fine sand, salt stains, and a giant rust spot. If you remember chemistry class, then the rust spot makes sense: rust is an electrical process. The biggest rust spot will be at the anode of the battery leads, which is exactly where it is.

The Screen Assembly and Mainboard

The salted, rusty screen assembly. The rust feels like its simply rubbed off from the other part.

The salted, rusty mainboard and battery. The battery is surprisingly intact.

How an iPhone 5 screen assembly and mainboard should look like. Notice the distinct lack of salt, rust, and sand. Courtesy of iFixit.

Once again, the salt stains and rust is the big difference. Surprisingly, the lithium-ion battery is perfectly intact, without holes or burn damage. Why surprising? Lithium and water tend to react vigorously.

Battery Closeup

The battery leads are extra rusty.

An unsalted battery, courtesy of iFixit.

Other than the rusty leads, the battery seems fine from the outside. The phone would not power on, but I am not sure if its related to the battery or other electronics failures. Probably both.

Mainboard and Chassis Closeup

There's a large salt deposit under the mainboard. The salt water must have pooled there as the phone dried.

A pristine mainboard, courtesy of iFixit.

Getting to this part was a challenge: some of the screws were so corroded and rusted that unscrewing them stripped the grooves used for unscrewing. I had to resort to force and some prying, which didn't matter since the phone was already broken.

A Zoom on the Mainboard

A zoom on the corroded mainboard.

The front of the camera and mainboard.

A pristine mainboard, courtesy of iFixit.

Almost every connector is rusted or otherwise corroded. This is one of the main reason everything stops working: the small connectors corrode and the mainboard components can't make electrical contact.

Everything

All the rusted components in one glorious photo.

All the pristine components, courtesy of iFixit.

The obligatory "all components in one photo" shot. Mine isn't as nice as iFixit's, but the other differences should be obvious. The one interesting thing to note is the serious corrosion on the SIM card.

Conclusion

If your phone falls into the ocean, its going to have a bad time. Don't let your phone fall into the ocean.

Bjarne Stroustrup on the Past and Future of C++ (Including Long Template Errors)

Someone on IRC pointed me to Bjarne Stroustrup's talk on C++11 and C++14 at Microsoft's Going Native 2013. If you work with C++ and haven't seen Bjarne's talk yet, go watch it now.

Stop reading this and go. I'll wait. 

An hour into the talk, Bjarne starts discussing templates, long error messages, and the tradeoffs that were made during the design of C++. The long error messages were a conscious decision to preserve performance and expressiveness with the computing power available back in the mid 1980s.

It amazed me that Bjarne admits template error messages are a huge debacle, and he has been working for 20 years to fix the problem. The solution is near: C++14 concepts will finally allow for sane template errors. Messages like "Member must be CopyAssignable" will be possible, and hopefully normal. This isn't just theory: there is an experimental branch of GCC that supports concepts right now.

Other parts of the talk are fascinating in their own right and have given me a lot more respect for C++ and Bjarne Stroustrup. The man could have rested after creating the original C++ spec and compiler, but he has been working for 20 years to improve the language. That dedication has made C++11 much better than C++98.

Bjarne also brings up a good point: many people who dislike C++ are using it the wrong way. The language should only be used when you need a performance and lightweight abstraction at the same time. If you don't care about performance or you need high-level abstraction, C++ is the wrong tool for the job.

The talk has a lot more interesting content. If you haven't watched it yet, go now.

C++11: better, but still frustrating

Update: jduck pointed out that the before/after code snippets were identical. Oops. Now fixed.

I'd previously given up on C++ due to the many small frustrations: incomprehensible error messages, silly parsing issues (e.g. '>>'), rules to avoid subtle errors, and many other small frustrations that soured me on the language. That was back in the days of C++98 and C++03.

The language has evolved, and recently I found myself working on a project written in C++11. So far my experience has been better, but still frustrating.

A Motivating Example

I'll start with a real example. The project created a lot of Foo objects that were passed by reference to numerous functions. I needed to keep a collection of every Foo object that was passed to a specific function.

My first thought was, "I know, I'll create a vector of Foo&". This thought is simple, elegant, and of course, wrong.

A vector of references isn't possible because references can't be reassigned. That is, references[0] = foo; would update the referenced object, not the zeroth entry of the references vector. More technically, references are not CopyAssignable, a requirement for members of containers.

Errors Galore

But how would someone new to C++ know this? What do compilers say when making a vector of references? Lets find out by compiling this small (and wrong) program.

#include <vector>
#include <iostream>

int main(int argc, const char* argv[])
{
    int a = 1;
    std::vector<int&> test = {a};
    std::cout << "a: " << test[0] << std::endl;
    return 0;
}

Here are the results for Clang, GCC and MSVC:

Compiler	Error List	Error Count
Clang	rextester.com/JMFGP72087	158 lines
GCC	rextester.com/HGKFIT84222	187 lines
MSVC	rextester.com/UXPG39365	107 lines

In classic C++ style, the error messages are hundreds of error lines from obscure library implementation code. They give no indication of what is wrong, and no indication of the solution. I pity someone who doesn't have C++ experience trying to figure out what is wrong with their code. Pretty much any error would be more helpful, even an obscure message like "Member must be CopyAssignable" -- as long as it pointed out the correct line of code.

The Fix

For reference, the corrected program is:

#include <vector>
#include <iostream>
#include <functional>

int main(int argc, const char* argv[])
{
    int a = 1;
    std::vector<std::reference_wrapper<int>> test = {a};
    std::cout << "a: " << test[0] << std::endl;
    return 0;
}

The fix is to use the std::reference_wrapper utility function when making a container of references.

Conclusion

There's definitely upsides: the '>>' parse has finally been fixed. Classes can now be initialized with initializer lists. There is type inference via 'auto'. For-each style loops exist.

C++11 is a great improvement over C++03, but its still frustrating: the obvious solution (like containers of references) is wrong in subtle ways, and compilers still generate hundreds of obscure error messages for a one-character typo.

Do Not Reply Addresses Suck

If you send emails from do not reply addresses, I hate you.
Your customers hate you.
People you've never met also hate you.

Why  you should stop using no reply addresses:

• Something will go wrong and your customers can't tell you.
• You will send email to people who aren't your customers. They will have no way to ask you to stop.

Stop hating your current and future customers. Stop using no reply addresses. Only send email from monitored email addresses.

And one more thing...

If you create accounts without validating email addresses, I doubly hate you... and from now on I will be naming and shaming.

The Do Not Reply Hall of Shame

Ask.fm

Ask.fm lets people register without validating their email. The many follow-up emails are all from noreply@ask.fm. Ask.fm, please stop.

As you can guess, nothing was ever done. Ask.fm, I hate you.

DataViz.com

DataViz lets people buy software without verifying their email. Wish I could reply and tell them, but the email is from do-not-reply@dataviz.com.

My name is not Artem Dubov and I did not buy this software.