Sagiri

The difference is that a big part of YT's appeal is how open it is. Anyone can post pretty much anything.

With something like Udemy, where you have to pay for courses, Udemy needs to review every course before selling them. You need to check them for accuracy (which would mean having them reviewed by experts in the field), as well as verifying the author's identity and doing at least a cursory check for stolen content.

If Udemy /wants/ to be as open as YouTube, that's fine. It just means that it's no better in terms of guaranteeing accuracy, which doesn't make much sense considering you have to pay for courses. If Udemy and YouTube offer basically the same minimal guarantees that their content is accurate and not stolen, why would you ever use the paid service?

Because you have to pay to access courses in Udemy, you may not even be able to tell if a course is stolen or not without paying for it. Obviously, you'd be able to tell if it was stolen whole cloth, but if it's been paraphrased, you'll probably want to be able to look at more of the course to make sure it wasn't just a coincidence because someone else decided to do the same topic. Do you want to pay just to check if it's your own stolen work?

While I haven't done it myself, my understanding is that reporting stolen content on Udemy is unnecessarily difficult, and that Udemy generally takes a long time to take it down. Now, maybe that's not true (or maybe it's not true anymore), but that doesn't reflect well on them if it is/was.

Ethical violations are an endemic problem. If everybody named and shamed companies for every ethical violation they encounter, every company would end up named and shamed. And the really bad stuff would get buried in an avalanche of comparatively trivial violations.

I'm not.

Undefined behavior is 'anything goes'. An implementation can choose a particular behavior that you can rely on for a particular case of UB, because, if the only rule is that 'anything goes', it doesn't violate that rule.

I'll admit that compilers don't generally do that - because specifying it could lead to fewer optimizations. But I did say "if", and there's no reason they couldn't do so in principle.

One could imagine a compiler with an extremely strict debug mode that traps on a number of situations that the standard deems undefined behavior via a segfault, in order to help people avoid relying on UB. Again - saying something like "casting misaligned pointers causes a segfault on [system]" would in no way violate a standard that says "casting misaligned pointers can do anything", because segfaulting falls under the umbrella of anything.

I think you're misinterpreting the fact that the results of undefined behavior can be ignored by a compiler for a requirement that it must be ignored by a compiler.

We just need to remove the Electoral College and use a straightforward majority wins (or plurality, as the case may be).

It isn't?

At least that would be a failure at compile-time, rather than run-time.

You weren't replying to me, but I genuinely do keep my phone on silent (no, not vibrate) and will never answer it (both because it's rude and because I don't notice it).

But I do try to check it regularly whenever I get the chance.

Well, yeah. If you have any reason to suspect that you will need to run your code on other platforms or compile with other compilers, don't do compiler-specific things. Just do it cross-platform the first time.

Hell, even if you don't think you'll ever need to do that, you should still avoid doing things that are platform or compiler specific.

If the semantics of casting pointers of wrong alignments were defined to be demons flying out of your nose, it would be perfectly acceptable to rely on that behavior.

The correct and portable solution is to not use uint32_t, but to use uint8_t, and construct the integers manually.

If a particular compiler specified that casting pointers of wrong alignments causes a segfault, it'd be perfectly acceptable to rely on that behavior. The standard would consider it UB, but that compiler has defined that behavior sufficiently.

Note, though, that a compiler simply doing a particular thing now isn't good enough to specify it in the sense that I mean. The compiler writers would have to explain (in a blog post or the like) the behavior and that they plan to keep that behavior in all future versions.

Rust is basically a safe C++, written by people who like functional languages. Also, it has an official package manager in Cargo, something that C++ lacks completely.

As such, it targets essentially the same niche as C/C++.

Personally, I would rather builds be slow than have my build mysteriously break when I'm in that 1%.

> There is no mechanism for you to mark a function as potentially crashing your teammate’s code or for specifying how to process an exception.

Maybe I'm misinterpreting this, but is the author actually advocating for Java-style checked exceptions? I can't even remember the last time I heard somebody say something positive about them (other than just now, possibly).