HackerTrans
トップ新着トレンドコメント過去質問紹介求人

deschutes

no profile record

コメント

deschutes
·17 日前·議論
What is so objectionable about data centers anyway? That they consume utilities without employing a substantial amount of people? Compared to actual manufacturing like fabs the pollution concerns are laughable. The water use issue seems to be a wedge.
deschutes
·2 か月前·議論
It's hard to find anyone that doesn't have some motivation in this problem. I won't claim any percentages because I do not know them and I would not trust them even if I did.

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.
deschutes
·6 か月前·議論
It sounds like std::atomic_ref<T>::{load,store}(relaxed) to me. 1. ad-hoc atomicity with ref 2. no ordering

https://godbolt.org/z/4h893P7hG
deschutes
·10 か月前·議論
You cannot use the rust standard library in environments where arbitrary allocations may fail but neither can you use the STL. The difference is the rust standard library doesn't pretend that it has some reasonable way to deal with allocation failure. std::bad_alloc is mainly a parlor trick used to manufacture the idea that copy and move fallibility are reasonable things.

I wouldn't wager a nickel on someone's life if it depended on embedded STL usage.
deschutes
·10 か月前·議論
You are correct, it does not affect the lifetime of the pointed object (pointee).

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.