deschutes
I'm sure there will be some bullshit example of how after inlining you can find repetition like this but clearly other languages get along fine without prohibiting infinite loops.
Furthermore, if the goal was to allow for code motion between identical loops absent side effects they could have just said that and spared the ordinary infinite loop.
In a world where C++ is a language unrelated to C another reasonable position would have been to prohibit spelling loops that cannot terminate and provide a fix it for the possible meanings (unreachable, spin).
Injecting a side effect to solve this issue is just horrendous
That said, my experience in a urban area on the west coast has given me many examples that support this notion that it's not just a housing problem. Indeed many of the local governments own attempts to house the unhoused fail in no small part because the unhoused create conditions incompatible with staying housed.
Furthermore there is a steady drip of examples in regional news that raise serious questions about the efficacy if not motivations of the judiciary, politicians, law enforcement and local beuracracies charged with addressing the problem.
I do believe that housing costs are a major part of the problem but I also believe that treating the population as if they have no obligations to society is a major and fatal mistake to the whole enterprise. For one the policy approach has invited contagion by not addressing the population of unhoused that cannot or will not uphold the most basic aspects of the social contract. For two, it turns away a large number of people that would otherwise be sympathetic to the cause.
I wouldn't wager a nickel on someone's life if it depended on embedded STL usage.
But a shared_ptr manages at least 3 things: control block lifetime, pointee lifetime, and the lifetime of the underlying storage. The weak pointer shares ownership of the control block but not the pointee. As I understand this is because the weak_ptr needs to modify the control block to try and lock the pointer and to do so it must ensure the control block's lifetime has not ended. (It manages the control blocks lifetime by maintaining a weak count in the control block but that is not really why it shares ownership.)
As a bonus trivia, make_shared uses a single allocation for both the control block and the owned object's storage. In this case weak pointers share ownership of the allocation for the pointee in addition to the control block itself. This is viewed as an optimization except in the case where weak pointers may significantly outlive the pointee and you think the "leaked" memory is significant.
For practitioners it serves mainly as a pointless gotcha. In safety critical domains the batteries that come with c++ are useless and so while they are right to observe this would be a major problem there they offer no real relief.
It's not really what this is about IMV. The vast majority of unrecoverable errors are simply bugs.
A context free example many will be familiar with is a deadlock condition. The programmer's mental model of the program was incomplete or they were otherwise ignorant. You can't statically eliminate deadlocks in an arbitrary program without introducing more expensive problems. In practice programmers employ a variety of heuristics to avoid them and just fix the bugs when they are detected.
This kind of dysfunction happens more often on teams with incompetent people in control but sometimes temporarily happens on otherwise high functioning teams when multiple people are fighting over philosophical control of the project.
Whether or not there is some legal argument that he didn't violate his employment contract anyone would recognize the conflict of interest at the heart of those transactions as fraud. Seems like the feds or Amazon just bungled the case.
This is funny to juxtapose with Neil Gorsuch giving accounts of honest people getting tied up in criminal cases or byzantine regulations for reasonable behavior. Hard to escape the conclusion the system is tuned to reward those with resources rather than find justice.
That's not to dismiss criticism of them, but to me it's obvious, especially if you take a slightly longer view that these companies are in fact making lives better.
The real estate market is a much better example of the harmful effects of terminal greed. Unfortunately so much of the population is in on it now nobody has the fucking balls to stop the music.
One big example is that keys in associative collections are const qualified even when moving from the collection. The constness doesn't match the expectation users have when consuming a collection and is unfixable within the constraints of the STL. Anyway it results in awful type checking errors. The whole library is full of these foot guns and most of them result in bizarre behavior or horrible error messages.
Iterators have their own warts but IMO work much better within the C++ type system. Here's a fun one. Reverse iterators have their own set of invalidation properties which are typically weaker and different than forward iterators. Due to various reasons they actually refer to the element that precedes (in reverse sequence) the one you'll get when dereferencing it. So end is rfront and front is rend.
In either case the experience is quite bad compared to the stream apis you get from rust. But I don't think this is a mark against concepts, just a dated design and the limits of the type system and semantics of the language.
So the net is actually a small performance win but lesser than if there was no free threading. That said, many of the techniques he identified were immediately incorporated into CPython and so I would expect benchmarks to show some regression as compared with the single threaded interpreter of the previous revision.
A text based format whose sole virtue is descending from a system that was composed mainly of bugs that had coalesced into perl scripts.
It's not the basis of something you could even give away, let alone have people willingly pay you for their agony. Cloudwatch being rather alike in this regard.
Formal verification is often thrown around but my understanding is it can't scale to the complexity of something like an optimizing compiler.
And when they do, they will be able to capitalize on the information gained from your 2 point attempt.
In terms of expected value, 2 point conversion attempts are roughly par with extra points, though with so few scoring events in the game you would expect large variance.
So outside of scenarios where it is pure upside (1 point doesn't matter without many more scoring events) teams will opt for the lower variance outcome. This matches practice pretty well IME.
Worst case execution time with pipelining should be similarly measurable given a worst case execution (which seems in any case necessary to demonstrate a bound on the task, even in a lockstep system).
See https://cs-people.bu.edu/rmancuso/files/papers/cache_survey_...
A few leaks fixed per month is nothing. Further there is no major language promising no leaks once you include things like retained references to garbage and reference cycles. Leaks are one thing modern C++ solves pretty well.