s28l

char* can also be a C-style string. std::byte has the same special treatment in the standard as char and unsigned char, with the added benefit of not being used for other purposes (i.e. ASCII character or uint8, respectively).

C style cast can be either a static_cast or reinterpret_cast, but it can also be a const_cast or a static+const or reinterpret+const. Finally, it will perform a static_cast that bypasses private inheritance (because the alternative would be to fall back to a reinterpret_cast, which is wrong if the static_cast needs to apply an offset to the pointer)

I find this article rather underwhelming because it spends so much time calling out bad examples and so little time highlighting examples of subtlety (in any era). Without positive examples, I don’t think they make the case that this is a new phenomenon or even a phenomenon at all: all the author has done is identify a lens to criticize through.

It may be the case that this is a recent phenomenon (though some other commentators disagree), but without providing detail on what movies the author feels avoid this pattern, they make their argument impossible to refute or engage with. (It also insulates the author’s tastes from criticism, which I suspect is part of the motivation)

Maybe it's a combination of the "bend" and the "long slow" part.

If you are making a turn the centrifugal force will push the fluid away from the axis of rotation. There is likely a level sensor only on one side of the tank, so the turn might push the fluid away from the sensor enough to trigger a warning.

The sensor likely has a time component to avoid triggering every time you make a turn, but if this bend is long enough, maybe the fluid is displaced long enough that it overcomes that minimum time.

Doesn't the unrolled version skip the speculation for three out of every four entries? If so, it seems suspicious that it does so much better when it looks like it's a mix between the first and second version instead of just an unrolled implementation of the second version.

I'd also be interested in seeing how this performs when the data isn't allocated in one chunk (which seems to be the absolute best case scenario for this trick). Will it end up worse than the "naive" version due to all the branch mispredictions?

His goal seems to be to effect change. My understanding is that before reaching these questions, he _was_ interested in the job. Explaining to a potential employer that they lost a candidate's interest because of their application questions seems like something they would want to know.

Considering he also wrote a blog post criticizing this question, I feel comfortable saying that he already passed on this job. So saying you'd pass on him has "you can't quit, you're fired!" energy to it. Also, I don't agree that this demonstrates insubordination. There can't be insubordination without a subordinate-supervisor relationship.

I also don't think this is a "smartass" answer:

> This is an irrelevant question unless you're focusing on recent grads with no job history.

That is a straightforward statement of his opinion. He's perfectly within his rights not to answer any question, and explaining why he chooses not to is hardly an unreasonable thing to do.

Against better judgement (and advice of counsel, presumably), this guy is still running his mouth to the media. If you had a disgraced former crypto CEO who was still willing to speak at your finance conference, wouldn't you keep him on the docket? I certainly would.

> No, just no. Why is the MSM putting out constant puff pieces about this guy?

Just to be clear, this is the archive of a puff piece published on the Sequoia Capital website: they were talking up their book. They took it down when they wrote their investment in FTX down to $0 (from over $200mm). It was neither published recently nor by a MSM outlet.

I don't think that's true. Neither C nor C++ would allow you to invoke a function with an incomplete type, regardless of whether it is a `struct` or an `enum`, so there's no ABI issues with forward declaring them, but you wouldn't be able to define or invoke a function that takes an incomplete type argument by value.

    struct A;
    enum B; // as you pointed out, not allowed by the C++ standard

    // fine to declare, define, and invoke
    void fooA(struct A*);
    void fooB(enum B*);

    // ok to forward declare, but you can't call them
    void barA(struct A);
    void barB(enum B);

I think the only benefit of `_Pragma` is that it enables defining a macro that expands into a `#pragma` definition. I don't think there's any other use case beyond that.

I meant that they are processed before any syntactical analysis, so they're not particularly useful for this kind of thing. For example, these are all wrong usages of our hypothetical `#pragma unreachable`:

    void foo();
    #pragma unreachable
    class bar
    {
    #pragma unreachable
    };
    namespace foobar {
    #pragma unreachable
    }

But pragmas can generally be used anywhere, barring tokenization issues. The end result is that `pragma unreachable` would likely end up turning into a magic function call inside the compiler, since it really only makes sense in a spot where you can invoke a function.

Also, I think you are conflating pragmas with `__attribute__`, which is how you set per function optimization settings. If you do that with pragmas, then it isn't limited to a single function.