In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability.
Exceptions in high-level languages avoid many of these issues by virtue of being much further away from the metal. It is a mis-feature for a systems language. C++ was originally used for a lot of high-level application code where exceptions might make sense that you would never use C++ for today.
> In low-level systems software, which is a primary use case for C++
I don't this this is true. There is A LOT of C++ for GUI applications, video games, all kind of utilities, scientific computing and others. In fact, I find that the transition to "modern" alternatives from native GUI toolkits in C/C++ has led to a regression in UI performance in general. Desktop programs performed better 20 years ago when everything was written in Win32, Qt, GTK and others and people did not rely on bloated Web toolkits for desktop development. Even today you can really feel how much more snappy and robust "old school" programs are relative to Electron and whatnot.
To clarify, you think that low-level systems software is only a secondary use case for C++? The part you quoted does not make claims about whether there are other primary use cases, just that low-level systems software is one of them, so it's not clear why it being useful elsewhere is a rebuttal of that.
The model of communicating errors with exceptions is really nice. The implementation in C++ ABI's is not done as well as it could be and that results in large sad path perf loss.
> That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception.
Sometimes it is not safe to unwind the stack. The language is not relevant. Not everything that touches your address space is your code or your process.
Exception handlers must have logic and infrastructure to detect these unsafe conditions and then rewrite the control flow to avoid the unsafety. This both adds overhead to the non-exceptional happy path and makes the code flow significantly uglier.
The underlying cause still exists when you don't use exceptions but the code for reasoning about it is highly localized and usually has no overhead because you already have the necessary context to deal with it cleanly.
If you forget to handle a C++ exception you get a clean crash. If you forget to handle a C error return you get undefined behavior and probably an exploit.
Anyhow erases the type of the error, but still indicates the possibility of some error and forces you to handle it. Functionality-wise, it's very similar to `throws Exception` in Java. Read my post
C++ exceptions are fast for happy path and ABI locked for sad path. They could be much faster than they are currently. Khalil Estell did a few talks/bunch of work on the topic and saw great improvements. https://youtu.be/LorcxyJ9zr4
> "In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability."
Interestingly, Microsoft C / C++ compiler does support structured exception handling (SEH). It's used even in NT kernel and drivers. I'm not saying it's the same thing as C++ exceptions, since it's designed primarily for handling hardware faults and is simplified, but still shares some core principles (guarded region, stack unwinding, etc). So a limited version of exception handling can work fine even in a thing like an OS kernel.
FWIW, I think it is possible to make exception-like error handling work. A lot of systems code has infrastructure that looks like an exception handling framework if you squint.
There are two main limitations. Currently, the compiler has no idea what can be safely unwound. You could likely annotate objects to provide this information. Second, there is currently no way to tell the compiler what to do with an object in the call stack may not be unwound safely.
A lot of error handling code in C++ systems code essentially provides this but C++ exceptions can't use any of this information so it is applied manually.
Exceptions are actually a form of code compression. Past some break even point they are a net benefit, even in embedded codebases. They're "bad" because the C++ implementation is garbage but it turns out it's possible to hack it into a much better shape:
There is an entire area of math about the uncertainty of decision correctness in incomplete information scenarios. One of the neat aspects of it is that all computable optimal decision makers are mechanically exploitable if you have a reasonably accurate model of their finiteness. In the case of human minds, that just means they are a lot like you. The exploits require iterated games and are cognitively difficult (you have to track a lot of state).
Anecdotally, in my poker playing days I had a lot of success by attacking quasi-optimal play this way. Optimality is contextual. You can engineer a context that motivates suboptimal decisions in fact, though it isn’t easy.
However, at the limit, this is really just attacking the cognitive facilities of your opponents rather than the math of the game. Someone that with a similar ability to manipulate large amounts of state mentally could nullify the advantage. It is meta-games all the way down.
> Optimality is contextual. You can engineer a context that motivates suboptimal decisions in fact, though it isn’t easy.
I agree with your post but I'd just like to nitpick that this first phrase is not true, the equilibrium point is independent of what your opponent does.
I'm pretty sure you know this as you then go on to describe not a context where the equilibrium changes but where it becomes hard for humans to find the equilibrium.
So we agree, it's just a small nitpick of how you worded.
When I was working for the automotive industry their models and projections suggested that ubiquitous self-driving cars would reduce the total market for cars to ~15% of its current size. As in, sales would drop by 85%. The addressable market for automotive OEMs is set to undergo a dramatic reduction in size.
Few automotive companies have a coherent plan for how they were going to survive that existential risk.
People will still be doing about the same number of miles per year, and cars will still last a similar number of miles. So if a ride share car does 10x as many miles per year we need 1/10 the cars, but they also last 1/10 as long, so it evens out.
Sure they'll get slightly more miles out of a ride share car, but the number of miles will also go up do to dead heading and because cheaper/better transportation causes prior to use more of it.
Sorry, but at the current price of Waymo rides that just can't happen. They become more expensive than leasing a car at something like 8 rides per month (as in, get into a Waymo, expect to pay $60 per ride)
> USA keeps getting a larger GDP you say, yet the population at large seems to be getting poorer
People in the US may be many things but poor is not one of them. The median household income is ~$85k and the median household lives somewhere pretty inexpensive. The amount of money Americans can afford to waste on things they don't need is unmatched.
"Poor" isn't just "doesn't have N USD", purchasing power as just one example, matters so much more. But maybe it was a poor choice of words on my part, sorry.
That's what government social programs like Medicaid and SNAP/EBT are for, accounting for about 800 billion in gov spending in 2025, and a total of 1,2 Trillion the US gov spend on welfare in 2025. That's exactly the opposite of being poor. If you want to see real poverty, go to countries that don't have any government welfare programs.
In EU many workers also wouldn't be able to afford to live without taxpayer-funded government subsidies, tax credits or regulations forcing employers to not be able to pay minimum wages below a certain threshold (which is not coming out of shareholders pockets BTW but from the overall company salary budget pie, IE high earners) which also gets inflation adjusted yearly.
The lower class is always subsidised in wealthy de-industrialized western countries, since the low-skill jobs that previously could support a family, either got automated or offshored to Asia, causing a loss of worker bargaining power, so your only chance of preventing mass riots is to subsidize the lower class here and there. It's a masked UBI with extra steps.
> That's what government social programs like Medicaid and SNAP/EBT are for
Many people intend those programs to work that way, but they don't: People still can't afford food, healthcare, housing, and education. The programs are also being cut back on a large scale.
> The lower class is always subsidised
Many would say it's actually the wealthy who are subsidized. For example, most policy, laws, regulations, and both political parties are oriented toward serving and facilitating the wealthy, or at worst, not displeasing them. The military is sometimes used to serve large corporations, such as oil companies. Weathy people often pay a lower rate of taxes: The tax on their primary form of income, capital gains, is lower than the tax on other people's primary form of income, wages; the numbers get worse when you account for welfare taxes, which are regressive. People literally die of poverty - they are unable to afford the care they need.
>Many people intend those programs to work that way, but they don't
It's not as binary. It fails for some people, but it definitely works for most. There's always people slipping through the cracks of the net, even in the most generous welfare states, but that's a long stretch to claim americans are "dying of poverty" when they have an abundance of resources at their disposal to not die.
For example, if you're homeless american in a large city, you can go dumpster diving and get fresh food that's been thrown out just because it "looks ugly". If your tummy hurts, you can go to the ER and receive mandated sci-fi healthcare to not die, even if you're homeless. This is a far cry from the definition of "dying of poverty". I suggest you visit places like Russian republics, Myanmar or Nigeria if you want to see what actual dying of poverty looks like where you don't have access to free food and scifi healthcare.
The biggest problem killing americans is drug addiction and mental illnesses. Since if your brain is fried you won't be able to make much use of available free food and healthcare.
>Many would say it's actually the wealthy who are subsidized
That's always been the case since post-WW2 at least and gotten worse since Reagan. What's your suggestion to fix it? The super wealthy have too much power and influence over finance and politics, no matter who you vote for. Elected officials, on either side, will never touch them since they're in this together, so the system is working as intended, there's nothing you can fix here.
> It's even difficult and expensive to _stop_ an LLC and dissolve it.
In my experience this is at least as important. Everyone focuses on the process of creating companies, which is now relatively streamlined in many European countries.
The real, massive difference between the US and EU is how hard it is to shutdown a company and the legal implications of that. I was shocked at how unreasonably slow and painful it can be to shutdown a company in Europe the first time I did it. Many countries effectively treat it as a criminal proceeding. Sometimes startups just fail, that is the nature of startups.
In the US shutting down a company is almost as easy as creating one.
I've been told by a lawyer that a common sensible step in closing companies in Germany is to first...reseat the company in the UK ... (at least pre-brexit - not sure if things have changed). Think of how bad and expensive the process has to be for this extra step to be worthwhile.
I have been trying to close a UK company for the past 2 years (created post brexit).
And reseat, as others say, is not as easy; the gravity of decision making has to be in the country of incorporation; if your main shareholders and directors are physically in Germany and you reseat the company to where-ever, Germany is going to see and act like this is a de-facto German company. Hence you gain nothing, you get more paper work.
You're saying you get nothing, but you perhaps underestimate how time-consuming and expensive even the easiest company shut down in the Germany is. (I had a very smooth process winding down my company in the UK - you have my very sincere sympathies that things are a bit rockier for you).
>if your main shareholders and directors are physically in Germany and you reseat the company to where-ever, Germany is going to see and act like this is a de-facto German company. Hence you gain nothing, you get more paper work.
Looking online, here's a german tax-advisor who talks about the strategy of liquidating your company by first merging it with a uk company, saying you can close a company in 4-6 weeks by this process (though they recommend against it after brexit for liability reasons, but mention Ireland and malta as options). In germany you have a year of waiting, and lots of additional notary/accounts work. (OTOH, I don't know how you get it down to 4-6 weeks and avoid the uk's company house gazette notification period - they must pick a different kind of company - if your fees for closing down a company in germany are going into the thousands (or tens of thousands) for notaries, liquidators fees, and the like).
Once again, not my specialty area, I just...wanted you to know that it does happen, is a specialty area of work for some companies, and it's presumably not irrational behaviour.
In the US, it is common for a small startup company to have no employees. Your role and title with a company is separate from your official employment status. This is where concepts like "sweat equity" come from. You can be an owner and work on a company without being an employee or receiving any compensation. Creating a company in the US comes with no real obligations to do something with it.
This is beneficial. It allows small companies to bootstrap without incurring the complexity and cost of having employees until they have enough revenue or capital to justify that expense.
For Americans the 1970s were pretty terrible all around when compared to the other decades in the latter half of the 20th century. The 1980s are broadly viewed as a positive decade, albeit not an impactful decade, but the context for that perspective is coming out of a terrible 1970s.
The Trump reign is a direct consequence of 1980s Social and Economic policy.
Although the libertarian hellscape vision of the 1980s would reject state ownership of (for instance) Intel, it might embrace the Chevron ownership of the state.
While not common, regulations requiring a hard delete do exist in some fields even in the US. The ones I familiar with are effectively "anti-retention" laws that mandate data must be removed from the system after some specified period of time e.g. all data in the system is deleted no more than 90 days after insertion. This allows compliance to be automated.
The data subject to the regulation had a high potential for abuse. Automated anti-retention limits the risk and potential damage.
There are higher non-technical peaks in South America. Ojos del Salado at well over 22,000 feet comes to mind as a peak that is often considered non-technical. Also an active volcano which is cool.
With the older microarchitectures there was a large penalty for crossing a cache line with AVX-512. In some cases, the performance could be worse than AVX2!
In older microarchitectures like Ice Lake it was pretty bad, so you wanted to avoid unaligned loads if you could. This penalty has rapidly shrunk across subsequent generations of microarchitectures. The penalty is still there but on recent microarchitectures it is small enough that the unaligned case often isn't a showstopper.
The main reason to use aligned loads in code is to denote cases where you expect the address to always be aligned i.e. it should blow up if it isn't. Forcing alignment still makes sense if you want predictable, maximum performance but it isn't strictly necessary for good performance on recent hardware in the way it used to be.
Exceptions in high-level languages avoid many of these issues by virtue of being much further away from the metal. It is a mis-feature for a systems language. C++ was originally used for a lot of high-level application code where exceptions might make sense that you would never use C++ for today.
reply