A lot of good stuff, reading C++ errors is like learning an extra language on top of the C++ language, I can’t wait to try it out.

How do I get at some private field?

That one is interesting! I wonder how smart it is.

For instance in the following example:

class foo
{
public:
  std::pair<int, int> get_coordinates() const { return std::make_pair(m_x, m_y); }

private:
  int m_x;
  int m_y;
};


void test(foo *ptr)
{
  if (ptr->m_x >= 3)
    ;// etc
}

I wonder if the compiler would be able to figure out that m_x is accessible via ptr->get_coordinates().first ?

My understanding of AMP is that the technical limitations it imposes (compared to a regular HTML/JS webpage) is exactly for this purpose: Be able to cache on CDN is one thing, but more importantly be able to preload pages at will.

The author makes a good point by saying that Google has an advantage because while you’re spending time browsing the Google’s page (or Google assistant or else on Android), it can perform all those pre-fetching in the background.

But to be 100% accurate, I don’t think this statement is fully true:

Taking that page from 2–8s to instant performance is something only Google is capable of, because it is the only entity in the world controlling the most important information portal: search.

Apple on iOS devices, or Microsoft on Windows, or RandomDev on “MyCoolNewsApps”, or a Firefox add-on, or Facebook could do it too, or even the NYTimes on their own website. But to date only Google has spent the time/$ writing the AMP clients.

And given enough time spent on the platform, caching on any Google CDN AMP server, or even any AMP cache server could be unnecessary, as long as the prefetching algorithm is smarter than you and predict all the pages you want to read before you tap on the link to read them.

The most important requirement for AMP pages to be successfully perceived as fast is that you spend a lot of time on the platform (or the platform has the capability of pre-fetching with close to perfect accuracy in the background)

Preloading is exclusive to AMP. Google does not preload non-AMP pages. If Google would have a genuine interest in speeding up the whole web on mobile, it could simply preload resources of non-AMP pages as well.

As qznc mentions, there might exist some technical limitation of non AMP pages that prevents this from happening. And with AMP pages Google can guarantee that the pages sizes are small enough and not too stressing on compute. It would piss off users really fast if Chrome started to preload multi Mb / java script heavy pages without the users consent, draining both data usage and battery.