You could also ask the question for "why do founders even bother with startups", and you'll get the exact same answer. It seems selfish that they then expect their employees to work for them, not for money, but rather for love and exposure.
> To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why.
Do you talk down to people like this IRL as well?
> I've been using ccache for years and I never had any problem getting ccache to support template code.
What I said is that zapcc has a different approach that offers even more performance benefits, answering the question of what zapcc offers that ccache doesn't offer.
> if you understand how compiler caches work. Think about it.
There's no need to use "condescending asshole" as your primary mode of communication, especially when you are wrong, such as in this case.
> What value do you think something like zapcc brings that tools like ccache haven't been providing already?
It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file.
How can that be true? Inside the event horizon, there is only one direction: down. If light cannot escape, how can it happily bounce around, reflect on something, then reach your eyes? How could signals from your feet (say) even reach your brain, assuming a feet-first entry into the black hole?
Same here. Three days of absolute hell. Even a single blue led was too much to bear. And like you I now need reading glasses, but I don't really care: I can see well enough in the distance, I'm not visually crippled throughout the day without my glasses.
I used to have dry eyes afterwards for quite some time (years) as well, but that seems to have gone away at some point.
If you'll inspect the names of the posters, you will quickly realize that it was not _my_ claim. I'm also not quite certain how a list of centuries-old atrocities serves as an 'evidence-based counter' to the claim that illegal immigrants in modern America have a high crime rate. If that was indeed fabricated, it could be trivially disproved by posting a link to a current-day statistical database.
Instead he tried his best to make this about race. At best that is whataboutism, and at worst he's just a racist f*ck.
It's your reality. _You_ choose to dwell on racial issues. _You_ dedicate your life to "correcting" people, and break in on discussions that have absolutely nothing to do with race, just so you can slap them in the face with a "WHITE MAN BAD!". That is a delusion, and the rest of us have absolutely no "duty" to go along with it.
Buddhism, above anything else, teaches to let go, to _not_ get stuck in the temporary sorrows of the earthly plane. If anything, you should have learned that it doesn't matter, and to not make it the core of your identity.
You blame the White man for genocide, but conveniently leave out that much of that 'genocide' was caused by disease, long before anyone even knew what caused it. You also conveniently ignore that the native Americans happily waged war on each other whenever they had the chance.
You blame the White man for slavery, but conveniently leave out that absolutely everyone practiced slavery, and that it was the White man who abolished it. You also conveniently leave out that more slaves are kept in just India _today_ than were taken by all European nations throughout history.
You blame the White man for lynching, but conveniently leave out that 'necklacing' is practiced today, in South Africa, on White people. Your viewpoint is extremely one-sided, and always to the detriment of a single race.
I can go on, but I think you can see my point: you assign blame to a single race, and are blind to the reality that nobody here are angels. You scapegoat one group based on their skin color, while willfully ignoring that pretty much everybody did the worst they could, whenever they had the opportunity.
Are there any human tribes around that haven't at one point or another experienced a negative event at the hands of others?
What should we all be given, and more importantly by whom, just to make up for the endless parade of historic injustices? Does dwelling on them for all eternity make for a good future?
And that makes it ok to commit warcrimes? Under that reasoning, which really only comes down to "because it is needed", anything is allowed. Including everything Israel does, because to them, it's also needed.
And here's the thing: hamas has extensive underground tunnel networks, so it actually _isn't_ needed to hide among civilians! They do it purely for the optics: every destroyed school or hospital will help sway Western opinion.
That list is totally not cherry picked to serve a very specific agenda (/s). Actual safety for regular citizens is affected by events that are occurring today (instead of decades ago), as the result of actions by individuals (rather than state-sanctioned violence). As such, the grandparent is 100% correct: letting violent people into your country will raise the overal level of violence that people encounter.
Next the police will be knocking on your door, just to make sure you are not skipping ads in the newspaper.
"M'am, that vase in front of your TV could be used to block ads. You are going to have to move that."
Anyway, I see a great future for adblockers that render the whole page in a back buffer, and then copy it to a front buffer where it is masked by a bitmap that just has black squares where the ads used to be. That doesn't "change the original, copyrighted document", so it should be fine. And I presume putting that vase in front of your screen is still acceptable, even in Germany.
If publishers want more control, they always have the option of downloading the entire page as a bitmap.
Yes, really. Windows supports 'delayed rendering' (https://learn.microsoft.com/en-us/windows/win32/dataxchg/cli...), whereby an application can choose to not provide the data until requested. Thus, applications have a choice of either providing the data directly if it's a smaller amount, or delaying that if the amount is large enough that a performance impact can be expected.
Moreover, Windows will request that applications that are closing provide their previously advertized clipboard data, making the feature pretty much transparent to users. And some applications ask if you will still need your previous clipboard data when they close (Excel is one, I seem to remember).
I, once again, disagree with the premise that UB is a necessary precondition for optimisation, or that it exists to allow for optimisation. You do not need UB to unroll a loop, inline a function, lift an object or computation out of a loop, etc. Moreover, _most_ UB does not assist in optimisation at all.
The two instances where UB allows for optimisation are as follows:
1. The 'signed overflow' UB allows for faster array indexing. By ignoring potential overflow, the compiler can generate code that doesn't check for accidental overflow (which would require masking the array index, recomputing the address on each loop iteration). I believe the better solution here would be to introduce a specific type for iterating over arrays that will never overflow; size_t would do fine, and making signed overflow at least implementation defined, if not outright fully defined, after a suitable period during which compilers warn if you use a too-small type for array indexing.
2. The 'aliasing' UB does away with the need to read/write values to/from memory each time they're used, and is extremely important to performance optimisation.
But the rest? Most of it does precisely nothing for performance. At 'best', the compiler uses detected UB to silently eliminate code branches, but that's something to be feared, not celebrated. It isn't an optimisation if it removes vital program logic, because the compiler could 'demonstrate' that it could not possibly take the removed branch, on account of it containing UB.
The claim in the linked article ("what every C programmer should know") that use of uninitialized variables allows for additional optimisation is incorrect. What it does instead is this: if the compiler see you declare a variable, and then reading from it before writing to it, it has detected UB, and since the rule is that "the compiler is allowed to assume UB does not occur", use that as 'evidence' that that code branch will never occur and can be eliminated. It does not make things go faster; it makes them go _wrong_.
Undefined behaviour, ultimately, exists for many reasons: because the standards committee forgot a case, because the underlying platforms differ too wildly, because you cannot predict in advance what the result of a bug may be, to grandfather in broken old compilers, etc. It does not, in any way, shape, or form, exist _in order to_ enable optimisation. It _allows_ it in some cases, but that is, and never was, not the goal.
Moreover, the phrasing of "the compiler is allowed to assume that UB does not occur" was originally only meant to indicate that the compiler was allowed to emit code as if all was well, without introducing additional tests (for example, to see if overflow occurred or if a pointer was valid) - clearly that would be very expensive or downright infeasible. Unfortunately, over time this has enabled a toxic attitude to grow that turns minor bugs into major disasters, all in the name of 'performance'.
The two bullet points towards the end of the article are both true: the compiler SHOULD NOT behave like an adversary, and the compiler DOES NEED license to optimize. The mistake is thinking that UB is a necessary component of such license. If that were true, a language with more UB would automatically be faster than one with less. In reality, C++ and Rust are roughly identical in performance.
Maybe that attitude works in a big company, but it won't fly in a smaller one. I'm a software engineer and I write plenty of code, but I also help out with interviews, packing, sales demos and proposals, customer support, general IT support, etc. Hell, I've fixed the coffee machine! I'd absolutely hate it if writing code was my only task.