Untrue. As far as my C++ code goes its kind of "light" on the use of templates, classes, etc. I don't use them because they are available, I use them when they make sense. My code is sort of C'ish in this respect.

Untrue. Obj-C is not as portable as C++. Even when not targeting MS Windows I like to compile the core code and run regression tests using MS Dev Studio. Yet another set of warnings, yet another code generator to help spot bugs. Plus I also tend to write code so that someone else can eventually maintain it. Obj-C is a niche language, C++ has a much broader user base.

There really is no downside to using C++ in core code rather than Obj-C.

That is not my experience. It feels quite natural and automatic to think Obj-C when doing UI code and think C++ when doing core code. Plus passing objects around seems a non-issue. One can use C++ structures and classes in Obj-C code and Obj-C objects tend to be those interfacing with the UI code, objects of no interest to the core code. And if an Obj-C object is input from the user its trivial to convert to an ordinary UTF8 string, int, etc.

That assumes one uses the gnu toolchain. When I write portable code I like to build it in Apple Xcode, MS Dev Studio and with GNU. Different warning can be useful and well as running regression tests on output from these three different code generators.

Perhaps my SF example created some confusion but my comment about gas leaks was independent from earthquakes, notice "happens all the time every day". I'll add that I am basing this on decades of maintenance experience (grandfather worked for gas company) from a region not prone to earthquakes, US North East.

I'll also add that gas leaks are only one of many possible sources of fires. Having worked in a warehouse fire was considered a major hazard. Far more hazardous than a home fire given limited egress points and the toxic by products of burning inventory. And this was in a warehouse serving department stores, not specialty chemicals and such.

SF was mentioned as an example of what a fire can do to a city when there is no active firefighting. I.e. huge sections of the city can burn.

C++ is also important when targeting Apple. Objective-C is the language of the Cocoa API (Mac OS X and iOS), however there is no need to use it beyond code that makes Cocoa based system calls. And getting C++ and Objective-C code to call each other is trivial.

Personally I recommend separating UI and platform (OS) specific code from an app's core functionality and implementing the UI/platform-specific code in whatever the native language for the platform is and implementing the core code in C/C++. This leaves the core code portable, ready to target other platforms. I have iOS apps where the core code can be compiled in a console Linux environment and exercised by various scripts (regression testing) and in a random manner (fuzzing).

Untrue. I am also not a lawyer and I only skimmed the agreement so perhaps I am misunderstanding it but I believe you can distribute the source code to your game.

What you cannot distribute is Epic's game engine source code and binary tools. However your customer can download these at no charge from Epic just like you did. So it seems a customer can get everything they need to rebuild the game themselves. They just need to download game code from you and engine code/tools from Epic.

No. For example the frameworks account for a lot of code and some differ between Mac OS and iOS and some are unique to iOS.

Zombies don't need to be realistic, merely being entertaining is sufficient. They can be quite useful to bring up the topic of disaster preparedness. A super-flu, ebola, etc is not necessary for crisis. A "mundane" storm or earthquake that knocks out the power to millions and shuts down the supermarkets is sufficient. Anything that might spark a conversation or some thought about having a weeks worth of unrefrigerated food and water at home is a good idea. OK some plastic trash bags, baby wipes, and purell might also be a good idea for your in-home campout.

Similar story for those survivalist/prepper shows.

Not a good metaphor. Zombie converts have a very reliable loyalty. While social/political/religious converts are more prone to be reliable only as long as the evangelist with the gun/sword/knife/money is standing nearby. :-)

Maybe in the movies. In reality a solo human is almost certainly at the mercy of the bear once things get to spear range. If you survive its because the bear was motivated by dominance / threat removal not predation. Wolves, you won't be against one, and while one gets your attention another will dash in and out for a quick bite to the leg to get you bleeding, to start the process where you become too weak to fight. Lions, well in North America that will be the mountain lion that you never saw and never raised your spear against.

Not really. The most important factor is the social factor, the extended family / tribal behavior. Solo sneaky toolmaker -- highly vulnerable. Tribal sneaky toolmakers -- very dangerous.

Highly vulnerable to fires. Without maintenance (ex: gas company crews fixing leaks -- happens all the time every day) and firefighting you are at risk and still need to be ready to bug out and be mobile. Think of the fires that followed the 1906 San Francisco earthquake.

Yeah, I realized this just as I typed the word "simulated" in another post. :-)

However I still expect that much iOS specific code is run in regression tests completely separate from the various device simulators.

But then I'm biased. Giving all the porting I've done I'm a little "enthusiastic" about separating core code from UI code and other platform specific code. Windows apps, Mac OS apps, iOS apps, Android apps, etc ... I've tended to have core code runnable in a console environment for testing on the headless Linux box in the closet. Regression, fuzzing, etc.

I'm referring to much more than Darwin. Possibly iOS in its entirety. At a minimum various iOS specific frameworks in a regression test environment. Including some hardware specific frameworks where inputs are simulated.

Wait, speaking of "simulated", we have the Mac OS X based iOS device simulators used during development. Doh!

{ Oops, forgot to log in, didn't mean to post AC }

Its not that simple. Tidal generation can also be used to temporarily reduce fossil fuel based generation. Throttle down the fossil fuel based plants during tidal generation, it predictable and schedule-able after all. Power generation can remain constant yet less fossil fuels are used.

It just takes a dev or two building and testing the code on x86 just to make sure its cross platform.

Such an effort can pay for itself simply through the bugs it will find. What is a very subtle and sometimes currently unnoticed bug on one platform may become a highly visible bug on another platform. Bugs sometimes manifest differently on different platforms. I've been on several teams over time where we moved good "working" code to a new platform and watched it crash spectacularly over and over again. Each time the original devs who thought their code was in great shape were shaking their heads wonder how it ever ran on the original platform. Lucky values in uninitialized variables and such.

So yes, someone is probably building and testing iOS on x86 but it has little to nothing to do with any plans regarding using x86 on any devices. Sort of similar to the Microsoft's efforts to internally build and test Windows on a non-x86 platform after it gave up on shipping MIPS, PowerPC and Alpha binaries. Its more about testing and future proofing a core asset than any short term plans.

And if I were running Intel I would be supplying the engineers to do so if Apple was not doing it on their own initiative.

I remember the world being surprised to mildly annoyed at best, surprised in the "did they (Apple) really do that, seems rude not to ask" sense. Very annoyed was definitely a minority. And of course those thinking it rude and those mildly annoyed included folks who had purchased U2 albums in the past, including the distant past. Those not interested at all seemed to delete it and calmly share sentiments such as "I hope Apple doesn't make a habit of this", a bit short of very annoyed.

So no, its not surprising that a lot of people listened to the album once they found it on their device, despite its "rude" delivery.