defap

Sure, but if the app hasn't been submitted, then what is there to discuss with Apple? What is he talking about?

You don't base it solely on that, either. Price is determined by the imbalance of buy and sell orders. Investors might decide to buy or sell based on a multitude of factors, including but not limited to earnings and growth potential.

> I guess a couple of the Safari team dudes have started blogging

Both stories are from the same person.

Pointless? You seem too caught up in the meaning of the word 'blame'. Maybe you should think of it as 'annotate', instead.

There are plenty of times where I want to find the changeset that last touched a line of code so I can read its commit message, find an associated bug tracker ticket, etc. What do these uses have to do with the last working revision of a project?

Some used this same argument to suggest that Google wouldn't want to ship an iOS Google Maps app, and yet, lo and behold, it shipped two weeks ago to great fanfare. To think that Google would not want to participate in an ecosystem as large as iOS because not doing so might drive some small percentage of those users to Android is ridiculous.

If the machine is as unserviceable as you claim, then the increased reliability is indeed an advantage (or at least a mitigation). I'm not sure I see the irony.

Apple has used the term HI for a long, long time.

Sure. I was more responding to the claim that shared_ptr should always be preferred to auto_ptr. I agree that scoped/unique_ptr fixed a lot if auto_ptr's pitfalls.

Before the days of std::move, auto_ptr's copy modeled an ownership-transfer semantic in a more efficient way than could be accomplished by shared_ptr (no refcount churn). It wasn't broken; one must have simply known when it was appropriate to use.

Consider a helper function that returns a heap-allocated object and think whether auto_ptr or shared_ptr better modeled the function's intent of giving ownership of the object to the caller.