Manchuria was across the Sea of Japan from the Japanese home islands. The Soviet invasion of Manchuria did nothing substantive to directly threaten Japan.

Japanese strategists wanted to be in Manchuria and Korea because of their proximity to imperial Japan, but that was also why they had invaded the Philippines (to defend seaborne lines of communication to their oil supplies in Borneo).

By the time the Soviets invaded, the Japanese had been ejected from much of their outlying empire, yet they had not surrendered, because Japan itself had the capability to fight.

The Soviet invasion of Manchuria did not change that, an invasion of Japan proper could only have come with involvement from the rest of the allies, including the sealift used for the invasions of Normandy and southern France.

Of course, but that's the value-add of Docker Desktop. But you don't have to tie yourself to it, or even if you do use it for a bit to get going faster, you have a migration path open to doing it yourself should you need it.

Yeah, it comes down to modeling assumptions on how many different types of exceptions can be thrown, how many actually are thrown, and the shape of the control flow graph of a program at runtime.

You can find one style outperforms the other based on the circumstances of the program, and programmers worried about optimization may someday be able to choose between approaches to meet their performance goals instead of pretending that tables are inherently slow and return codes that they won't even fully implement are inherently fast.

My point was simply that you can't just say "oh but exceptions are not zero-cost" without actually comparing to the alternative of laboriously carting return codes all through the call graph, as done in the research you show here and as also done by Khalil Estell elsewhere for ARM embedded.

A specific presentation I'd point to is Khalil Estell's presentation on reducing exception code size on embedded platforms at https://www.youtube.com/watch?v=bY2FlayomlE

But honestly you'd get vast majority of the benefit just by skimming through the slides at https://github.com/CppCon/CppCon2024/blob/main/Presentations...

With a couple of symbols you define yourself a lot of the associated g++ code size is sharply reduced while still allowing exceptions to work. (Slide 60 on)

There's a time-space tradeoff to basically any means of error checking.

Including checking return codes instead of exceptions. It's even possible for exceptions as implemented by g++ in the Itanium ABI to be cheaper than the code that would be used for consistently checking return codes.