tpolzer

Apple sends your searches to Google for money. I would call search queries data?

Apple, Samsung and Google all earn money from ads on your phone, just with different monetization pathways.

Indeed, but then I wouldn't call it a "big miss" (the title of the article, which doesn't mention regions either).

A moving GC would make it simple to move any remaining live objects back under normal GC control once the arena goes out of scope.

You could probably also do it without moving actually, it just gets a little more complex.

I wonder whether it would be possible to retrofit Arena allocation transparently (and safely!) onto a language with a moving GC (which IIUC Go currently is not):

You could ask the programmer to mark some callstack as arena allocated and redirect all allocations to there while active and move everything that is still live once you leave the arena marked callstack (should be cheap if the live set is small, expensive but still safe otherwise).

It's a question of energy density. Multiple joules into your big phone battery is nothing, multiple joules into a small SMD component means it evaporates immediately in a bright flash!

Bad drivers could brick (parts of) your hardware permanently.

While you should have a backup of your data anyway.

If there was a std::unit_t and it was implicitly convertible to optional, tuple and pointer, I don't think that would be worse in terms of usability at all (maybe worse in readability for people who haven't heard of a 'unit' type).

As for the std::variant use case, using std::monostate is only a matter of convention there. You could use any of the other unit types just the same.

What's really weird to me is not that C++ has a unit type and picked a weird name for it (that's just C++). The weird thing is how many unit types it has:

- std::nullopt_t

- std::nullptr_t

- std::monostate

- std::tuple<>

And I'm sure there's more.

I find it annoying that (a) this seems to be a hardware feature that is almost universally permanently disabled in firmware and (b) it's almost impossible to find out whether it is supported by any given product (neither of the two products you link provide any mention on the spec sheet).

SD Express is basically dead as far as I can tell.

SD card users who care about speed have UHS-II equipment, but SD Express and UHS-II use mutually incompatible high speed signalling on the same pins (so cards and readers are only supporting one of the two - I guess technically this could be fixable with special purpose chips, but at large cost).

Users who care about speed but not about SD card compatibility are already using CFExpress, which is supported by most modern professional cameras and has much better hardware availability than SD Express.