Ace17

You mean, having wrapper classes over the C primitives?

Wouldn't this defeat the purpose of having an immediate-mode API ?

Quite the opposite IMHO : when your program interacts with a user, you cannot panic the program each time something unexpected happens. Here are some examples of unexpected conditions:

- "Null pointer dereference"

- "Out of memory"

- "Disk is full"

- "File does not exist"

- "File does not exist in cache"

- "File exists but is corrupt"

- "Access denied"

- "Connection reset by peer"

It's pretty obvious that all of the above is generally unwanted most of the time.

However, putting them all in the same bag labeled "error", and forcing them to be treated the same way might be counterproductive. Sometimes you might want to panic. Sometimes you might want to retry. Sometimes you might want to ignore!

Now, if your program isn't interactive (such as a compiler), halting on any error might be a choice. But you still have to provide contextualized and accurate error messages, which is easy for the case "File does not exist", and a lot less easy for the case "Out of range index".

Technically, `throw` is `goto somewhere`.

> But as natural as causal reasoning feels to us, computers can’t do it. That’s because the syllogistic thought of the computer ALU is composed of mathematical equations, which (as the term “equation” implies) take the form of A equals Z. And unlike the connections made by our neurons, A equals Z is not a one-way route. It can be reversed without changing its meaning: A equals Z means exactly the same as Z equals A, just as 2 + 2 = 4 means precisely the same as 4 = 2 + 2.

What about Prolog ? How is it not a counter-example of this ?

> I was curious to see how the self-correcting mechanisms of science would respond [...] > I was disappointed by the response from Southwest University. Their verdict has protected [a fraudulent researcher] and enabled him to continue publishing suspicious research at great pace.

The self-correcting mechanisms of science can only correct knowledge. Those mechanism work mainly by requiring the research works to be checkable by others. Self-correctness emerges by the accumulation of checks on the same topic, all leading to the same conclusion, and by the progressive retractation of bad research ... not by the elimination of "bad researchers".

Efficiently "correcting" people, whatever that means, is a different beast. Such a mechanism belongs to an administrative entity who can emit decisions - and, by construction, who can make errors.

> You learn how to use it, but you don't learn the proofs behind it?

Which makes sense, at least firstly, considering that understanding a proof is a lot easier when its conclusion is already familiar.

It depends on how the physics engine has been integrated into your game/engine. The book "Game Coding Complete" shows how to isolate a 3rd-party physics engine so you can switch implementations.

Of course, every physics engine behaves a little differently from the others, so, if you game is physics centered (pinball, racing), switching implementation might result in a slightly different game - but having the core of your game depends on the implementation details of some 3rd-party library might not be a good idea anyway.

In general, the more you sprinkle your code with dependencies to 3rd party libraries, the less control you have over the resulting product.

Your point still stands, though, for some very low-level "utility" libraries like boost or the STL, or any standard library replacement , and more generally, libraries holding "vocabulary" types.

> You do not live in a video game. There are no pop-up warnings if you’re about to do something foolish, or if you’ve been going in the wrong direction for too long.

In the good old times most video games weren't like that.

It's a pity that those times are gone, to the point video games are now used as such a comparison point!

Facebook and Google anyone ? :-)

``` In this sense, the lock in lock-free does not refer directly to mutexes, but rather to the possibility of “locking up” the entire application in some way, whether it’s deadlock, livelock – or even due to hypothetical thread scheduling decisions made by your worst enemy. That last point sounds funny, but it’s key. Shared mutexes are ruled out trivially, because as soon as one thread obtains the mutex, your worst enemy could simply never schedule that thread again.

[...]

A final precision: Operations that are designed to block do not disqualify the algorithm. For example, a queue’s pop operation may intentionally block when the queue is empty. The remaining codepaths can still be considered lock-free. ```

I don't get it ; how could "locking a mutex" not be considered as an "operation that are designed to block" ?

Would somebody be kind enough to tell me what am I missing here? Thanks !

Your hypothesis would explain a decrease in sales ; but can it explain an increase of negative reviews?

"We’re so spoiled today. Every week a newer, faster processor is released. Hardware gets cheaper and we can just throw more chips at the problem."

I've been running a 3.5GHz CPU (with 4 HT cores) for nearly 10 years.

That's a lot of weeks. Surely, today, I should be able to buy a 10GHz CPU, right? :D

I agree: if you only consider extra revenue, it's not worth the extra effort.

And yet, GNU/Linux is supported by many commercial games: Amnesia, SOMA, SpaceChems, Towerfall, Braid, HyperLight Drifter, Shovel Knight, Undertale, VVVVVV, Hollow Knight, Overload, WarGame Red Dragon ...

So there must be something else there than extra revenue.

No GNU/Linux version, for such a geeky theme ?

The game uses Unity3D, it might only be a matter of ... recompilation :D