I’m working through the vulkan tutorial and came across GLFW_TRUE and GLFW_FALSE. I presume there’s a good reason but in looking at the docs it’s just defining 1 and 0, so I’m sorta at a loss as to why some libraries do this (especially in cpp?).
Tangentially related is having things like vk_result which is a struct that stores an enum full of integer codes.
Wouldn’t it be easier to replace these variables with raw int codes or in the case of GLFW just 1 and 0?
Coming mostly from C, and having my caps lock bound to escape for vim, the amount of all caps variables is arduous for my admittedly short fingers.
Anyway hopefully one of you knows why libraries do this thanks!
Some languages define True as -1, which is NOT False…
I once wrote a library to replace an older one. Someone did this, and users were multiplying variables by booleans and negating them in formulas.
I just made the new library less stupid and left the users to clean up their mess when migrating.
You really didn’t need this; I would have just assumed that you were speaking the truth.
CONST False = 0, True = NOT False
NOT as in the binary operator. What’s NOT of 0 in a 32 bit space? 0xFFFFFFFF, which is -1, which is ≠ 1
Different languages, and even different programmers might interpret the concept and definition of True and False differently, so to save any ambiguity and uncertainty, defining your own critical constants in your own library helps make sure your code is robust.
So… all that is NOT False either, I presume?
they mean every bit is different
I don’t know; their comment seemed pretty much the same throughout…